# Streembit Deed Protocol Working Draft — Version 0.1 ## 1. Purpose, Scope and Participants ### 1.1 Purpose The Streembit Deed Protocol provides a durable, verifiable and confidential record of signed documents concerning intentions, agreements and rights. Its primary use cases are: - **Wills and inheritance declarations:** preserving a person’s instructions, establishing their recorded history and enabling authorized access. - **Property deeds:** recording signed instruments concerning identified property or rights, together with associated payment conditions and evidence of completion. The protocol supports real-world assets without requiring their tokenization. ### 1.2 Scope The protocol covers identity attestations, document signatures, blockchain anchoring, deed history, on-chain encrypted preservation, Accountable Node key custody, authorized access and optional payment. A deed comprises a document and its associated protocol records. Each registered deed MUST bind the exact document to its authorizations and attestations. The protocol distinguishes: - What a person declared or agreed. - What another participant attested. - What the blockchain recorded. - What payment or external completion evidence was subsequently supplied. An anchor establishes a commitment to a document within the recorded blockchain history. It MUST NOT be represented as independently proving the document’s signing date, a person’s capacity or completion of an external ownership transfer. National property registers and external estate-administration processes are outside scope. Their documents or confirmations MAY be referenced as supporting evidence. ### 1.3 Participants **Deed parties** create, review and sign documents. Depending on the deed type, they include a testator, transferor, transferee or other declarant. **Accountable Nodes** verify identities and issue signed attestations identifying the subject, verification method, relevant deed and scope of the attestation. Identity verification MUST be distinguishable from witnessing a signature or attesting another fact. Attestations and disclosures record the Accountable Node’s actions and verification. **Witnesses**, where required by the deed’s policy, sign witness statements bound to the relevant deed. Witness statements are distinct from Accountable Node attestations. **Beneficiaries, executors and authorized recipients** request access through an assigned Accountable Node under the deed’s access policy. Being named as a beneficiary does not itself grant immediate access. Assigned **Accountable Nodes** also hold the deed’s encryption key and provide authorized access. Each assigned Accountable Node holds a complete copy of the same key and can decrypt the deed independently. Key custody and access handling are distinct from identity attestation. ### 1.4 Confidentiality, Storage and Access The complete encrypted deed document MUST be stored on-chain in the contract’s KV store. A document hash or external storage reference alone MUST NOT satisfy this requirement. Each deed MUST have its own encryption key. Every assigned Accountable Node MUST receive and securely retain a complete copy of that key. Decryption MUST NOT depend on access to the author’s device, account or private key. The encryption key MUST NOT be publicly exposed on-chain. Registration completes only when the encrypted document is recorded on-chain and every assigned Accountable Node has signed an on-chain acknowledgement of key receipt bound to the deed. Key delivery MUST be confidential; its technical mechanism will be specified later. An assigned Accountable Node handles a recipient’s access request as one workflow: locate the deed, verify the recipient’s identity and entitlement under the deed’s policy, and securely provide authorized access. A recipient need not have had a blockchain account when the deed was registered. A separate private-discovery mechanism is deferred beyond this version. **Disclosure conditions.** Access MUST satisfy the conditions defined in the deed’s policy and the recipient-verification requirements. Supported conditions include an instruction of the grantor, a specified date, a required counter-signature, an attested external fact such as death, or a recorded judicial order. Each assigned Accountable Node can decrypt independently and MUST protect the key and enforce the deed’s access and disclosure conditions. Disclosure authorization and the Accountable Node’s confirmation of providing access MUST be recorded as separate on-chain events without exposing the encryption key or document contents. Public records MUST minimize disclosure of identities, beneficiary relationships, property details and other sensitive metadata. **Continuity dependency.** Each deed MUST name at least two Accountable Nodes, each holding the complete encryption key. A deed’s preservation and key custody MUST survive Accountable Node turnover. Key continuity and operational reassignment are dependencies of the Accountable Node protocol. ### 1.5 Deed Policy Each deed MUST carry a policy fixed at registration except as provided below. The policy defines: - Required signatories and their roles. - Required witnesses. - Required attestation level for each role. - Assigned Accountable Nodes. - Authorized recipients and their access rights. - Disclosure conditions. - Supersession and revocation authority. - Payment terms, where applicable. The contract MUST enforce the policy’s machine-checkable requirements. The policy records the applicable formalities and required attestations; it does not independently establish legal validity. Operational Accountable Node assignments MAY change through the continuity process referenced in Section 1.4 without replacing the deed or changing its substantive policy terms. Such replacements MUST be recorded on-chain and preserve the deed’s access conditions and key-custody requirements. ### 1.6 Deed History and Supersession Each deed is registered as a separate document, not as a version of an existing document. Registered records MUST be append-only. A new deed MAY supersede an earlier deed through an explicitly authorized instruction linking the two deeds, subject to the applicable deed type and policy. Revocation MUST likewise be explicitly authorized and identify the affected deed. A later timestamp alone MUST NOT establish supersession. The recorded status MUST distinguish current deeds from superseded or revoked deeds. Earlier encrypted deeds and their history remain preserved as evidence but MUST NOT be presented as current. Authorization rules MUST depend on deed type: replacing a will and superseding a deed signed by multiple parties require different treatment. ### 1.7 Payments Deeds MAY include direct, escrowed or staged SBRIT payments. Each payment obligation MUST identify the applicable deed, payer, recipient, amount and release conditions. Locked-payment terms MUST identify the required party signers and refund treatment under Section 3.5. External payments MAY be supported through identified attestations. Such attestations MUST remain distinguishable from payments executed by the protocol. ### 1.8 Verification An authorized verifier MUST be able to check document integrity, signatures, attestations, recorded deed history and relevant payment evidence without relying solely on the continuing availability or assertions of the original service provider. ### 1.9 Out of Scope for Version 1 The following capabilities are outside this version of the protocol: - **Adjudication, penalties and enforcement.** The protocol records statements and actions; disputes, liability and remedies are external. - **Separate private-discovery infrastructure.** Locating a deed, verifying the recipient’s identity and entitlement, and providing authorized access form one Accountable Node workflow. - **Threshold cryptography and key-share reconstruction.** Each assigned Accountable Node holds a complete copy of the deed’s encryption key, as specified in Section 1.4. - **Accountable Node lifecycle management.** This belongs to the Accountable Node protocol. - **Document editing and version management.** The protocol registers completed deeds. A replacement is a separate deed linked by an authorized supersession instruction, as specified in Section 1.6. - **National property-register integration.** The protocol records signed instruments and supporting evidence; it does not update external registers or independently establish legal title. - **Probate and estate administration.** Locating assets, administering estates and carrying out transfers of real-world property remain external processes. - **Legal drafting and automated legal determinations.** The protocol preserves declarations and attestations; it does not draft legally sufficient instruments or independently determine capacity, legal validity or ownership disputes. Relevant external decisions MAY be recorded as evidence. - **Mandatory asset tokenization.** Real-world property need not be represented by a blockchain token to be identified in a deed. - **External payment execution.** Bank payments MAY be evidenced by attestations, but the protocol does not operate banking systems or execute those payments. Storage limits and encryption specifications remain implementation details to be defined in this protocol; they are not excluded by this section. ## 2. Definitions and Identifiers ### 2.1 Definitions **Deed** — A registered record comprising one encrypted document, its policy, the signatures and attestations bound to it, and its on-chain history. The registered document is never edited; supersession, revocation and subsequent events are recorded through append-only records (Section 1.6). Operational Accountable Node assignments may change as provided in Section 1.5. **Document** — The complete instrument as signed by the parties (for example a will or a transfer deed), in its final form. The document exists in two forms: the **plaintext**, known to the parties and disclosed recipients, and the **ciphertext**, stored on-chain. **Grantor** — The deed party who registers the deed: the testator of a will, or the transferor of a property deed. Supersession and revocation require the authorizations specified by the deed's policy; registration by the grantor does not confer unilateral authority to revoke or supersede a deed signed by multiple parties. **Deed policy** — The requirements and rights attached to a deed, fixed at registration except for the operational Accountable Node reassignment permitted by Section 1.5. The policy is expressed as data whose machine-checkable requirements the contract enforces. **Role** — A named function a participant has in a deed: grantor, party, witness, executor, recipient or assigned Accountable Node. **Attestation** — A signed statement by an Accountable Node asserting one fact about one subject in relation to one deed: an identity verification, a witnessed signature, or an external fact such as death or completion. Only Accountable Nodes issue attestations; witnesses sign witness statements (Section 1.3), which are not attestations. An attestation identifies its kind, subject, statement, assurance level, method, attestor and the deed it concerns. **Acknowledgement** — An assigned Accountable Node's signed on-chain confirmation, bound to the deed, that it holds the deed's encryption key (Section 1.4). **Disclosure** — The authorized provision of the document plaintext to a recipient. It consists of two recorded events: the **disclosure authorization**, which records that the policy's disclosure and recipient-entitlement requirements are satisfied, and the **access confirmation**, by which the Accountable Node records that access was provided. **Supersession** — An authorized instruction recording that a later deed replaces an earlier one. **Revocation** — An authorized instruction recording that a deed is no longer current, with no replacement. **Completion evidence** — A recorded reference to an external document or confirmation (for example a land-registry entry or a bank payment) attached to a deed as evidence. Recording that evidence does not independently establish legal effect. ### 2.2 Identifiers `H(x)` is the lowercase hex of `blake2b256` over the UTF-8 canonical JSON serialization of a validated field object `x`. `Hbytes(b)` is the lowercase hex of `blake2b256` over the exact byte sequence `b`, without JSON serialization, text conversion or normalization. Each hash is 32 bytes, represented by 64 lowercase hexadecimal characters without a `0x` prefix. | Identifier | Definition | |---|---| | `documentHash` | `Hbytes(plaintext bytes)` — binds the exact final document, including any signatures contained within it | | `ciphertextHash` | `Hbytes(ciphertext bytes)` — binds the exact encrypted document stored on-chain | | `policyHash` | `H(policy)` — binds the policy as registered | | `deedId` | `H({ chainId, contract, grantor, policyHash, documentHash, ciphertextHash })` | | `attestationId` | `H({ deedId, attestor, kind, subject, statement, assuranceLevel, method })` — `statement` is the structured object defined in Section 4.1 and binds every attested detail (keys, addresses, evidence hashes, authority scope); the signature is excluded | | `disclosureId` | `H({ deedId, recipient, sequence })` — identifies one disclosure authorization; `recipient` is the policy-defined recipient reference and `sequence` is the next unused value read and supplied by the signer | | `linkId` | `H({ fromDeedId, toDeedId, kind })` for supersession; `H({ fromDeedId, kind })` for revocation, with `toDeedId` omitted | **Attestation uniqueness.** The contract MUST maintain at most one active attestation per `(deedId, attestor, kind, subject, statement.name)`, where `statement.name` is the fact or binding name defined in Section 4.1. A later attestation for the same tuple MUST explicitly replace the active attestation or follow its explicit withdrawal. An attestation MAY be withdrawn or replaced only by the Accountable Node that issued it (Section 4.5). Withdrawal and replacement records MUST identify the affected `attestationId` and the authorizing party. Earlier attestations and their withdrawal or replacement history MUST remain preserved; they MUST NOT be overwritten or presented as active. Replacement MUST deactivate the earlier entry and activate its replacement atomically. **Recipient reference and disclosure sequence.** `recipient` is a stable reference defined by the deed's policy, not a blockchain address. At disclosure, the assigned Accountable Node MUST verify that the requesting person is the recipient identified by that reference and is entitled to the requested access. A blockchain account is not required for receipt of the document. For each `(deedId, recipient)`, the next unused `sequence` starts at `0`. The signer reads that value and includes it in the signed disclosure authorization. The contract MUST reject the call unless the supplied value equals the current next unused value. On successful authorization, the contract MUST record the disclosure and increment the sequence atomically. A failed call MUST NOT consume the sequence; an access confirmation refers to the existing disclosure and does not allocate another sequence. Used values MUST NOT be reused. For a supersession link, `fromDeedId` identifies the earlier deed, `toDeedId` identifies the replacement and `kind` is `SUPERSEDE`. For revocation, `fromDeedId` identifies the revoked deed and `kind` is `REVOKE`. **Link uniqueness.** A deed MAY have at most one outgoing supersession or revocation link in total. Once either link has been recorded, the contract MUST reject any further outgoing link from that deed. Subsequent replacement or revocation acts on the current replacement deed, subject to its policy. Link creation and the affected deed's status change MUST be atomic. A `deedId` binds the exact document, its ciphertext, its registered policy and its grantor. Changing any of those inputs produces a different identifier. Permitted operational Accountable Node reassignment is recorded in the deed's history and does not rewrite the registered policy hash or deed identifier. The `chainId` and `contract` fields bind the deed identifier to its network and contract. Every protocol signature also explicitly binds both fields as specified in Section 2.3. **Canonical form.** Structured data uses the shared Streembit canonical-form conventions. This protocol defines the accepted deed fields and enum values; unknown fields and invalid values MUST be rejected. Hashes bind the validated fields specified above. Optional fields are omitted when unused, and arrays retain their defined order. Document and ciphertext hashes use exact bytes through `Hbytes`, without text normalization or JSON serialization. The ciphertext's hexadecimal representation is specified in Section 6.2. ### 2.3 Signed Messages Every protocol signature MUST be over `H(message)`, where the message contains `chainId`, `contract`, the `deedId` it concerns, a `purpose` string and the complete action payload. A signature made for one purpose is invalid for any other. Signatures MUST be excluded from the payload they sign. The purpose values are `SIGN_DOCUMENT`, `WITNESS`, `ATTEST`, `ACKNOWLEDGE_KEY`, `AUTHORIZE_DISCLOSURE`, `CONFIRM_ACCESS`, `SUPERSEDE`, `REVOKE`, `CANCEL`, `COMPLETION` and `RELEASE_PAYMENT`. The signed payload MUST bind all fields on which the authorized action depends. In particular: - Document and witness authorizations bind the signer's role and the statement being signed or witnessed. - Attestations bind the complete attestation fields identified in Section 2.2. Withdrawal and replacement authorizations use the `ATTEST` purpose with an explicit action identifying withdrawal or replacement, the affected `attestationId` and, for replacement, the new attestation. These action fields MUST be included in the signed payload. - Key acknowledgements identify the assigned Accountable Node confirming custody of the key for that deed. - Disclosure authorizations bind the recipient, `disclosureId`, authorized access and the condition and supporting evidence relied upon. Access confirmations bind the same disclosure and recipient and identify the Accountable Node providing access. - Supersession binds both deed identifiers and the link kind. Revocation binds the affected deed and the revocation kind. Cancellation uses `CANCEL`, binds the pending deed and creates no supersession or revocation link. - Completion statements bind the referenced evidence and the fact it is submitted to support. - Payment-release signatures bind the deed, obligation, amount and destination under RELEASE_PAYMENT (Section 3.5). **Accountable Node reassignment.** The deed records authorized changes to its assigned nodes, identifying the previous and replacement nodes and the AN-protocol authorization relied upon. Reassignment preserves the registered deed, access policy and key-custody requirements; the external dependency is stated in Section 1.4. **Instrument signatures and protocol signatures.** Signatures already contained in the final document are part of the document bytes. They are distinct from protocol signatures and are not required to sign `deedId`. The final document is completed first, then hashed and encrypted to derive `deedId`; subsequent `SIGN_DOCUMENT` protocol signatures authorize registration of that exact document and policy. Protocol signatures are stored as associated records, not inserted into the document whose hash they authorize. This avoids a circular dependency between the document and its identifier. Signatures by deed parties, witnesses and recipients use their personal signing keys, whose binding to the relevant identity and role MUST satisfy the deed's policy. Signatures by Accountable Nodes use the node's registered signing key. A valid signature alone does not grant authority: the contract MUST also verify the signer's required role and the policy conditions for the action. ## 3. Deed Types and Policy ### 3.1 Policy Content A deed policy is registered with the deed and is immutable except for operational Accountable Node reassignment under Section 1.5. It contains: | Element | Content | |---|---| | `deedType` | `WILL`, `PROPERTY_TRANSFER` or `GENERIC` | | `jurisdiction` | Reference to the legal system whose formalities the policy expresses | | `roles` | Each role with a unique recipient reference, the natural person or entity it denotes, its required identity-attestation level, and whether it must sign | | `witnesses` | Required number of witnesses and their required attestation level; `0` if none | | `assignedNodes` | Accountable Nodes holding the key; at least two distinct nodes, each ACTIVE at registration | | `grants` | Access grants (Section 3.2) | | `supersession` | The roles whose signatures are required to supersede or revoke, and the number required | | `payments` | Optional SBRIT payment obligations (Section 3.5) | | `completion` | Which completion-evidence kinds may be attached and by which roles | The contract enforces every element it can check: signatures of signing roles, witness count, attestation levels, assigned-node acknowledgements, grant conditions, supersession authority and payment execution. It does not interpret the document. ### 3.2 Access Grants and Disclosure Conditions Each grant MUST have a `grantId` unique within the deed's policy and a `scope` of `ACTIVE` or `HISTORICAL`. `ACTIVE` grants authorize disclosure only while the deed is ACTIVE; `HISTORICAL` grants authorize disclosure only while it is SUPERSEDED or REVOKED (Section 5.6). A grant names one recipient reference, what is disclosed (`DOCUMENT` or `OWN_COPY`), and a non-empty list of conditions that MUST ALL hold. A recipient MAY hold several grants; disclosure is authorized when ANY one of its grants is satisfied. The disclosure authorization MUST identify the `grantId` relied upon. `DOCUMENT` grants access to the complete document plaintext. `OWN_COPY` also grants access to the complete document plaintext, specifically for a principal party's own copy; it does not denote a different or redacted document. | Condition | Satisfied when | |---|---| | `GRANTOR_INSTRUCTION` | The grantor has signed a disclosure authorization for this recipient and grant | | `DATE` | `blockTimestamp ≥ date` | | `COUNTER_SIGNATURE` | Every role listed in the condition has signed the deed | | `ATTESTED_FACT` | An active attestation of kind `FACT`, with the statement named in the condition (for example `DEATH_OF_GRANTOR`), exists for the relevant subject and deed from an Accountable Node named in the condition | | `JUDICIAL_ORDER` | The named AN records that it has seen the order identified by documentHash and relies on it for disclosure to this recipient under this grant. The chain checks the AN signature and bindings, not the order's authenticity or legal effect | **Preparation access.** Parties and witnesses review the plaintext before signing. This happens off-chain among the parties before registration and is not a disclosure under this protocol; disclosure concerns only the registered deed. ### 3.3 Deed Types **WILL.** Roles: testator (grantor, signs); recipients (beneficiaries); an executor if the policy designates one. Witness number and attestation level are explicit policy choices. Identity attestation of the testator is mandatory. Grants typically use `ATTESTED_FACT` (`DEATH_OF_GRANTOR`) or `JUDICIAL_ORDER` for recipients, and `GRANTOR_INSTRUCTION` where the testator wishes to disclose during life. Supersession and revocation require the testator alone. Wills preserve bequest instructions for external administration; locked on-chain bequests are outside this version (Section 3.5). **PROPERTY_TRANSFER.** Roles: transferor (grantor, signs), transferee (signs); optional agents. Identity attestation of every principal party is mandatory. Each principal party holds an `OWN_COPY` grant with `COUNTER_SIGNATURE` of all principal parties as its condition; further grants are defined by the policy. For supersession and revocation, all principal parties MUST sign; no other authorization is permitted. Payments MAY be direct or escrowed SBRIT under Section 3.5, with release authorized by all principals and refunds on supersession or revocation. Completion evidence MAY include a registry entry, payment confirmation or completion attestation. **GENERIC.** Any signed declaration or agreement; roles, witnesses, grants and supersession authority are as the policy states, subject to Section 3.4. ### 3.4 Minimum Requirements and Consistency Every deed MUST name a grantor who signs; name at least two distinct assigned Accountable Nodes, each ACTIVE at registration; carry an identity attestation of the grantor; define at least one grant; and define supersession and revocation authority. Signature and witness counts MUST be counted per distinct attested person: multiple signatures from one person satisfy one requirement only. Every signer and witness whose signature is counted MUST have identity verification at the level required by the policy, evidenced by an Accountable Node attestation. An entity signs through an identified natural-person representative whose authority to act for that entity MUST also be attested by an Accountable Node. Using different keys or roles for the same person MUST NOT increase the count. A witness MUST NOT be a principal party or a recipient of the same deed. Registration MUST reject an internally inconsistent policy, including: - Grants or conditions referencing undefined roles or recipient references. - Duplicate `grantId` values or grants with no conditions. - A signature threshold exceeding the number of eligible distinct signers. - `COUNTER_SIGNATURE` naming a non-signing role. - Fewer than two distinct assigned nodes, or an assigned node that is not ACTIVE. - A payment naming an undefined payer or recipient, or undefined principal signers for locked payment release. - A payment lacking the authorization, funding or terms required by Section 3.5. ### 3.5 Payment Obligations Payments are optional SBRIT transfers associated with the deed. Death, completion and judicial-order attestations MUST NOT authorize payment. Each obligation or separately funded stage has a unique policy-defined `obligationId`, payer role and funding account, recipient reference, amount and mode: direct payment at activation or funds locked for later release. Each payer MUST sign a SIGN_DOCUMENT authorization binding the deed and the obligations funded. Sufficient balance alone does not authorize a debit. Direct payments execute at activation and are not reversed by later supersession or revocation. PROPERTY_TRANSFER and GENERIC deeds MAY lock funds at activation. The policy identifies all principal parties whose signatures are required for release. Both principals of a two-party transfer MUST sign; a single-grantor GENERIC deed requires the grantor's signature. Release requires the specified parties’ authorization. WILL deeds MUST NOT contain locked payments or on-chain bequests in this version. They preserve the testator's instructions for external administration; release must not depend on obtaining a deceased grantor's new signature. `releasePayment` requires an ACTIVE deed and RELEASE_PAYMENT signatures from every required principal. The signed message binds chainId, contract, deedId, obligationId, the exact remaining amount and destination address. An active ACCOUNT_BINDING must verify that destination. The full remaining amount is paid once and the obligation closes. Staged payments use separately funded obligation identifiers. Authorized supersession or revocation MUST refund every remaining locked amount to its original funding account atomically with the lifecycle change. Completed transfers remain recorded. Activation and funding follow Section 5.3. Refunds return to the original funding account; recipient payouts require verified destination accounts. ### 3.6 Jurisdiction and Formalities The protocol does not encode law. `jurisdiction` is a reference; witness and attestation requirements are how the grantor's advisers express that jurisdiction's formalities. The contract checks the policy's own requirements, nothing more. ## 4. Attestations and Identity ### 4.1 Attestation Kinds Every attestation carries `kind`, `subject`, a structured `statement`, `assuranceLevel`, `method`, `attestor` and `deedId`, and is signed under the `ATTEST` purpose (Section 2.3). The `statement` object always contains `name` and the fields listed for its kind; all of them are bound by `attestationId`. | Kind | Subject | `statement` fields | Asserts | |---|---|---|---| | `IDENTITY` | A role's recipient reference | `name` = `IDENTITY_BOUND`; `identityRef` (the node's verified-identity record hash); `signingKey` | The named person or entity has been verified at the stated level and is bound to `signingKey` | | `AUTHORITY` | A role denoting an entity | `name` = `AUTHORITY_GRANTED`; `entityRef`; `representativeIdentityRef`; `representativeSigningKey`; `permittedRoles[]`; `permittedActions[]` (purpose values); `evidenceHash` | The verified representative may act for the entity in the listed roles and actions | | `WITNESSED` | A signer's role | `name` = `SIGNATURE_WITNESSED`; `signerIdentityRef`; `documentHash` | The node observed the person sign the document. This attestation evidences a signature; it does not itself count as a witness's signature under the policy | | `ACCOUNT_BINDING` | A recipient reference | `name` = `ACCOUNT_BOUND`; `address`; `controlProofHash` | The recipient demonstrated control of `address` (by signing a challenge with its key) or explicitly authorized it in a signed instruction; the proof is identified by hash | | `FACT` | The deed | `name` = fact name (`DEATH_OF_GRANTOR`, `COMPLETION`, `JUDICIAL_ORDER_AUTHENTIC`, or a policy-defined name); `evidenceHash`; `relatedRecipient` and `relatedGrantId` mandatory for judicial disclosure and otherwise present for a specific grant | Records the external statement and evidence relied upon by the AN. The judicial name denotes the AN's assertion about the order it saw, not a blockchain determination of authenticity or legal effect | Uniqueness, withdrawal and replacement follow Section 2.2, with `statement.name` in the uniqueness key so that distinct facts about one deed coexist. ### 4.2 Assurance Levels A deed policy specifies the required assurance level for each role. Attestations record the level and verification method used under the shared Accountable Node identity and assurance specification. That specification defines the levels, verification procedures and whether one level satisfies another. The deed contract checks the policy's required level against the attestation. This protocol does not define general identity-verification procedures. The recorded level describes the verification performed, not an independent determination of legal validity. ### 4.3 Who May Attest Only Accountable Nodes that are `ACTIVE` at the time of attestation MAY attest. Any `ACTIVE` Accountable Node MAY issue `IDENTITY`, `AUTHORITY`, `WITNESSED` and `ACCOUNT_BINDING` attestations for a deed. `FACT` attestations used for disclosure MUST come from an AN named in the grant condition. Later node-status changes do not erase its statements. Explicit correction or withdrawal follows Section 4.5. An Accountable Node MUST NOT attest a deed in which it is a party, witness or recipient. ### 4.4 Identity Binding and Keys A natural-person role is bound to a signing key only through an active `IDENTITY` attestation. An entity role signs through a representative: the signature is accepted only if an active `IDENTITY` attestation binds the representative's key and an active `AUTHORITY` attestation names that representative, covers the role and the action's purpose value. `AUTHORITY` never substitutes for the representative's own identity verification. A protocol signature is accepted on-chain only if, at the block in which it is accepted, the required attestations are active. Once accepted, a signature remains recorded and valid regardless of later replacement or withdrawal of those attestations. A person MAY change key through a replacement `IDENTITY` attestation (Section 2.2). A recipient who only receives disclosure needs no key; identity is verified by the Accountable Node at disclosure (Section 1.4). A key and `IDENTITY` attestation are required where the recipient must sign. Receipt of SBRIT requires an active `ACCOUNT_BINDING` attestation for the destination address; the address need not be controlled by the recipient's own key if the recipient explicitly authorized it under Section 4.1. ### 4.5 Evidence, Corrections and Withdrawal Attestations are signed, dated statements, not protocol determinations that real-world facts are true. Every accepted attestation records its AN issuer, statement, evidence references and `acceptedAt = blockTimestamp`. Acceptance time does not independently prove when the external event occurred. The contract verifies signatures, authority and record integrity. An accepted attestation remains evidence of what its issuer stated, not confirmation by the chain that the external event occurred. Only the issuing AN may explicitly withdraw or replace its attestation. The signed action identifies the affected attestation and appends to history without erasing the original statement. Withdrawal prevents reliance on that attestation for new operations. Already accepted signatures, disclosures and completed transfers remain recorded and are not reversed. ## 5. Deed Lifecycle ### 5.1 States ```text PENDING ──activate──────▶ ACTIVE PENDING ──cancel/expire─▶ CANCELLED ACTIVE ──supersede─────▶ SUPERSEDED ACTIVE ──revoke────────▶ REVOKED ``` `PENDING` and `ACTIVE` are live states; `CANCELLED`, `SUPERSEDED` and `REVOKED` are terminal. Disclosure, attestation, completion evidence and payment release are events recorded against a deed; they never change its state. ### 5.2 Pending Registration `registerDeed` creates the deed in `PENDING` with its policy, ciphertext, `documentHash` and `ciphertextHash`, and records `createdAt = blockTimestamp`. It carries the grantor's `SIGN_DOCUMENT` signature together with the `IDENTITY` and, where applicable, `AUTHORITY` attestations required to accept that signature under Section 4.4. The contract MUST validate and accept those attestations before accepting the signature, within the same atomic registration call. Failure of either step MUST reject the whole call. While `PENDING`, the remaining signing roles' `SIGN_DOCUMENT` signatures, witness signatures (`WITNESS`), required attestations (`IDENTITY`, `AUTHORITY`, `WITNESSED`) and `ACKNOWLEDGE_KEY` from every assigned Accountable Node are collected as recorded transactions. Required identity and authority attestations MUST be active before the corresponding signature is accepted; these items are not accepted in arbitrary order. A `PENDING` deed is not disclosable, cannot be superseded or revoked, is not current for any purpose; payment funding follows Section 5.3. ### 5.3 Activation `activateDeed` MAY be called by any signing role only while the deed is `PENDING` and `blockTimestamp < createdAt + PENDING_TTL_MS`. Activation checks the policy's registration requirements; future disclosure conditions, such as death of the grantor, are not activation requirements. In one atomic call the contract MUST verify: - All required party and witness signatures are present and counted per distinct attested person (Section 3.4). - All attestations required for registration are active at the required assurance levels. - There are at least two distinct assigned Accountable Nodes; every assigned node is currently ACTIVE and has acknowledged key receipt. - All payers' authorizations are present and their balances cover their aggregate obligations. - Every direct-payment destination has the active `ACCOUNT_BINDING` required by Section 4.4. `activateDeed` MAY additionally carry `supersedes: fromDeedId`. If supplied, the contract MUST verify the earlier deed's required `SUPERSEDE` signatures binding both deed identifiers, that the earlier deed is ACTIVE, that both deeds have the same `deedType`, that the new deed has no incoming link, that the earlier deed has no outgoing link, and that the identifiers differ. For a WILL, both deeds MUST have the same grantor. A replacement WILL MUST use this activation path rather than separate activation followed by linking. The call executes direct payments, locks locked payments, records `activatedAt = blockTimestamp` and sets the new deed ACTIVE. When `supersedes` is supplied, the same atomic call also records the supersession link, sets the earlier deed SUPERSEDED and refunds its remaining locked funds under Section 3.5. No intermediate state with both deeds ACTIVE is committed. Any failed check or payment operation fails the whole call with no state change. Registration completes at this activation step. Creating the pending record does not execute or fund payments. Each payer authorizes and funds its aggregate obligations, including every stage, as part of this atomic activation. ### 5.4 Cancellation of Pending Registration A `PENDING` deed is cancelled, becoming `CANCELLED`, by any of: a `CANCEL` signature from the grantor; a `CANCEL` signature from any signing role that has already signed (a party may withdraw before activation); or a permissionless `expireDeed` call once `blockTimestamp ≥ createdAt + PENDING_TTL_MS`, where `PENDING_TTL_MS = 2592000000` (30 days). Activation MUST be rejected at or after that deadline even if no one has called `expireDeed`. Cancellation creates no `linkId` and makes no payment transfer. The ciphertext and collected records remain on-chain as history and are never disclosable under this protocol. ### 5.5 Active Deed and Disclosure An `ACTIVE` deed is the current deed. Disclosure (Section 1.4) MAY occur any number of times: each `AUTHORIZE_DISCLOSURE` records the applicable `ACTIVE`-scope `grantId` and the conditions found satisfied; each `CONFIRM_ACCESS` records that an assigned node provided access. The deed remains ACTIVE. Locked payments require the parties' signed release instruction under Section 3.5, once per obligation or funded stage. Disclosure grants and FACT attestations do not authorize payment. ### 5.6 Supersession and Revocation For WILL replacements, supersession occurs within `activateDeed` as specified in Section 5.3; a separate `supersedeDeed` call MUST be rejected. For other deed types, the atomic activation path is also available, or `supersedeDeed(fromDeedId, toDeedId)` requires the `SUPERSEDE` signatures the policy of the earlier deed demands, an ACTIVE earlier deed, an ACTIVE later deed with the same `deedType` and no incoming link, and no existing outgoing link from the earlier deed. The contract MUST reject `fromDeedId == toDeedId`. For a WILL, both deeds MUST have the same grantor. `revokeDeed(deedId)` requires the policy's `REVOKE` signatures and an ACTIVE deed. Both operations record the link (Section 2.2), set the terminal state and refund all remaining locked funds to their funding accounts (Section 3.5) atomically. A SUPERSEDED or REVOKED deed remains fully preserved. Its ACTIVE-scope grants no longer authorize new disclosure. Historical access MUST rely on a HISTORICAL-scope grant explicitly included in the registered policy under Section 3.2; terminal status MUST NOT create new access rights. A historical grant MUST require a `JUDICIAL_ORDER` condition satisfied for that deed or a `GRANTOR_INSTRUCTION` by the grantor while living. For a WILL, the policy MAY alternatively provide a historical grant to the named executor requiring `ATTESTED_FACT` with `DEATH_OF_GRANTOR`. Every historical disclosure MUST satisfy all conditions of the selected grant and be recorded like any other disclosure. With no applicable historical grant, disclosure is not authorized. ### 5.7 Completion Evidence `attachCompletion` records a `COMPLETION` statement (Section 2.3) from a role permitted by the policy's completion element, identifying the evidence by hash and the fact it supports. It MAY be attached to an ACTIVE, SUPERSEDED or REVOKED deed. It changes neither the document nor the deed state and establishes no legal title; it is a dated, signed reference. An AN completion attestation is a separate evidence record and MAY support disclosure where the policy permits. Neither it nor a party completion statement authorizes payment. ### 5.8 Effect of Attestation Withdrawal Withdrawal of an attestation never changes a deed's state or reverses recorded events (Section 4.5). Its forward effect is: - On a PENDING deed, withdrawal of an attestation required for registration blocks activation until that requirement is satisfied by an active attestation. - In any state permitting an operation, new signatures require the active IDENTITY and AUTHORITY attestations specified in Section 4.4. Withdrawal prevents further signature acceptance relying on that attestation; a different active attestation may satisfy the requirement if permitted by the policy. - New disclosures, including historical access, must recheck the FACT statements relied upon. Withdrawn statements cannot support new disclosure. Payments require party signatures and destination verification, never FACT-based release. - Before providing plaintext under an existing authorization, the assigned Accountable Node MUST recheck the applicable disclosure conditions, including that required FACT attestations remain active. Previously issued authorization does not permit a new delivery after those conditions cease to hold. Confirmation of access already provided records that past delivery. - Disclosures, payments, accepted signatures and links already recorded stand. ## 6. Contract Interface and Storage ### 6.1 Contract and Methods One system contract, `deed_v1`, is to be deployed from `node/smart-contracts/deed/deed_v1.ts` and registered in ContractFiles. Methods follow `(tx, params, cid) => Promise`. The contract uses the trusted blockTimestamp provided by the contract execution interface. Every call is a CONTRACT_CALL in SBRIT with `tx.amount = '0'`. Authorized BalanceChange entries implement payments under the shared contract execution standard. Reads for verification are permitted, but required signatures and authority must be verified before changes are applied. | Method | Caller | Purpose verified | Effect | |---|---|---|---| | `registerDeed` | grantor | SIGN_DOCUMENT, ATTEST | Creates pending record with required grantor attestations | | `signDeed` | signing role | SIGN_DOCUMENT | Records party signature while pending | | `witnessDeed` | witness | WITNESS | Records witness signature while pending | | `attest` | issuing AN | ATTEST | Records, replaces or withdraws its statement | | `acknowledgeKey` | assigned AN | ACKNOWLEDGE_KEY | Records key receipt | | `activateDeed` | signing role | SUPERSEDE when replacing | Activates, funds payments and optionally supersedes atomically | | `cancelDeed` | grantor or signed role | CANCEL | Cancels pending deed | | `expireDeed` | anyone | — | Cancels expired pending deed | | `authorizeDisclosure` | anyone submitting required authorizations | AUTHORIZE_DISCLOSURE | Records AN verification and applicable grant | | `confirmAccess` | assigned AN | CONFIRM_ACCESS | Records access provided | | `releasePayment` | anyone submitting all required party signatures | RELEASE_PAYMENT | Releases obligation under Section 3.5 | | `supersedeDeed` | per earlier policy | SUPERSEDE | Supersedes and refunds; unavailable for WILL | | `revokeDeed` | per policy | REVOKE | Revokes and refunds | | `attachCompletion` | permitted role | COMPLETION | Records evidence | | `reassignNode` | per AN protocol | AN protocol authorization | Records operational custodian replacement | Successful calls return relevant identifiers and status. Execution and failure handling follow the shared contract execution standard. An assigned AN signs each disclosure authorization, binding deedId, recipient reference, grantId, sequence, verification performed and evidence relied upon. The chain verifies the AN's signature and policy authority, not the truth of external evidence. GRANTOR_INSTRUCTION additionally requires the grantor's signature. Recipients need no key merely to receive plaintext. Each obligation or funded stage has a unique policy-defined obligationId. `messageHash = H(message)` identifies an exact signed action. Hashes follow Section 2.2. ### 6.2 Document Storage Ciphertext is stored at `doc/` as lowercase hex without 0x. Decoding stored hex reproduces exactly the bytes bound by ciphertextHash. MAX_CIPHERTEXT_BYTES is 262144 (256 KiB), measured on decoded ciphertext. Registration rejects malformed encoding, hash mismatch or excess size. Ciphertext is immutable. Large attachments may be referenced by hash and retained externally, outside the preservation guarantee; the complete deed document itself remains on-chain. ### 6.3 Storage Layout Keys are relative to `sc//kv/`; variable components follow the shared storage-key encoding convention. | Key | Value | |---|---| | `deed/` | Grantor, hashes, status, timestamps and outgoing link | | `policy/` | Registered policy | | `doc/` | Ciphertext hex | | `sig///` | Signed action, role and acceptance record | | `att/` | Statement, issuer, acceptedAt, active flag and history reference | | `attkey/////` | Active attestation identifier | | `atthistory//` | Append-only correction, withdrawal and replacement records | | `atthistoryseq/` | Next history index | | `ack//` | Key acknowledgement | | `nodes/` | Current nodes and reassignment reference | | `nodehistory//` | Reassignment record | | `nodehistoryseq/` | Next reassignment index | | `grantseq//` | Next disclosure sequence | | `disclosure/` | Authorization, grant and AN verification record | | `access//` | Access confirmation | | `accessseq/` | Next confirmation index | | `obligation//` | Payer, funding account, recipientRef, amount, remaining, mode, required principal signers and status | | `link/` | Supersession or revocation record | | `incoming/` | Incoming supersession link | | `completion//` | Evidence record | | `completionseq/` | Next evidence index | | `held` | Total locked SBRIT | | `surplus` | Reconciled unsolicited credits | Mutable indexes and flags never erase signed source records or history. The contract reads AN status, keys and reassignment authorization through canonical namespace helpers, and writes only its own namespace. ### 6.4 Accounting Invariants 1. Contract SBRIT balance equals held plus surplus after external-credit reconciliation. 2. Held equals the sum of remaining amounts in unclosed locked obligations. 3. Pending and cancelled deeds hold no funds. Supersession or revocation refunds all remaining obligations atomically; terminal deeds retain no payment funds. Balance-change netting, numeric precision, sequential state visibility and failure handling follow the shared contract execution standard. Unsolicited credits confer no payment rights and do not satisfy payer funding. Successful calls reconcile excess committed balance as surplus; deficits fail. Unreconciled external excess is also surplus for the invariant. This version has no surplus withdrawal method. ## 7. Implementation Notes ### 7.1 Execution Dependencies The deed contract follows the shared Streembit contract execution standard. Deed time comparisons use the engine-provided `blockTimestamp`. Items in deed-operation arrays are processed in the supplied order. ### 7.2 Encoding and Storage Structured data and hashes follow Section 2.2 and the shared canonical-form conventions. Ciphertext uses the lowercase hexadecimal representation specified in Section 6.2. A 256 KiB document occupies 512 KiB of state in this representation; this is an accepted v1 storage cost. ### 7.3 Accountable Node Records The deed contract reads AN status, signing keys and authorization records through the system's read-only contract interface. The deed-specific use is to verify its assigned nodes and record authorized changes. ### 7.4 Deed Implementation Requirements 1. **Contract registration.** Register `deed_v1` in the allowed contract files. 2. **Document size.** Confirm that a registerDeed transaction carrying the full ciphertext, policy, signatures and attestations fits the system limits. Resolve compatibility before implementation is complete; this protocol does not define chain-wide transaction limits. 3. **Key delivery and receipt.** Implement confidential delivery of the deed key to each assigned AN and the deed-bound receipt record required by Section 1.4, using the system's secure communication facilities. Canonical encoding, contract execution, storage-key encoding and AN identity assurance are shared dependencies. Their system-wide implementation and verification belong in the corresponding specifications and engineering backlog, not in this deed protocol. ### 7.5 Security Notes A false or mistaken attestation may lead an AN to disclose a document, and that disclosure cannot be undone. The record preserves the issuer, statement, cited evidence and acceptance time. Revocation or supersession changes recorded status and future access rules. Neither reverses an earlier disclosure or makes an already disclosed document secret again. The ciphertext is public. Each assigned AN holds the complete key, so compromise of one node can expose the deeds whose keys it holds. Naming at least two nodes serves availability, not confidentiality. Public metadata reveals that a deed exists and can reveal participating nodes, roles and relationships. Recipient references reduce direct exposure but do not guarantee anonymity: ACCOUNT_BINDING records contain addresses and policy or attestation fields may expose identifying information. Public records follow Section 1.4's metadata-minimization requirement.