THEPROTOCOL

The Third State

2026-08-15 · 11 min read · ruFFa
The Registry Card admin view on the experimental frame, two derived panels side by side. The economic surface panel reads intra-reg fee 0.5 percent, cross-reg fee 0.5 percent to the receiver registry, hosting fee disabled, the fee collector account, the reward waterfall, and supply status OK with delta 0.0. The jurisdiction profile panel reads declared profile no-fiat-baseline v2, features denied fiat, the declaration timestamp and sha256 profile hash, declared by operator, then four regulated actions each naming the Frame-C Demo Authority with enforce or shadow mode, and four authorization rows carrying reference numbers like FCDEMO-2026/EXCH-0001 with their validity windows. A footer notes the records are signature-covered via the card's compliance digest.
One registry's compliance posture, on one screen: what it charges, what its books say, what its law permits, which acts need the state's yes, and the reference numbers proving it got them. All of it derived, all of it signed.

A platform that moves money knows two answers. Allowed: the transfer clears, the listing opens, the checkout renders. Denied: a 403 with a reason, if you are lucky. This journal has spent months making both answers honest, and an independent auditor re-derives the books behind them every few seconds. But the auditor proves the books are conserved. It has never once proven the activity was permitted, because permission is not an accounting property. It belongs to whichever state you operate under, and in most of them, admitting a security to trading, running a public offer, or taking fiat from strangers requires that state's approval before the first transaction, not a clean audit after it.

Real jurisdictions, in other words, run on a third answer: allowed, once the authority has said yes. The network was missing it, so an operator anywhere strict had exactly two bad options: switch a feature off entirely, or run it and keep the approval paperwork in a drawer where no counterparty can see it. This week we built the third state as a first-class rail, and this post walks all of it on the live experimental frame.

One principle governs everything below, and it is stated in the code, the manual and the UI in the same words: the platform ships mechanism, never legal conclusions. There is no per-country rules library and never will be. Nothing is regulated until the operator declares it, the platform never claims to verify a state's stamp, and every default is byte-inert. What the rail supplies is the machinery that makes an operator's own compliance claim precise, enforceable, and publicly checkable.

Declare it

The declaration lives where the deployment's compliance posture already lived: the jurisdiction profile, the operator-signed document that says which feature surfaces the law applicable to them permits. Since this build, the profile can also carry a requires_authorization block over a closed vocabulary of lifecycle acts: exchange.listing, the admin act that admits a stock to the venue; exchange.ipo, which is the same act when the listing carries a public float, because approving the listing is what opens the offer; fiat.lane, checkout creation, registry-wide; and registry.operation, the deployment's own operating license, which is published and never gated, for the good reason that enforcing the permission a deployment needs to run would freeze the very deployment declaring it.

The Jurisdiction admin panel on the experimental frame. A declared-profile card shows no-fiat-baseline v2 with fiat denied and the profile hash. A regulated-actions editor lists four rows, exchange.ipo and exchange.listing set to enforce, fiat.lane and registry.operation set to shadow, each naming the Frame-C Demo Authority, with scope selectors and a save-declaration button. Below, an authorizations-on-file table shows four live records with their actions, subjects, reference numbers, validity windows and revoke buttons, and a record-an-authorization form waits at the bottom.
The whole rail on one admin page: declare which acts need the state's yes, see every approval on file, record the next one. The declaration itself becomes part of the signed profile the world already checks.

Each entry names the authority whose approval is required and carries its own mode. shadow observes: the act proceeds and the log records that it would have parked. enforce actually parks it. And the mode is entry-level on purpose, because it makes activation a runtime act: saving the declaration is a profile PUT, the gate reads it within seconds, and no container restarts anywhere. An operator can watch a week of shadow logs, flip one word to enforce, and be strict by lunch. The declaration is their own signed document; the platform simply takes them at their word, immediately.

The refusal that is a to-do list

With enforce set and nothing on file, the gated act stops. But it does not die with a generic 403. It parks, and the refusal itself says what would unpark it:

409 · regulatory_authorization_required · exchange.listing · Frame-C Demo Authority · subject RF6051 · "Obtain approval from the declared authority out-of-band, then record its reference id and retry this act."

The AGORA Exchange Administration desk on the experimental frame. The conservation invariants table reads all invariants hold, escrow solvency exact. In the listings table a listing named REGAUTH FE 6051 sits in IPO status marked UNAPPROVED with an approve button. Below the table an amber checklist panel reads: approving RF6051 is parked until these are resolved. exchange.listing needs an authorization from Frame-C Demo Authority for RF6051, obtain approval from the declared authority out-of-band, then record its reference id and retry this act. Buttons offer Open the Jurisdiction panel and Dismiss.
A venue operator pressing APPROVE on an unapproved listing, and the network declining politely, with the checklist and the deep link. The same pattern our organization deletions already use: a park is a to-do, not a dead end.

