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. Terms hold free-text commercial and legal content; milestones gate or modify specific contract effects inside an ACTIVE contract and never move the lifecycle themselves; evidence supports both. All contract amounts are expressed in the organization's single currency.

Signing asserts every party's agreement. An implementation may let one authorized user record that agreement, with the signing user attributed — richer per-party signing flows conform as well.

A Contract may carry zero or more free-form grouping tags. Tags are query-only: they group and filter contracts, and they never change contract semantics, never gate a lifecycle transition, and never affect P&L.

Each type specializes the shared shape. A Purchase buys exactly one Offering. A Revenue Split routes inbound revenue over collection points. An Investment moves capital and equity into an existing investee Node.

#Purchase

A Purchase Contract is one Node purchasing exactly one Offering from another Node. The purchased object is always an Offering — the standard defines no separate service or product contract types — and the contract's behaviour is shaped by the offering's business-equation archetype. Four archetypes are in scope: Scoped on Demand, Unit Based, Subscription — Tiered, and Subscription — Parametric.

Offering-level economics stay on the offering; contract-level deal parameters stay on the contract. Unit price is a contract-level term set at point of sale, as is a selected subscription tier. Parametric is the asymmetric case: the parameter lives on the offering and prices each period at its end — nothing parametric is set at point of sale.

Unit-Based consumption materializes as one-off volume events. The operator records "N units now" against the active contract, producing a ledger fact of N times the unit price agreed at signing. Executions are repeatable; a Unit-Based Purchase is never a periodic stream.

A Scoped on Demand Purchase requires at least one milestone, and its milestones unlock percentages of the contract payment as they are accepted.

Where the archetype produces a fixed periodic cash flow, the recurring Purchase stream is bounded: a total amount, a period count, and a period type (MONTH, QUARTER, SEMI_ANNUAL, or YEAR). The per-period amount is the total divided across the period count, and the stream ends once the count is reached.

Every Purchase carries buyer-side cost attribution for the buyer's P&L: FIXED_COST, OFFERING_COGS with a target offering, or GENERAL_COGS. When no attribution is set, FIXED_COST is the default. A FIXED_COST attribution without a target lands on the buyer's general fixed-cost line; with a target offering it lands as that offering's fixed cost, feeding its net margin. The target offering is a buyer-side P&L destination, distinct from the offering being purchased.

Statements

• A Purchase Contract references exactly one Offering.
• The offering's business-equation archetype shapes Purchase behaviour: Scoped on Demand, Unit Based, Subscription — Tiered, or Subscription — Parametric.
• Unit price is a contract-level term set at point of sale.
• A Purchase carries buyer-side cost attribution: FIXED_COST by default, OFFERING_COGS with a target offering, or GENERAL_COGS; a fixed cost may also target an offering.
• A recurring Purchase stream is bounded by a total amount, a period count, and a period type; the per-period amount is the total divided across the count, and the stream ends once the count is reached.
• Unit-Based consumption is recorded as one-off volume events — N units at the unit price agreed at signing — repeatable and never a periodic stream.
• A Parametric Subscription prices each period at its end from the parameter on the offering; nothing parametric is set at point of sale.
• A Scoped on Demand Purchase includes at least one milestone, and its milestones unlock percentages of the payment.
• A Purchase Contract never creates a contract-node.

#Revenue Split

A Revenue Split Contract is the routing agreement for inbound revenue: it defines how revenue flowing into a source is distributed among destinations, with allocations expressed in basis points.

Routing operates over collection points — the points where inbound revenue enters a Node: the Node's default Wallet and each Offering's Wallet. A collection point captures only the revenue that enters it. A node-level split on the default wallet routes the revenue not directed to a specific offering; an offering-level split routes the revenue landing on that offering's wallet. The two capture disjoint streams, so a node-level split and offering-level splits coexist on the same Node — and each unit of inbound revenue is subject to at most one Revenue Split at a given collection point.

