Derived Deals & Contributor Entitlements

Where this sits in the alignment economy. Derivation is the Structure stage reaching across deal boundaries. The DMS guide documents a single deal's life: a typed DealPlan, a plan_hash the parties sign over, a lifecycle that runs to settlement. This page documents what the deal engine guarantees when deals relate: how a new deal descends from an existing one, how a party's signature can extend forward to deals that don't exist yet, and how contributors to a parent deal hold positions over the revenues of the deals derived from it.

Read the DMS guide first — this page assumes its vocabulary (DealPlan, plan_hash, parties, proposer, periodic phases) and never restates its lifecycle. What follows is the platform's behavioural model for derivation and entitlements: what the engine guarantees, and when.

Derived deals — descent, not supersession

A deal may be created from an existing deal. The existing deal is the parent; the new deal is derived from it, and carries a reference to the parent's id from the moment it exists.

This is a different relationship from the one counterOfferDeal creates. A counter-offer supersedes: the parent moves to CounterOffered and the child replaces it — one agreement continued under new terms. A derived deal descends: the parent keeps running (or completes) on its own terms, entirely unaffected by the derived deal's existence, lifecycle, or fate.

   counterOfferDeal — supersession        derivation — descent

   ╭───────────────╮                      ╭──────────╮
   │    PARENT     │                      │  PARENT  │──► continues /
   │(COUNTEROFFERED│                      │ (ACTIVE) │    completes on
   │  = parked)    │                      ╰────┬─────╯    its own terms
   ╰───────┬───────╯                           │
           │ child replaces it                 │ declared derivation
           ▼                                   │ classes
   ╭───────────────╮                 ┌─────────┼─────────┐
   │     CHILD     │                 ▼         ▼         ▼
   │ (new terms,   │            ╭─────────╮╭─────────╮╭─────────╮
   │  new hash)    │            │DERIVED A││DERIVED B││DERIVED C│
   ╰───────────────╯            ╰─────────╯╰─────────╯╰─────────╯
   one agreement,               each an ordinary deal: own DealPlan,
   re-struck                    own plan_hash, own parties, own
                                lifecycle — plus a parent reference

In every respect the DMS guide documents, a derived deal is an ordinary deal. It has its own DealPlan and its own plan_hash; it is proposed, signed, activated, and settled through the same lifecycle; its plan validates at proposal time under the same rules. Derivation adds exactly two things: the descent reference, and the consent and entitlement semantics below. Descent is not conditionality — for deals that wait on other deals rather than descend from them, see Dependent deals below.

Dependent deals — conditioned, not derived

What a dependency is. A deal's plan may declare a dependency on another deal: a condition that gates the dependent deal's activation — or a specific step, or a period's settlement — on the referenced deal reaching a stated status (Active, Completed, or a given period settled). All three gate forms behave the same way: a deal that activates only once the deal it references is Active; a step that runs only once the referenced deal is Completed; a period that settles only after the referenced deal's corresponding period has settled. The distinction from derivation is one line: derivation is ancestry — where a deal comes from; dependency is conditionality — what a deal waits on. The two are orthogonal: a deal may be derived from one deal and dependent on another, either alone, or neither. In every other respect a dependent deal is an ordinary deal — what the dependency changes is when the gated part of its lifecycle may proceed.

Declared and locked. Dependencies are declared in the plan and validated at proposal time: the referenced deal must exist, and the referenced status must be reachable — a condition that could never be satisfied is rejected before any party can sign. Because the declaration lives in the plan, it is covered by plan_hash: every party signs over exactly what their deal waits on. The same immutability posture as everything else in the plan applies — a dependency is superseded by counter-offer, never edited in place — exactly as a derivation-class declaration or an entitlement grant is.

Dependency failure is a defined outcome. If the referenced deal reaches a terminal state that makes the condition unsatisfiable — Cancelled, Defaulted, FailedAfterPartialExecution, or Rejected before signing — the dependent deal does not hang. The plan's declared failure handling applies: the dependent deal is cancelled with cleanup, or proceeds under a declared fallback branch — per what the parties signed, in every case. The failure event, the evaluation of the condition, and the resulting transition are written to the audit trail like any other deal events — the dependent deal's history shows what it waited on, what happened, and how it resolved.