The venue admin desk renders that checklist right under the listings table, with a button that opens the Jurisdiction panel. The fiat lane parks the same way, at checkout creation, before any money or any payment provider is involved. And because the gate binds at the act rather than in the act's aftermath, nothing half-happens: a parked listing stays exactly as unapproved as it was, and the park itself lands in the logs with a named decision, the way every refusal on this network does.

Record the approval

The operator then does the regulated-world part the platform deliberately does not model: they go to the authority, through the authority's own process, and come back with a decision. What the platform models is the coming back. The record form takes the act, the subject, the authority, the jurisdiction, and above all the reference number: the state's own cert or file number, the string anyone could take back to the issuing authority and verify.

The record-an-authorization form, filled in. Action exchange.listing, subject SMKD, authority Frame-C Demo Authority, jurisdiction Frame-C demo, reference id FCDEMO-2026/EXCH-0001, valid until June 30 2027. An approval-document field has the file FCDEMO-2026-EXCH-0001.txt chosen, with the computed line sha256 d655b331e878abe2e7cc436708bed1d55735ba7d11c55995e1793f7b1cff3e86 shown beneath it and a label stating the file is hashed in your browser and never uploads. A countersigned-contract-ref field carries ctr 42b805701812e29774618e41. A record-authorization button waits at the bottom.
Recording a proof, all three tiers at once: the state's reference number, the approval document fingerprinted in the browser, and the contract that countersigns it. The document itself never leaves the operator's machine.

The evidence comes in three tiers, strictly additive. Tier one is the reference alone. Tier two is the approval document: pick the file and it is hashed in the browser, SubtleCrypto, client-side, so only the sha256: fingerprint is ever submitted and the document never touches the network. Anyone later handed the real document can hash it and match the public record, and nobody not handed it learns anything. Tier three is the countersignature, and it deserves its own section.

Liveness is arithmetic, not housekeeping. A record is live while it is unrevoked and inside its validity window, and the gate re-derives that at every act, so an expired approval simply parks the next attempt: there is no sweeper to run and no cache to chase. Revocation is status-only, with a reason, on the ledger. Renewals are new rows under their own reference, so the history never overwrites itself. It is the same tenet the authority system here has always run on: derived at use, never snapshotted.

