Contract

#How It Works

Every Contract has at least two party Nodes and moves through one shared lifecycle: DRAFT, SIGNED, ACTIVE, TERMINATED. Transitions are sequential and driven by explicit contract events; milestones operate inside an ACTIVE contract and never move the lifecycle themselves. Terms hold free-text commercial and legal content; milestones gate or modify specific contract effects; evidence supports both.

Each type specializes that shared shape. A Purchase Contract references exactly one Offering and carries buyer-side cost attribution for P&L. A Revenue Split Contract routes inbound value between collection points — the points where revenue enters a Node, each one a Node's default Wallet or an Offering's Wallet, with at most one Revenue Split attached to any single point. Its JOINT_VENTURE variant atomically creates a contract-node at signing — a real Node with its own identity, wallets, and cap table — while STANDALONE and BUNDLE_LINKED variants never create a Node. An Investment Contract operates on an already existing investee Node, changing ownership or investment economics, and never creates a Node.

A Replicable Contract Format provides reusable agreement-shape prefill: applying one creates a new editable DRAFT contract with the reusable parameters in place and parties and node-bound references stripped.

#Statements

These statements fix the meaning of a Contract and the boundaries between its three types.

Definition and lifecycle

• A Contract is a governed commitment.
• A Contract binds party Nodes.
• A Contract has a type and a lifecycle.
• The standard's contract types include Purchase, Revenue Split, and Investment.
• A Contract can carry milestones, terms, and evidence.

Type-specific behaviour

• A Purchase Contract references one Offering.
• A Purchase Contract carries buyer-side cost attribution.
• A Revenue Split Contract routes value between collection points.
• A collection point is where inbound value enters a Node — a Node's default Wallet or an Offering's Wallet.
• At most one Revenue Split attaches to a collection point.
• Value that lands on a collection point with its own Revenue Split cascades into that split, and the routing graph stays acyclic.
• An Investment Contract changes ownership or investment economics.

Replicable Contract Format

• A Replicable Contract Format reuses agreement shape for draft Contract authoring.
• A Replicable Contract Format creates editable Draft prefill and strips parties and node-bound references.

#Operations

Contract operations carry an agreement through its life: authoring a draft, moving it along the DRAFT to SIGNED to ACTIVE to TERMINATED lifecycle, accepting the milestones that gate its effects, and applying those effects. They cover the three contract types — Purchase, Revenue Split, and Investment — and move commitments between states without rewriting the evidence or history behind them.

Contracts bind real money and ownership, so the way they change state has to be disciplined. A single sequential lifecycle, explicit signing-time effects, and milestone acceptance that gates rather than skips state changes mean every party can trust what a contract guarantees at each point, and applying a Revenue Split or an Investment effect follows the rule the contract was signed under rather than an ad hoc edit.

Authoring starts with a draft. Draft Purchase Contract creates a Purchase draft that references exactly one Offering and captures the buyer-side cost attribution used for P&L; any Draft Contract can be prefilled from a Replicable Contract Format, where the reused shape is editable rather than locked.

Lifecycle movement is strictly sequential: Sign Contract moves a Contract to Signed, Activate Contract moves it to Active, and Terminate Contract moves it to Terminated. Signing a JOINT_VENTURE Revenue Split has a topology side effect: the contract-node is created atomically at SIGNED, with no separate later promotion step.

Milestones operate inside an active contract without moving it between lifecycle states: Accept Milestone moves a Milestone to Reached. The contract's economic effects are then applied per type — Apply Revenue Split routes value by the Revenue Split rule, and Apply Investment Effect changes investment or ownership economics.

Authoring

• Draft Purchase Contract creates a Purchase Contract draft.
• Draft Purchase Contract references one Offering.
• Draft Purchase Contract captures buyer-side cost attribution.
• Draft Contract can use Replicable Contract Format as editable prefill.

Lifecycle movement