Derivation classes are declared, not open-ended

A parent does not accept arbitrary descendants. Its plan declares which classes of derived deals may descend from it, identified by deal kind and purpose — for example, an issuance deal might declare that distribution deals and service agreements may descend from it, and nothing else. A deal proposed as derived from a parent outside the parent's declared classes is rejected at proposal time, before any party can sign — the same validation posture as every other plan check.

Because the declaration lives in the parent's plan, it is covered by the parent's plan_hash: every party that signed the parent signed over exactly which classes of deals may descend from it. The declaration is locked with the plan and cannot be widened after signing — only a subsequent deal can extend it.

Standing consent

Ordinarily, joining any deal requires a party's signature. A party's signature on a parent deal, however, may include standing consent to designated classes of derived deals — consent given once, at parent signing, that covers enrolment in deals that don't exist yet.

Standing consent is tightly bounded. The engine guarantees:

• Scope is the declared classes, only. Consent attaches to specific derivation classes named at signing. It never extends to other classes, other parents, or the platform generally.
• No enrolment outside scope. A party is never enrolled in a derived deal outside the scope of the consent they gave. A derived deal in an unconsented class needs their ordinary signature, exactly as the DMS lifecycle requires.
• No less favourable terms. Enrolment under standing consent is valid only where the terms applying to that party in the derived deal are no less favourable than the terms applying to them in the parent. Standing consent lets a party skip re-signing equivalent-or-better terms; it is never a mechanism for binding them to worse ones.
• Everything is audited. The consent, its scope, and each enrolment made under it are written to the audit trail like any other deal event — queryable on both the parent and the derived deal.

Absent standing consent, nothing changes: a derived deal collects ordinary signatures from its parties like any other deal.

Contributor entitlements

A parent deal's plan may grant its contributors — parties whose contribution the plan recognises — entitlements over defined revenue bases of derived deals. For example: a party who contributed the underlying asset in the parent holds 2% of a defined revenue base of every distribution deal derived from it.

Two definitions carry the whole model:

• A revenue base is a defined subset of a derived deal's cashflows, named in the plan that grants the entitlement — "gross distribution receipts", "net service revenues". Entitlements are always expressed against a defined base, never against "the deal" at large.
• An entitlement is a recorded beneficiary position, not a participation. The holder need not be — and typically is not — a party to the derived deal. They do not sign it, they hold no lifecycle rights over it, and they take no obligations under it. What they hold is a claim over a defined slice of its revenue base, recorded and settled by the engine.

This distinction does real work. A derived deal's parties negotiate and run their deal normally; the entitlement holders' positions ride alongside as recorded beneficiaries, resolved at settlement (below) without a seat at the table.

Crystallisation

An entitlement granted in a parent's plan is, until a derived deal exists, a standing grant — terms waiting for a deal to attach to. It crystallises when the derived deal is created: at that moment, the entitlement's terms — holder, revenue base, rate, duration — fix against that specific derived deal.

  parent deal ────────────────────────────── Completed / Cancelled
     │                                                / Defaulted
     │ plan grants: contributor C holds 2% of the
     │ "distribution receipts" base of class-K derived deals
     │
     ├──► derived deal 1 created ● crystallises against deal 1
     │        (holder C · receipts base · 2% · granted duration)
     │
     ├──► derived deal 2 created ● a second, independent
     │                             crystallisation against deal 2
     ●
   parent ends. Both crystallised entitlements continue —
   they are bound to their derived deals, not to the parent.

Each crystallisation is independent: an entitlement crystallised against derived deal 1 says nothing about derived deal 2, which gets its own crystallisation on its own creation.

Crystallised entitlements survive the parent. The parent's completion, cancellation, or default does not end entitlements already crystallised under it — from crystallisation onward, the entitlement's life is tied to the derived deal it fixed against, not to the parent that granted it. However the parent ends, its ending never reaches back into positions that have already fixed.

Well-formedness — the 100% rule and the cascade