Destination percentages may sum to less than 100%. Any residual stays permanently at the source collection point; it cannot be picked up by a second split on the same point. When routed funds land at a destination collection point that itself has an active Revenue Split, that downstream split fires — cascading is a consequence of the collection-point model — and the routing graph must remain acyclic.

Scope. A Revenue Split has a scope: COLLECTION_POINT, the default, attaches to exactly one collection point, while NODE — the integral split — attaches to a Node and routes inbound revenue from all of that Node's collection points, the default wallet and every offering wallet, current and future. A new offering wallet created on a node with an active integral split is automatically enrolled under the same allocation, with no separate authoring step. An integral split claims all of a node's collection points: it may be created only when all of them are free, and while it exists no other split may attach to any of them.

Variants. The standard defines three variants:

• STANDALONE is created manually. Its source is a node-level or offering-level collection point, and it may be indefinite or explicitly time-bounded.
• BUNDLE_LINKED is auto-created when a bundle is created. Its source is the bundle's own offering wallet at organization level, its destinations are the offering wallets of the bundle's component offerings, and its lifecycle is tied to the bundle.
• JOINT_VENTURE creates a contract-node at signing — atomically — with its own identity, default wallet, and cap table.

A JOINT_VENTURE carries two independent allocations set at signing: the JV cap-table allocation across the constructor nodes, and the JV revenue-split allocation routing revenue from the JV node back to them. At signing the JV node has only its default wallet, so the JV split attaches there as its source — or it may be authored as an integral split, covering the default wallet and any offering wallets the node gains later under the same allocation. JV distributions land only on the constructor nodes' default wallets, never an offering wallet: a JV distribution is owner income to a constructor rather than that offering's sales revenue, and routing it into an offering wallet would corrupt that offering's P&L. A contract-node is a Node in full standing and may later acquire offering capability where its unit type permits.

Milestones on a Revenue Split may change the split allocation going forward, and only that. A JOINT_VENTURE milestone never modifies the JV cap table; cap-table changes require a separate Investment Contract on the JV node.

A Revenue Split may also work with payment tags: it may filter inbound payments by tag and may label routed portions with outbound tags. Payment tags are distinct from contract grouping tags.

Statements

• A Revenue Split routes inbound revenue from a source among destinations, with allocations in basis points.
• A collection point captures only the revenue that enters it; a node-level split and offering-level splits coexist on the same Node over disjoint streams.
• At most one Revenue Split attaches to a given collection point.
• A partial split leaves the residual at the source collection point.
• Routed funds cascade through downstream splits, and the routing graph stays acyclic.
• Split scope is COLLECTION_POINT by default or NODE for an integral split.
• An integral split covers all of a Node's collection points, current and future, auto-enrolls new offering wallets, and excludes any other split on that Node.
• STANDALONE is authored manually; BUNDLE_LINKED is auto-created with a bundle and sources from the bundle's organization-level offering wallet.
• JOINT_VENTURE creates a contract-node atomically at signing, with its own identity, default wallet, and cap table.
• A JOINT_VENTURE carries two independent allocations: the JV cap-table allocation and the JV revenue-split allocation.
• JV distributions land only on the constructor nodes' default wallets, never an offering wallet.
• A contract-node is a Node in full standing and may later acquire offering capability where its unit type permits.
• A Revenue Split may filter inbound payments by tag and label routed portions.

#Investment

An Investment Contract represents investment from one or more investor Nodes into an already existing investee Node. It never creates a Node and never references an Offering; any Node may invest in any other Node. At most one active Investment may exist on an investee at a time — a second cannot be signed while one is active.

An Investment carries a disbursement schedule of zero or more disbursements. Each disbursement is either a lump sum or a bounded recurring stream — a total amount, a period count, and a period type, with the per-period amount the total divided across the count — and each is released either at a fixed date or by milestone acceptance. Zero disbursements is valid: an Investment may exist only to set cap-table allocations. With multiple investors, each disbursement records how its amount splits across them; how that split is authored and defaulted belongs to the implementation. An investor split never names the investee — a node cannot fund its own tranche.

