Deed contract
Working draft, v0.1A durable, confidential record of signed documents concerning intentions, agreements and rights, with Accountable Nodes verifying identities, holding the encryption key and providing authorised access.
At a glance
| Contract | deed_v1, one system contract |
|---|---|
| Deed types | WILL, PROPERTY_TRANSFER, GENERIC |
| Document storage | Complete encrypted document on chain, up to 256 KiB |
| Key custody | At least two assigned Accountable Nodes, each holding the complete key |
| Payments | Optional SBRIT, direct at activation or locked for release |
| Pending registration expires | 30 days after creation |
| Transaction form | CONTRACT_CALL in SBRIT with zero amount; funds move only through authorised balance changes |
Purpose
The Deed contract keeps a verifiable record of signed documents: a will preserving a person's instructions, or a property deed recording a signed instrument about identified property together with its payment conditions and evidence of completion. Real-world assets are identified in the document; they are not tokenised.
The record separates four things that are easy to confuse: what a person declared or agreed, what another participant attested, what the blockchain recorded, and what payment or external completion evidence was supplied afterwards. An anchor on the chain proves that the document existed in the recorded history. It does not by itself prove the signing date, a person's capacity, or that an external ownership transfer was completed.
Participants
- Deed parties create, review and sign the document: a testator, a transferor and transferee, or another declarant, depending on the deed type.
- Accountable Nodes verify identities and issue signed attestations stating who was verified, how, and for which deed. Assigned Accountable Nodes also hold the deed's encryption key and provide access to authorised recipients. Identity attestation and key custody are separate roles.
- Witnesses, where the deed's policy requires them, sign witness statements bound to the deed. A witness may not be a party or a recipient of the same deed.
- Beneficiaries, executors and other authorised recipients request access through an assigned Accountable Node under the deed's policy. Being named does not grant immediate access.
Confidentiality and access
The complete encrypted document is stored on chain in the contract's storage; a hash or an external reference is not enough. Each deed has its own encryption key, and every assigned Accountable Node receives a full copy, so decryption never depends on the author's device or account. The key itself is never exposed on chain.
A recipient's request is handled by an assigned Accountable Node as one workflow: locate the deed, verify the recipient's identity and entitlement under the policy, and provide access. Disclosure conditions a policy may require include an instruction of the grantor, a date, counter-signature by named roles, an attested external fact such as the death of the grantor, or a judicial order seen by a named Accountable Node. The authorisation and the confirmation that access was provided are recorded on chain as separate events, without exposing the key or the document.
The deed policy
Every deed carries a policy fixed at registration. It names the roles and who must sign, the required witnesses, the identity-assurance level each role must meet, the assigned Accountable Nodes, the access grants and their conditions, who may supersede or revoke the deed, any payment obligations, and which completion evidence may be attached. The contract enforces everything in the policy it can check mechanically. It does not interpret the document or encode the law; witness and attestation requirements are how the grantor's advisers express the formalities of the chosen jurisdiction.
- WILL: the testator signs and must be identity-attested; recipients typically gain access on an attested death or a judicial order; only the testator may supersede or revoke. Wills carry no locked payments in this version.
- PROPERTY_TRANSFER: transferor and transferee both sign and are both identity-attested; each holds a copy grant conditioned on all principals having signed; all principals must sign to supersede or revoke. Payments may be direct or escrowed in SBRIT.
- GENERIC: any signed declaration or agreement, with roles, witnesses, grants and supersession authority as the policy states.
Attestations
An attestation is a signed, dated statement by an ACTIVE Accountable Node, not a determination by the chain that a fact is true. Five kinds exist: IDENTITY binds a verified person to a signing key; AUTHORITY lets a verified representative act for an entity; WITNESSED records that the node observed a signature; ACCOUNT_BINDING confirms a recipient controls an SBRIT address; FACT records an external statement and its evidence, such as the death of the grantor or that a judicial order was seen. Only the issuing node may correct or withdraw its attestation, and the history is kept. Withdrawal blocks new reliance on the statement but never reverses what was already recorded.
How a deed moves through its life
- Register. The grantor submits the encrypted document, its policy and the grantor's own signature and attestations. The deed is PENDING.
- Collect. While pending, the other signing roles sign, witnesses sign, Accountable Nodes attest, and every assigned node acknowledges receipt of the key. Each signature is accepted only once the attestations it relies on are active.
- Activate. Any signing role activates the deed once every policy requirement is met. In the same atomic call the contract executes direct payments, locks escrowed payments and, when replacing an earlier deed, records the supersession and refunds the earlier deed's locked funds. The deed is ACTIVE.
- Cancel or expire. A pending deed may be cancelled by the grantor or by a party that has already signed, and anyone may expire it 30 days after creation. It becomes CANCELLED and is never disclosable.
- Disclose. While active, disclosures are authorised and confirmed as recorded events; the deed stays ACTIVE. Locked payments are released once, in full, on the signed instruction of every required principal.
- Supersede or revoke. Under the policy's authority a deed becomes SUPERSEDED or REVOKED and all remaining locked funds are refunded. The record is preserved as history; new access requires a grant written for that purpose.
- Completion evidence may be attached to an active or terminal deed as a dated, signed reference. It changes neither the document nor the state and establishes no legal title.
What the contract enforces, and what it does not
The contract checks signatures, witness counts, attestation levels, assigned-node acknowledgements, grant conditions, supersession authority and payment execution, and it keeps every signed record append-only. Payments are authorised only by the payer's signature and released only by the signatures of the required principals; death, completion and judicial-order attestations never move funds.
Outside the protocol are adjudication and enforcement, probate and estate administration, national property registers, legal drafting and determinations of capacity, validity or ownership, and external bank payments, which may be evidenced by attestations but are not executed by the contract.
Contract methods
| Method | Caller | Effect |
|---|---|---|
| registerDeed | Grantor | Creates the pending deed with its policy, encrypted document and the grantor's signature and attestations |
| signDeed | Signing role | Records a party's signature while pending |
| witnessDeed | Witness | Records a witness signature while pending |
| attest | Issuing Accountable Node | Records, replaces or withdraws an attestation |
| acknowledgeKey | Assigned Accountable Node | Records receipt of the deed's encryption key |
| activateDeed | Signing role | Activates the deed, executes and locks payments, optionally supersedes an earlier deed atomically |
| cancelDeed | Grantor or a role that has signed | Cancels a pending deed |
| expireDeed | Anyone | Cancels a pending deed after 30 days |
| authorizeDisclosure | Anyone submitting the required authorisations | Records the Accountable Node's verification and the grant relied upon |
| confirmAccess | Assigned Accountable Node | Records that access was provided |
| releasePayment | Anyone submitting all required principal signatures | Releases a locked obligation in full, once |
| supersedeDeed | Per the earlier deed's policy | Supersedes an active deed and refunds its locked funds; not available for wills |
| revokeDeed | Per policy | Revokes an active deed and refunds its locked funds |
| attachCompletion | Permitted role | Records completion evidence by hash |
| reassignNode | Per the Accountable Node protocol | Records the replacement of a key custodian |
Protocol document
Streembit Deed Protocol
Version 0.1, Working draft. This page summarises the document; the document is the normative text.
Download Markdown All documentsOn this page
- Purpose
- Participants
- Confidentiality and access
- The deed policy
- Attestations
- How a deed moves through its life
- What the contract enforces, and what it does not
- Contract methods