Entitlements against any one revenue base must be jointly satisfiable. The engine enforces this as a plan-validity rule: the aggregate of entitlements declared against any defined revenue base cannot exceed 100% of that base.

Because entitlements can accumulate — a parent granting several contributors positions over the same base of the same derivation classes — every plan that declares entitlements also declares a cascade rule for how the aggregate resolves:

• Priority order — entitlements rank; each is satisfied in full before the next, and the base exhausting mid-cascade cuts off the remainder.
• Pro-rata normalisation — entitlements scale proportionally so the aggregate never exceeds the base.

Both are validated at proposal time. A plan whose entitlements could exceed a base — or that declares entitlements without a cascade rule to resolve them — is rejected before any party can sign, consistent with the engine's proposal-time validation posture: malformed economics are a validation failure, not a settlement-day surprise.

Temporal binding — the base definition locks with the plan

An entitlement binds to the revenue-base definition as it stands when the deal granting it is proposed and locked. If anyone later redefines the base — in a subsequent deal, a template revision, or anywhere else — the redefinition does not retroactively alter an entitlement locked against the earlier definition.

This is the same immutability principle as plan_hash, applied to the economics: what a party signed is what binds, and later amendment cannot reach back into a locked artefact. An entitlement holder can always answer "2% of what, exactly?" by reading the base definition as at their grant's lock — and the answer never changes underneath them.

Variation only by subsequent deal

A crystallised entitlement is varied or extinguished only by a new deal signed by the affected holder. It is never varied by:

• amendment of the parent deal,
• amendment of the derived deal it crystallised against, or
• amendment of platform terms.

This is the DMS's supersession principle extended across deal boundaries: just as a locked plan is superseded, never modified, a crystallised entitlement is re-struck by a fresh signed deal, never edited in place. The holder's signature on the varying deal is the only path — no combination of other parties, on any deal, can move a holder's position without them.

Settlement precondition — one gate, not two ledgers

A derived deal that carries entitlements cannot reach Completed until its entitlement obligations for the settled periods are resolved in the entitlement register. Settlement of the deal and resolution of its entitlements are one gate, not two ledgers: there is no state in which the derived deal has settled "for its parties" while what it owes its entitlement holders remains open on the side.

For deals with periodic phases, this holds period by period — each settled period's entitlement obligations resolve as part of that period settling, and the deal reaches Completed only once every period's entitlement obligations are resolved. A derived deal short of that is simply not done, in exactly the sense the deal lifecycle means by not done.

The entitlement register

Entitlements are recorded the way everything else in the deal engine is recorded: as deal events and frames, like every other deal transition. The register is not a separate system with its own semantics — it is the deal audit trail, extended to cross-deal positions. Written to it, like any other deal event:

• the grant (in the parent's plan, at lock),
• each standing consent, its scope, and each enrolment under it,
• each crystallisation (on derived-deal creation),
• each distribution made against a crystallised entitlement, and
• each variation or extinguishment (via the subsequent deal that effected it).

The register is queryable per deal — everything granted by, or crystallised against, a given deal — and per holder — every position a given holder holds, across all deals. A holder who was never party to any derived deal still has a complete, auditable view of every position they hold and every distribution made against it.

Illustrative shape — derivation and entitlements surface through the same dealFlow namespace as the rest of the deal machinery (fields shown are indicative, not a contract):

query DescentAndPositions {
  dealFlow {
    deal(id: "DEAL-parent") {
      derivedDeals { id status }                 # descent, parent-side
      entitlementsGranted {                      # grants in this plan
        holder { entityId } basis rate status    # status: standing | crystallised
      }
    }
    entitlementsAsHolder {                       # register, holder-side
      dealId basis rate crystallisedAt
      distributions { periodIndex amount }
    }
  }
}

Pitfalls

Reference

See also

• DMS (Deal Management System) — the single-deal machinery this page builds on: the DealPlan, plan_hash, proposal-time validation, and the lifecycle that derivation extends across deal boundaries.
• Contracts & Obligations — the on-chain artifact shapes a derived deal's plan compiles down to, like any other deal's.
• Payments — the settlement rail that distributions against crystallised entitlements run over.