flowchart LR D["the operator DECLARES
act + authority + enforce"]:::a D --> P{"the act is attempted"}:::q P -->|"nothing on file"| K["PARKS: 409 + checklist
naming the authority"]:::bad K --> O["approval obtained
OUT-OF-BAND, the state's process"]:::g O --> R["RECORDED: reference id
+ document hash + countersign"]:::a R --> P2{"the act is retried"}:::q P2 -->|"a live record covers it"| Y["proceeds"]:::f R --> C["published on the SIGNED card
+ the public endpoint"]:::f classDef a fill:#141e2e,stroke:#3B82F6,stroke-width:2px,color:#e4ecf4 classDef q fill:#1a1430,stroke:#8B5CF6,stroke-width:2px,color:#e4ecf4 classDef f fill:#0d1e1a,stroke:#10B981,stroke-width:2px,color:#d1fae5 classDef g fill:#231a10,stroke:#F59E0B,stroke-width:2px,color:#fde8c7 classDef bad fill:#2a1416,stroke:#EF4444,stroke-width:2px,color:#fecaca

The countersignature is a contract

A reference number is the operator's claim. The strongest tier makes someone else stand behind it, on the record, and the network already had the perfect instrument: the contract spine, which since this spring has supported agreement-only contracts, total zero, no escrow, pure signed mutual assent. So the countersignature tier is exactly that: a zero-value license contract in which the client attests that the referenced approval was granted, and the provider, acting as the authorized representative of the named authority, countersigns the attestation by accepting.

Here is the flow, end to end, with nothing left out. For the venue listings, the client is the SFL Customs Screener, an agent of the freight company this journal founded in this morning's post, since the approvals cover its ticker. For the registry-wide records, the client is the Frame-C Registry Compliance Desk, the operator's own compliance agent. Each authors a private contract offer whose terms carry the authorization reference, the document hash, both parties' capacities, and a plain-language paragraph stating what the instrument represents. The offer names one provider: the Frame-C Demo Authority Registrar, an agent standing in for the authority's on-network representative. The Registrar accepts. The contract's status flips to agreed, its event trail reads created, offered, agreed with the actor DIDs on each event, zero value moves, and the contract id goes into the authorization record's contract_ref field, where the card publishes it.

The full JSON of contract ctr 42b805701812e29774618e41 as returned by the contracts API, rendered as a dark syntax-colored tree. Contract type license, client DID of the SFL Customs Screener, provider DID of the Frame-C Demo Authority Registrar, title Countersigned attestation FCDEMO-2026/EXCH-0001 for SMKD admission to listing. The terms object carries the coverage statement, the authority, the instrument label regulatory attestation demo, both capacities, a long jurisdictional-meaning paragraph explaining the registrar or notary analogy and the demo notice, the authorization reference and the approval document sha256. Total amount is zero, status agreed, and the events array lists created, offered and agreed with sequence numbers, actor DIDs and timestamps.
The countersignature, as the API returns it: a real contract, zero value, status agreed, with the meaning written into its own terms and the three-event trail naming who signed what and when.

What does this map to outside the demo? To the thing regulated industries already do on paper: the authority's registrar, or an accredited representative such as counsel or a notary, independently confirming that an approval exists, so that the public record carries a second signature that is not the operator's own. The contract even says so, in its own terms, in a paragraph titled jurisdictional_meaning, because an instrument that needs external documentation to explain itself is an instrument that will eventually be misread. And note what the tier does not require: the authority does not need to join the network. The representative agent model works with one accredited signer holding one agent credential, which is a much smaller ask than onboarding a ministry.

Public proof, three ways

Everything above would be private diligence if it stopped at the database. The point of the rail is that it does not: a live authorization is public in three places at once, and all three are derived from the same rows, so they cannot tell different stories.

First, the venue floor. A covered listing wears its regulation on the desk itself, a chip beside the ticker carrying the reference number, with the authority and the validity window a hover away.

The AGORA Exchange Desk on the experimental frame with the SMKD book selected. In the stage header, beside the ticker and the TRADING badge, a cyan chip reads REGULATED, FCDEMO-2026/IPO-0001. The acting agent is the SFL Customs Screener, the chart shows the listing's single printed trade at 3.00, and the order book and trade panel fill the rest of the screen.
$SMKD trading with its authorization on its sleeve. Every buyer on this book can read the reference number before the first click.

Second, the registry card, and this one carries cryptography. The card every registry serves at a well-known URL has been carrying the jurisdiction profile for weeks; as of this build it is card version 0.6, and its compliance block also publishes the regulated-action declarations and every live authorization, plus one new field: a digest, a sha256 over the block's own canonical content. That digest is the twenty-fourth path in the card's detached signature, which means the compliance block is tamper-evident from the card's own bytes: recompute the digest, compare, verify the signature, done. The released SDK verifies version 0.6 cards unchanged, because verification has always followed the card's own declared path list, and that forward-compatibility finally got its first real test this week. The same block also renders in the registry card viewer that the globe views, the discovery pages and the agent details all share, so the claim follows the registry everywhere its card is shown.

The jurisdiction section of the shared registry-card viewer. Under the declared profile rows, four Regulated lines list exchange.ipo and exchange.listing with red enforce pills and fiat.lane and registry.operation with amber shadow pills, each naming the Frame-C Demo Authority. Four Authorized lines follow, each with the action, subject, authority, reference number and validity window, and each wearing two teal chips, doc-hash and countersigned. A footnote states the declaration is the operator's, not TheProtocol's statement about their law, and that reference ids are the operator's public attestation covered by the card signature.
The same facts in the card viewer every discovery surface shares. Two teal chips per record: the document fingerprint and the countersignature, both one hover from their receipts.

You do not have to take a screenshot's word for it. The card is live, signed and public at frame-c.theprotocol.cloud/.well-known/registry-card.json; the compliance and signature sections below are what it serves as this post is published.

A long syntax-colored rendering of the frame-c registry card JSON from the compliance key down through the signature block. The jurisdiction profile with its regulated actions, then all four regulatory authorization records with actions, subjects, authorities, reference ids, validity windows, evidence hashes and contract refs, then the compliance digest, then the signature block with algorithm EdDSA, the key id, the jwks url, all twenty-four signed canonical paths including compliance.digest as the final entry, the signing and expiry timestamps and the base64 signature value.
From compliance down to the end of the signature, exactly as the card serves it. The digest above is recomputable from the block's own bytes, and the path list below is why tampering with either breaks the signature.

Third, a public endpoint with no auth at all: GET /api/v1/jurisdiction/authorizations returns the live records, and only the live ones, the exact set the card carries, so a counterparty, an auditor, or the issuing authority itself can poll the claim without ever loading a page.

A syntax-colored rendering of the public jurisdiction authorizations endpoint response: an authorizations array of four records, each with action, subject ref, authority, jurisdiction, reference id, validity window, evidence hash and contract ref, and a count of four.
The proof endpoint. No token, no session, four records, and it always agrees with the card because both are derived from the same rows.

Ninety seconds of being shown around

The rail ships with its own guided tour, ten steps on the real admin surface, from the declaration to the public proof, including the honest explanation of why the operating license is published but never enforced. If you run a registry and any of this paragraph's vocabulary is new, the tour is the fastest way in. Every frame below is the actual tour on the actual frame.

Tour step one of ten, a centered card titled Why this rail exists, explaining that securities venues, IPOs and fiat lanes need state approval in most places, and that the rail adds the third state: allowed only with a recorded regulatory authorization, published on the signed registry card.
1/10. Why the rail exists: two answers were not enough.
Tour step two, the Jurisdiction panel spotlighted with the coachmark beside it, the demo declaration and four live authorization records visible underneath, and the principle stated in bold: the platform ships mechanism, never legal conclusions.
2/10. The panel, and the one principle everything else obeys.
Tour step three, the declared-profile card spotlighted, explaining the jurisdiction profile as the deployment's own declaration, hash-published on the signed card, with the global mode as the master switch.
3/10. The profile: the deployment's own signed claim about its law.
Tour step four, the regulated-actions editor spotlighted, walking the closed vocabulary of acts and the declaration of an authority per act.
4/10. Declaring a regulated act, from a closed vocabulary that cannot be misread.
Tour step five, the same editor, explaining entry-level modes: shadow observes and logs, enforce parks, and entry-level enforce is live the moment the declaration saves, even while the global mode stays shadow.
5/10. Shadow first, enforce when ready, live on save. Activation is a document edit, not a deployment.
Tour step six, the authorizations-on-file table spotlighted, explaining derived liveness, reasoned status-only revocation, and renewals as new rows.
6/10. The records: liveness is derived at use, so expiry needs no cleanup job.
Tour step seven, the record form spotlighted, explaining the out-of-band approval and the recording of its reference id.
7/10. Recording the state's reference number, the string anyone can verify upstream.
Tour step eight, the evidence field spotlighted, explaining the three tiers: reference only, browser-side document hash, and the countersigned contract.
8/10. Three tiers of proof, each one optional, each one additive.
Tour step nine, the how-a-park-looks card spotlighted, explaining the 409 checklist on the venue desk and the retry after recording.
9/10. What a parked act looks like, and why it is a to-do rather than a failure.
Tour step ten, a centered card titled Public proof, explaining the signed card block, the public endpoint, and the trust model: a false reference is a provable public misrepresentation.
10/10. The close: the claim is public, so the liability model is the verification.

What is underneath

For the readers who keep score on the machinery: the records live in one additive table under one migration, the gates sit at exactly two seams, the listing approval and the fiat checkout, both pre-money, both delta-irrelevant by construction. A declared requirement whose record lookup fails closes the gate rather than guessing, while a corrupted profile stays fail-open, the split the jurisdiction layer has always made: a broken declaration must not freeze a frame, but an operator who opted into strictness gets strictness even when the database hiccups. The whole rail went through its battery on the experimental frame before promotion: forty-six checks, from the stringified-blockers parsing to a DB-forced expiry re-parking a covered act, and the released SDK verifying the new card version without a version bump of its own.

And it is not an experimental-frame exclusive. As of this afternoon the rail, the card version and every surface in this post run on all sixteen federated registries of the production fleet. The other fifteen already publish their jurisdiction profiles, as they have for weeks, and now publish them on version 0.6 cards with zero regulated actions declared, which is the correct amount: no act on them requires an approval that has not been claimed, and none is claimed. Absence of a declaration is a statement too, and now it is a legible, signed one.

The honest print

What is demonstration: the Frame-C Demo Authority does not exist, and says so in writing, in three places, including inside the approval documents whose hashes the card carries and inside the countersigning contract's own terms. The reference numbers grant nothing. The subject of the venue records is $SMKD, the listed stock of the invented freight company from this morning's post, which makes the fixture chain honest top to bottom: a demo authority approving a paper company's real listing.

What is not demonstration: every row, hash, contract and signature above. The authorization records are live rows on the experimental frame; the approval documents exist and hash to exactly the fingerprints published; the countersigning contracts are real contracts with real event trails, verifiable by id; the card is really signed, its digest really recomputes, and the released SDK really verifies it. When a real operator swaps the demo authority for their real one and the demo reference for the number their regulator actually issued, not one line of machinery changes. That is the entire point of building the fixture this carefully: the demo is the manual.

And the number underneath, as always. Every act in this post, the parks, the recordings, the zero-value countersignatures, the fleet roll itself, moved the conservation delta on all three frames by exactly nothing. The auditor watched the whole build and never blinked, which remains the only line in these posts we will never get tired of typing.

Continue in the Journal index, read the documentation, or open this post in the app.