On-Demand Contract Factory

The on-demand factory pattern lets an institution publish a governed product template and create one child contract per approved customer request.

The factory does not spawn contracts inside TREA runtime. Instead:

ProductTemplate
  -> ProductRequest
  -> ProductInstance
  -> ChildContract

The parent approves and binds. The CLI or institutional backend deploys the child at a deterministic address and registers it back into the parent.

Why No Runtime Spawn

Native spawn would open a large surface: lifecycle policy, gas limits, artifact authorization, replay protection, and audit semantics. The v0.1 pattern keeps the runtime deterministic:

1. Institution deploys std.factory.ProductTemplate.
2. Customer calls request_contract(...).
3. Issuer calls approve_request(...).
4. Parent derives the required child id.
5. CLI/backend deploys the child contract at that id.
6. CLI/backend calls register_child_instance(...).
7. The child runs its own accounting and receipts.

Derived Child Address

Child ids are deterministic and not human-named:

derive_child_id(template_id, requester, request_id) -> contract:<hex16>

This makes identity personal by ownership and request. One thousand customers of the same template get one thousand distinct child contracts, not one shared Map[user -> state].

ProductTemplate Contract

std.factory.ProductTemplate stores:

• issuer;
• template id and product type;
• child artifact allowlist;
• child code, ABI, IR, and storage-layout hashes;
• request state;
• approved terms hash;
• derived child id;
• registered child artifact.

Important entrypoints:

@tx
def request_contract(request_id, requested_amount, requested_term_days, requested_terms_hash)

@tx
def approve_request(request_id, approved_terms_hash)

@tx
def reject_request(request_id)

@tx
def cancel_request(request_id)

@tx
def register_child_instance(request_id, child_contract_id, child_artifact_id,
                            child_code_hash, child_abi_hash,
                            child_ir_hash, child_storage_layout_hash)

@view
def child_id_of(request_id) -> Address

@view
def expected_child_id(request_id) -> Address

register_child_instance rejects mismatches between the deployed child and the approved allowlist. Free text is never the source of truth.

`trea deploy-child`

The CLI packages the external orchestration:

trea deploy-child tmpl req-1 child-req-1 --audit basic

It:

1. reads child_id_of(req-1) from the template;
2. deploys the child script at that derived id;
3. fetches the artifact hashes;
4. calls register_child_instance on the template.

Do not use --no-wait for flows that need immediate binding unless the node and deployment script guarantee the artifact is already visible. Binding needs the published artifact hashes.

Child Lineage

Child contracts can carry their own origin proof. CreditCardVault exposes:

@tx
def bind_lineage(parent_template_id: String,
                 origin_request_id: String,
                 approved_terms_hash: String)

@view
def parent_template() -> String

@view
def origin_request() -> String

This is set once by the issuer. It lets wallet, explorer, and AI Audit show the link from child back to product template even without trusting the parent's registry alone.

Audit View

AI Audit marks:

• factory_template for parent contracts that approve and bind children;
• child_of_template for children that carry lineage fields.

Wallets should show both layers: the parent product approval and the child contract's own financial powers.