Portable Trust Cell · PTC

The record carries its own proof.

A Portable Trust Cell is a minimal, passive, signed object. It packages protected information together with the evidence, history and rules a completely separate implementation needs to verify and recover it, long after the original vendor is gone.

Six layers

The cell, layer by layer

Exploded 3D render of a Portable Trust Cell as six stacked layers: L1 Membrane, a strict boundary for parser, type, version and resource limits; L2 Identity, a fixed logical identity separate from any copy or storage medium; L3 Memory, the authenticated lineage of the cell's recorded history; L4 Receptors, the typed evidence the cell is allowed to accept; L5 Behavior, bounded, fixed interpreter actions with no autonomous agents; L6 Inheritance, explicit parent and child commitments that carry trust forward to child cells below.
Design concept · research stage

Anatomy

Six parts. No executable code.

Unlike a “smart container”, the cell never runs embedded scripts and never invents legal authority. A tiny, openly specified interpreter, which anyone can implement, evaluates it. Select a part to see what it does.

Diagram of a Portable Trust Cell: an outer membrane with input ports (receptors), an identity plate, a central behavior interpreter, an append-only memory chain, and an inheritance link to a child cell.

01 · The gatekeeper

Membrane

Screens every input before anything inside the cell sees it.

  • Strict parsing and canonical encoding, so there are no ambiguous or malformed payloads.
  • Type and protocol-version validation.
  • Resource limits that protect the interpreter from exhaustion attacks.
  • Domain-separated commitments, so input meant for one context can’t be replayed in another.

One input, one verdict

Everything passes or nothing changes.

Each input is checked against rules the cell has already committed to. A single failed check, whether a mismatched signature, an expired timestamp or a corrupted share, leaves the cell exactly as it was and returns an explicit reason.

  1. 01

    Membrane

    Format, type, version and size checks.

  2. 02

    Receptor

    Accepted only if it is one of the known input types.

  3. 03

    Interpreter

    Applies the fixed, versioned transition rules.

  4. 04

    Outcome

    All checks pass committed to Memory.

    Any check fails nothing committed; reason code returned.

statet+1 = Transition(statet, typed_inputt, fixed_rulesv)

Fork detection

Two valid signatures. One honest answer.

If someone signs two conflicting updates from the same earlier state, the lineage visibly splits. The interpreter can prove the split happened. It can’t decide which branch the law recognizes, and it won’t guess.

same parent signed ✓ signed ✓
Generation 3 has two children, both validly signed and both claiming the same parent hash.
INVALID
A branch breaks the transition rules, version bounds or signature policy.
REQUIRES_EXTERNAL_AUTHORITY
Both branches are valid. Deciding which one governs takes a person, an organization or a court.

Recoverable ≠ authorized for release

What math can settle, and what it can’t.

CertiLink keeps four statements about a record separate. A verifier must never silently turn signed into true, a valid hash into authorized, or recoverable into legally releasable.

Checked offline, by math

Byte integrity

Do the recovered bytes match the commitment?

Provenance

Which keys, parties or systems signed and recorded it?

Needs people, organizations or courts

Current status

Which version or instrument governs today?

Authorized disclosure

Is this person entitled to see the plaintext?

A completed online notarization is not a court ruling that a will is valid. An offline device can’t learn about a revocation, a death determination or an injunction it has never been shown.

The offline drill · eStateSafe

Switch everything off. Recover anyway.

The acceptance test CertiLink has designed around a real estate record. Every system that created it is shut down, and an independent implementation on an isolated machine has to rebuild the exact original and report what it can and can’t verify.

  1. 01

    Freeze

    An estate document is created and its exact source bytes are cryptographically frozen.

  2. 02

    Execute

    Where legally appropriate, executed through a remote online notarization provider; otherwise synthetic fixtures.

  3. 03

    Package

    Evidence signed, document encrypted under a per-version key, lineage bound.

  4. 04

    Distribute

    Ciphertext spread across separate media and operators; the recovery secret split across independent control domains.

  5. 05

    Export

    A standalone package with specifications, key history, proofs, policies and interpreter source.

  6. 06

    Kill

    eStateSafe, CertiLink, databases, identity providers, cloud credentials and the network are all cut off.

  7. 07

    Reconstruct

    An independent implementation rebuilds the original bytes, evaluates authorization separately and reports claim by claim.

  8. 08

    Attack

    Corrupted copies and shares, removed domains, forged approvals, stale lineage. Every failure has to be caught.

  9. 09

    Compare

    Results benchmarked against matched baseline designs at equivalent resources and cost.

Must succeed with no access to

  • PostgreSQL
  • eStateSafe APIs
  • Privy identity
  • Pyth oracles
  • Arweave gateways
  • Bitcoin nodes
  • CertiLink services
  • Server secrets
  • Network

This is the drill’s design. Independent offline exact-byte recovery is a Tier-2 research goal and has not yet been demonstrated.

Go deeper

See the cell move, or read the research.

The film walks through a cell surviving a failure and a custody handover. The research page covers the survivability quorum, the hypotheses, and how the work will be tested.