• Sign Contract moves a Contract to Signed.
• Activate Contract moves a Contract to Active.
• Terminate Contract moves a Contract to Terminated.

Milestones and effects

• Accept Milestone moves a Milestone to Reached.
• Apply Revenue Split routes value by the Revenue Split rule.
• Apply Investment Effect changes investment or ownership economics.

#Lifecycle

Every contract moves through the same four stages, no matter whether it is a Purchase, a Revenue Split, or an Investment. It starts as a draft while terms are written, becomes signed once parties agree, runs while it is active, and ends when it is terminated. Termination closes the commitment but keeps its history intact rather than erasing it.

One shared lifecycle for all three contract types means every agreement is read the same way: anyone can tell whether terms are still being negotiated, whether the deal is binding, whether it is executing, or whether it is closed. Keeping this progression explicit and ordered is what lets the rest of the standard reason about money movement, milestones, and topology with confidence.

The state set is DRAFT, SIGNED, ACTIVE, TERMINATED, and the only legal moves are sequential: DRAFT to SIGNED, SIGNED to ACTIVE, ACTIVE to TERMINATED. No state is skipped. Each transition is driven by an explicit contract-level event — signing, activation, termination — and by nothing else.

In particular, milestones and recurring period proposals do not move the contract. Milestones operate inside an ACTIVE contract and a recurring period proposal just marks a matured payment period; neither performs a lifecycle transition.

Joint Venture special case. The single transition with a topology side effect is signing a JOINT_VENTURE Revenue Split: at SIGNED the contract-node is created atomically, with no separate later promotion step. INVESTMENT contracts never create nodes; STANDALONE and BUNDLE_LINKED Revenue Splits never create nodes; PURCHASE never creates a contract-node. Termination of a JOINT_VENTURE hands its created node into the standard node-termination flow, and that termination is blocked while an active Investment contract still exists on the JV-created node.

• A Contract lifecycle includes Draft, Signed, Active, and Terminated.
• A Draft Contract can become Signed.
• A Signed Contract can become Active.
• An Active Contract can become Terminated.
• Contract activation uses a valid contract shape.
• Contract termination preserves contract history.

#Replicable Contract Format

A Replicable Contract Format is reusable agreement-shape prefill for Draft Contract authoring. It is a narrower sub-concept of Contract: not a Configuration Artifact, not a standalone contract, but a reusable shape that can seed a new Draft.

Agreements often share structure across deals — the same revenue split mechanics, the same milestone pattern, the same term layout — while the parties and node-bound references change every time. A Replicable Contract Format captures that reusable shape on its own so authoring a new Contract starts from a known structure rather than a blank draft, and so contract reuse stays separate from configuration.

A Replicable Contract Format is derived from an existing Contract. It preserves the reusable agreement shape and strips everything party-specific: parties, node-bound references, Offering bindings, wallet bindings, collection-point bindings, and investor or investee bindings. Applying one creates a new Draft Contract that then follows the normal Contract authoring, validation, signing, activation, and termination rules.

• A Replicable Contract Format is derived from a Contract and preserves reusable agreement shape.
• It removes parties, node-bound references, Offering bindings, wallet bindings, collection-point bindings, and investor or investee bindings.
• Applying a Replicable Contract Format creates a new Draft Contract.
• The new Draft Contract follows normal Contract authoring, validation, signing, activation, and termination rules.
• Replicable Contract Format belongs to Contract semantics; it is not a Configuration Artifact.

#Why It Matters

Contracts are how Nodes commit to each other: buying offerings, routing revenue, or moving investment and ownership. Keeping the type set closed at three and sharing a single lifecycle lets the rest of the standard reason about agreements uniformly — milestones gate effects, terms hold the legal content, and evidence supports both — without each contract kind reinventing the rules.

#Related

• Node
• Milestone
• Offering
• Wallet
• Ledger Event
• Cap Table
• Configuration Artifact