An Investment sets how the investee's cap table is allocated. The effect applies at signing and may redistribute pre-existing allocations, diluting existing holders, while always preserving the exact 10,000-basis-point sum. While the contract is active, the cap table changes only through this contract's MOVE_EQUITY milestones.

Equity and investment movements are capital movements: they never sit in the cash ledger and never contribute to any P&L view.

Statements

• An Investment flows from one or more investor Nodes into an existing investee Node.
• An Investment never creates a Node and never references an Offering.
• At most one active Investment exists on an investee Node at a time; a second cannot be signed while one is active.
• A disbursement is a lump sum or a bounded recurring stream, released at a fixed date or by milestone acceptance; zero disbursements is valid.
• With multiple investors, each disbursement records how its amount splits across them.
• An investor split never names the investee; a node cannot fund its own tranche.
• Cap-table allocation is set at signing, may redistribute pre-existing holders, and always sums to exactly 10,000 basis points.
• While the contract is active, the cap table changes only through its MOVE_EQUITY milestones.
• Equity and investment movements are capital movements; they never enter the cash ledger and never contribute to any P&L view.

#Lifecycle

Every contract moves through the same four states, whether it is a Purchase, a Revenue Split, or an Investment: DRAFT while terms are written, SIGNED once every party has agreed, ACTIVE while it executes, TERMINATED when it completes or is cancelled. Transitions follow the sequential forward path — DRAFT to SIGNED, SIGNED to ACTIVE, ACTIVE to TERMINATED — and each is driven by an explicit contract-level event: signing, activation, termination. Milestones operate inside an ACTIVE contract and never move the lifecycle; a recurring period proposal marks a matured payment period and never moves it either.

The one exception to the forward path is pre-active cancellation: a SIGNED contract may be cancelled before it ever activates, moving SIGNED to TERMINATED directly. The cancellation is recorded — when it was cancelled, why, and that activation never occurred.

Signing a JOINT_VENTURE Revenue Split has a topology side effect: the contract-node is created atomically at SIGNED, with no later promotion step. Terminating a JOINT_VENTURE hands the created node into the standard node-termination flow, and that termination is blocked while an active Investment exists on the JV-created node — a block that applies equally to a pre-active cancellation, since the contract-node already exists at SIGNED. Termination closes the commitment but preserves its history.

Statements

• A Contract lifecycle includes Draft, Signed, Active, and Terminated.
• Transitions are sequential and driven by explicit contract events — signing, activation, termination.
• Milestones and recurring period proposals never move the contract lifecycle.
• A Signed Contract may be cancelled before activation — Signed to Terminated — with the cancellation recorded: when, why, and that activation never occurred.
• Signing a JOINT_VENTURE creates the contract-node atomically.
• Terminating a JOINT_VENTURE hands the contract-node into standard node termination, blocked while an active Investment exists on it.
• 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 — a reusable shape that can seed a new Draft; it is neither a Configuration Artifact nor a standalone contract.

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 structure that makes the agreement pattern reusable: the contract type, non-node commercial parameters, terms, milestone definitions with their structured effect parameters, the Investment disbursement schedule shape, the recurring payment shape (including an authored start date where present), and the Revenue Split variant shape. It strips parties and every node-bound reference: Offering bindings, wallet bindings, collection-point bindings, and investor or investee bindings. Applying one creates a new editable DRAFT Contract prefilled with the reusable shape; the new draft 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: contract type, non-node commercial parameters, terms, milestone definitions with their structured effect parameters, the Investment disbursement schedule shape, the recurring payment shape including an authored start date where present, and the Revenue Split variant shape.
• It removes parties and all node-bound references: Offering bindings, wallet bindings, collection-point bindings, and investor or investee bindings.
• Applying a Replicable Contract Format creates a new editable 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