The RSIC Protocol
The primitives are seven.
The extensions are open.
On the claim of this document.
The Continuity Chain is the first reference implementation of the RSIC protocol — Responsibility, Stewardship, Inheritance, Continuity. RSIC is a protocol for recording continuity: the continuity of institutions, the continuity of offices, the continuity of stewardship through a change of holder.
Three statements appear at the centre of the protocol. They are not claims made for the chain. They are claims made about the chain.
These three statements protect the constitutional boundary the protocol observes. They are repeated throughout this document, and they should be read each time they appear, slowly, before the next chapter is begun.
The Continuity Problem
Trusts, estates, offices, and institutions exist through time. They are constituted at some moment and intended to persist beyond that moment. Persistence is not automatic. A trust does not continue because nothing happens. A trust continues because the events that would otherwise end it — death, resignation, incapacity, dispute, fraud, key compromise, legal fusion — are absorbed by the trust without the trust ceasing to be itself.
This is the continuity problem. It is older than software, older than law, older than writing. Every institution that has survived a generation has solved some version of it. Every institution that has not has dissolved.
The conventional solutions are paper. A trust instrument is drafted. Successor trustees are named. A registrar maintains a record. A court keeps a docket. These solutions work — when they work — because trusted parties maintain trusted records using trusted procedures. When trust in those parties or those records erodes, continuity erodes with them.
RSIC does not replace those solutions. RSIC supplements them with a record that cannot be re-written. The trust instrument is still the trust instrument. The court is still the court. The registrar is still the registrar. RSIC records what they did, in the order they did it, in a form that any future reader can verify without their permission.
The continuity problem RSIC addresses is therefore narrow: not how to constitute a trust, not how to adjudicate a dispute, not how to certify identity, but how to record continuity in a form that survives the failure or absence of the institutions that originally recognised it.
Constitutional Principles
The RSIC protocol is structured around five constitutional principles.
Append-only. No record in the chain is ever deleted, edited, or replaced. Corrections are appended as new records. The past is preserved exactly as it was witnessed.
Cryptographic linkage. Every record references the hash of the record before it. Tampering with any record breaks the chain from that point forward. Tampering is detectable by anyone, without privileged access.
Witnessing thresholds. Constitutional events require multiple independent witnesses of sufficient rank to seal them. The threshold is not procedural ceremony. It is the constitutional condition under which responsibility is permitted to move.
External authority. The chain records the determinations of competent external authorities — courts, registrars, masters’ offices, trust protectors. It does not generate those determinations. It does not adjudicate.
Frozen primitives. The seven primitives — Object, Office, Holder, Transfer, Witness, Record, Inheritance — are not extensible. New requirements are absorbed through extension vocabulary, workflow, and configuration, never through amendment.
These principles are not implementation choices. They are constitutional commitments. The implementation enforces them; it does not define them. A different implementation, in a different language, on a different database, against a different signing scheme, must enforce the same five principles or it is not an implementation of RSIC.
The Frozen Baseline
The constitutional baseline of RSIC is frozen.
This is the most important architectural commitment in the protocol and the one most often misunderstood. A frozen baseline does not mean the protocol cannot grow. It means the protocol cannot grow through amendment of its own foundations.
If the seven primitives could be revised, every chain in existence would be vulnerable to retroactive reinterpretation. A future committee, by amending the meaning of Office or Witness, could change the constitutional weight of every historical record. Continuity would no longer be continuous. It would be subject to redefinition by whoever held the pen.
A frozen baseline removes that vulnerability. The Constitution as it stood at RSIC v1.0 is the Constitution under which every record was, is, and will be evaluated.
Growth happens elsewhere: in extension vocabulary, in workflow configuration, in implementation. A new jurisdiction can add domain-specific record types through an extension pack. A new institution can configure thresholds at the upper bound of what the Constitution permits. A new implementation can support new storage backends, new signing schemes, new languages.
What cannot change are the primitives, the append-only contract, the cryptographic linkage rule, the witnessing principle, and the rule of external authority.
This is why the protocol is called a protocol, not a product.
The Seven Primitives
The vocabulary of RSIC is exactly seven words.
Object. The thing that endures. A trust. An estate. A foundation. A society. The institutional or legal entity whose continuity the chain records.
Office. The seat through which stewardship of the Object is exercised. An office is older than its current holder and will outlast them. Trustee. Executor. Administrator. Director. Custodian.
Holder. The person who, for now, occupies an Office. The Holder is mortal. The Office is not.
Transfer. The movement of a Holder into or out of an Office. A Transfer is constrained by the inheritance rule the Object placed inside itself when it was constituted.
Witness. An attestation, by a party of sufficient rank, that an event has occurred. Witnessing is the mechanism by which the chain knows that a constitutional threshold has been satisfied.
Record. An entry in the append-only chain. Each Record carries a class — Operational, Exceptional, or Constitutional — and an event type. Each Record links cryptographically to the Record before it.
Inheritance. The rule, written in advance, by which continuity survives a change of Holder. Inheritance is the difference between a trust that ends when its trustee dies and a trust that does not.
These seven words constitute the entire vocabulary. Any institution that can be described using these seven words can be recorded by the chain. Any institution that cannot must use an extension.
This is austere by design. Austerity protects the constitutional boundary.
Witnessing versus Adjudication
The distinction between witnessing and adjudication is the most consequential one the protocol makes.
A witness attests that an event occurred or that a determination was made. A witness does not make the determination. A witness records that the determination was made and attaches the evidence on which the determination rests.
An adjudicator makes the determination. Adjudication belongs to external authorities — courts, registrars, masters’ offices, councils, trust protectors, regulators. The chain witnesses what those authorities adjudicate. It does not pretend to adjudicate in their place.
This distinction is what permits the chain to be neutral. The chain takes no view on whether Trustee A actually died, on whether the inheritance rule was correctly drafted, on whether the successor was the right one. The chain records that a competent authority attested to the death, that the inheritance rule (whatever its merits) engaged, that a successor (whoever they were) was determined and assumed office.
A reader who disagrees with any of those determinations is free to challenge them in the appropriate forum. The chain does not prevent the challenge. The chain only prevents the challenge from being conducted by re-writing history.
This is the constitutional architecture of the protocol: facts are witnessed by the chain, determinations are made by external authorities, history is preserved exactly as it occurred.
Continuity through a Change of Holder
The central case the protocol must solve is the change of Holder.
If continuity belonged to the person, every death would end every trust. It does not. Continuity belongs to the Office. The Office is older than its Holder. The Office will outlast its Holder. A change of Holder is not a change of Office, and therefore not a change of trust.
The protocol records this with deliberate care.
When a Holder ceases to occupy an Office — through death, resignation, incapacity, removal, or any other terminating event — the chain records the event. Evidence is attached. Witnesses seal. The chain does not declare the Office vacant. The chain records that a competent authority attested that the conditions for vacancy were satisfied.
When a successor assumes the Office, the chain records the assumption. A new Holder assignment is created. The prior Holder’s assignment is marked ended; the prior Holder’s row is not deleted. The chain preserves both, because both occurred.
At every step, what is being recorded is not the replacement of one person by another. What is being recorded is the persistence of one Office through a transition between persons. The Object — the trust itself — never enters the transaction. The Constitution never enters the transaction. The succession rule never enters the transaction. Only the Holder changes.
This is the meaning of continuity through a change of Holder. It is also the meaning of the protocol’s name.
The Acceptance Scenarios
Four canonical scenarios constitute the protocol’s acceptance suite. Each tests one constitutional question. Together they exercise the principles of the protocol against the situations real institutions encounter.
RSIC-001 — Absence. A trustee dies. Continuity is preserved through the inheritance rule. A successor assumes the office. The trust does not change.
Tests the central constitutional claim of the protocol: continuity survives a change of holder.
RSIC-002 — Conflict. Two parties claim the same office. The chain does not adjudicate. The chain records the determination of an external competent authority.
Tests the boundary between witnessing and adjudication.
RSIC-003 — Provenance. A holder’s cryptographic credentials change. Identity persists. Office persists. Continuity persists. Provenance remains an unbroken line from Genesis.
Tests that cryptographic mechanics do not become a single point of failure for institutional continuity.
RSIC-004 — Confusio. A holder and beneficiary become the same person. Roman law calls this confusio. The chain records the fact. It does not infer the legal consequence. That belongs to an external authority.
Tests the protocol’s commitment to refusing legal inference even when legal inference appears obvious.
These four scenarios are not exhaustive. They are canonical. An implementation that passes all four can be relied upon to handle a wider class of situations that share their constitutional structure. An implementation that fails any one of them cannot be called RSIC-compliant.
Extension Architecture and Constitutional Boundaries
Extensions are the mechanism by which RSIC absorbs new requirements without amending its Constitution.
An extension is permitted to introduce:
- New vocabulary (e.g. Beneficiary, Settlor, Master) that maps onto the seven primitives.
- New record types (e.g. Distribution, Investment Resolution) that conform to the existing classes.
- New workflows (e.g. quarterly reporting, jurisdiction-specific attestation).
- New thresholds within the bounds the Constitution permits.
- New attachment classes (e.g. images, audio, video).
An extension is not permitted to:
- Introduce new primitives, or alter the meaning of existing ones.
- Permit deletion or editing of records.
- Permit unwitnessed constitutional events.
- Allow records to be created without cryptographic linkage to the chain.
- Allow the chain to make adjudicative determinations on its own.
The boundary is sharp. If an extension would require an amendment to the seven primitives, the extension is incorrect, not the Constitution.
This rule may appear rigid. It is the discipline that keeps the protocol coherent across implementations, jurisdictions, and decades. An institution that adopts RSIC today should be able to read records produced by an institution that adopts RSIC fifty years from now and find them constitutionally identical.
The Family Trust extension pack, shipped with the reference implementation, is the canonical example of a well-formed extension. It introduces beneficiary tracking, distribution records, investment resolutions, and reporting workflows. It introduces no new primitives. It does not modify the chain’s append-only contract. It does not permit unwitnessed constitutional events.
This is the shape of every legitimate extension.
The Reference Implementation
The Continuity Chain reference implementation is shipped as a Node.js monorepo with PostgreSQL, Prisma, and Docker. It implements the seven primitives, the three record classes, the constitutional witnessing thresholds, the inheritance engine, the chain verifier, and the four acceptance scenarios.
The reference implementation is not the protocol. It is one implementation of the protocol. Another implementation may use a different language, a different database, a different signing scheme. So long as it enforces the five constitutional principles and exposes the seven primitives, it is RSIC.
The reference implementation is provided for three reasons.
First, as a proof of feasibility. The protocol is not abstract. It runs.
Second, as a reference for compliance. Other implementations can compare their behaviour against the reference on the acceptance suite.
Third, as a starting point for institutions. Adoption is easier when an institution can stand up a working system in an afternoon rather than building one from a specification.
The reference implementation deliberately does not implement everything an institution might want. It does not include identity management beyond the minimum required by the protocol. It does not include billing, regulatory filings, jurisdiction-specific document generation, or counsel collaboration. These are extensions, and extensions belong to the institution.
What the reference implementation does include is precisely the constitutional core, the acceptance suite, the reporting surface, the documentation, and the narrative artifacts. That is the protocol. The rest is the institution.
Scope, Limits, and Non-Claims
The protocol’s modesty is a feature, not a limitation.
RSIC does not claim that a record in the chain is legally binding. Legal bindingness is a matter for the law of the relevant jurisdiction.
RSIC does not claim that a record in the chain is factually true. Factual truth is a matter for the competent authority whose attestation the record carries.
RSIC does not claim that a successor named by the inheritance rule is the rightful successor. Rightfulness is a matter for the trust instrument, the applicable law, and any party with standing to dispute.
RSIC does not claim that a signature on a witnessed record is the signature of the named party. Signature authenticity is a matter for the signing scheme and for whatever authority certifies the keys.
What RSIC claims is exactly this: the chain preserves what it was given, in the order it was given, with the witnesses that sealed it, in a form that any future reader can verify without privileged access.
That is the whole of the protocol’s claim.
This narrowness is not a deficiency. It is the source of the protocol’s durability. By claiming only what a chain of records can rigorously claim, RSIC avoids the failure mode of every previous system that has tried to make stronger claims and been found, eventually, to be unable to support them.
The chain records continuity. It does not create it. It does not adjudicate it. And because it claims nothing more, the claim it does make can be trusted by anyone, anywhere, at any time.
That is the protocol.
On the place of this document.
This White Paper is the first artifact in the trust profile that treats RSIC as a protocol rather than as a software project. Every other artifact — the implementation, the reports, the scenarios, the walkthrough, the documentation, the landing page — is downstream of what this document states.
The protocol is older than its first implementation, and intended to outlast it. The Constitution is frozen. The primitives are seven. The extensions are open. The chain is append-only. Authority is external. Continuity is recorded.