ARC Network

Federation trust

This protocol answers one question for any node that holds a copy of the public registry. The question is whether another node's standing in the network is good, decided from the copy alone, with no live answer from the registry operator and no trust in the presenter.

The verifier specified here is implemented once, in one canonical home, and every surface renders its verdicts. The website's statements about trust will be generated from this specification rather than written beside it. A change to trust semantics lands in the canonical verifier and in this document together, or it does not land at all.

The grade on every standing check

Every standing check opens with the same grade statement, sealed by the handshake command specification and printed by the operator command and the application alike.

Standing check by the canonical federation trust verifier.
Grade: PRODUCTION-GRADE.
F5, governance-revocation countersignature, ruled: a second custody seat countersigns every governance revocation.
F7, checkpoint key custody and rotation, ruled: rotation is a governed act and verdicts anchor to the key that signed their basis.
Every verdict is a statement about the checkpoint basis printed with it.

The published basis

The basis below is the checkpoint this page answers to, read from the published record at build time. A verdict is a statement about this basis, and the basis is printed with it.

What standing decides, and what it does not

This protocol decides standing and nothing else. It grants no authority, and it settles nothing. Discovery alone never admits authority. A verified standing is an input to a node's own trust policy, and the acceptance under that policy remains the node's own act, exactly as the settlement protocol's handshake requires. Entitlements are a separate layer, defined in ENTITLEMENTS.md beside the registry, and no verdict in this protocol speaks to them.

Identity

A node's identity is its key, and its address is derived from the key so that anyone can recompute it. The address is the string arc: followed by the lowercase hex SHA-256 digest of the public key's DER encoding in SPKI form. Possession of the key is proven by signature, never by assertion. A presentation is optional input. Without one, the verifier reads standing from the published record alone and its verdict says that is what it did.

The record

The registry ledger is a hash-linked append-only chain, and its rules already exist in the registry machinery. Canonical form means JSON with object keys sorted recursively and no insignificant whitespace, the same function the registry's checkpoint.mjs and admit.mjs already share. The checkpoint object names the ledger head hash, the entry count, and the SHA-256 digests of the ledger file, the registry feed, and the nodes document as published. The checkpoint is signed with a dedicated registry checkpoint key, separate from every node key and from the release signing key, and the signature covers the canonical form of the checkpoint object. The rule for readers is recompute, never believe. Failure at any point ends the matter, and the verdict names the failure rather than grading it. A checkpoint key can rotate, and rotation is a governed act recorded in the ledger rather than a substitution of files.

The check

The required objects are the ledger registry-ledger.jsonl, the checkpoint envelope registry-checkpoint.json, and the checkpoint public key checkpoint-pubkey.pem. The verifier is a pure function of its inputs. It performs no network access, and the proof battery runs it under a tripwire that makes any network attempt throw, so the absence of network contact is a property of the harness and not an assertion in a report. Every verdict names its basis. A verdict is therefore a statement about a named published state of the registry, never a statement about the present moment. A reader holding an older copy receives a true verdict about an older state, printed on the verdict's face, and staleness is visible rather than hidden.

The verdict words

The five verdict words are standing_verified, refused_unenrolled, refused_revoked, copy_invalid, and presentation_invalid, with indeterminate reserved for the two-copy disagreement of Section 6.

• standing_verified. Otherwise the admission stands, and a presented key proof is checked before the verdict reports it.
• refused_unenrolled. Finding none, it refuses the subject as unenrolled.
• refused_revoked. A valid revocation refuses the subject as revoked.
• indeterminate. When a caller holds two copies that each pass integrity and name different heads, the verifier returns indeterminate with the reason copies_disagree and names both heads in its warnings.

The remaining words report that the question itself could not be put to a valid copy or a valid presentation, and they are refusals of the question rather than answers about the node.

Revocation

A revocation is a ledger entry of kind revocation, appended like every entry and never edited or removed afterward. Two revokers can sign, because two different situations demand withdrawal. The node's own key signs a self revocation, verified against the public key in the node's stored proposal, exactly as a correction is verified today. The registry checkpoint key signs a governance revocation, verified against the published checkpoint public key. The words are key-compromise, operator-request, superseded-by-rotation, and governance-act. A valid revocation takes effect for every verdict computed from a copy whose chain includes the revocation entry, and inclusion in the checkpoint-bound chain is what makes it operative. An entry whose document is missing, malformed, digest-mismatched, or signature-invalid does not revoke anything, and the verdict carries it as a named warning instead, because treating unsigned paper as withdrawal would hand any tamperer a weapon against any node. Corrections never affect standing, since they amend fields such as locality on an admission that continues to stand. Revocation is the only entry kind in this protocol that removes standing. One signature is not enough for a governance revocation.

The published ledger this page answers to holds nineteen entries. Eight are admissions, one is the genesis anchor, three are corrections, two are key bindings, two are endpoint records, three are custodian records, and none is a revocation. The first governance revocation of a real standing, if one is ever needed, will be the machinery's first live exercise, and the registry act stage is where a real revocation entry first becomes possible at all.

Introductions

An introduction is a signed statement by an enrolled node, the introducer, naming a stranger node's address and public key, the introducer's own entry number, a scope, and an expiry. An introduction does exactly two things and no third thing. It marks the stranger's address as presented by a named enrolled introducer, a fact any verifier can check against the introducer's standing at the introduction's basis checkpoint. Admission remains the governed checker's act, standing still comes only from an admission entry, and an introduction confers none. Introductions stand designed in the protocol and unbuilt in the machinery.

What has been proven, and at what strength

The claims on this page stand at the strengths the stage reports state, and at no greater strength.

• The canonical verifier's proof battery passed nine of nine checks under a network tripwire, each with zero network attempts recorded against the armed guard. Run again from the copy staged into the repository, all nine checks passed with zero network attempts recorded on every check.
• The revocation machinery built into the live registry home passed its battery sixteen of sixteen on the machinery's fixture line. On that line the staged canonical verifier returned refused_revoked for the fixture self revocation, at reason operator-request under the node key, and for the fixture governance revocation, at reason key-compromise under the registry key, while the real Nodes 002 and 003 still verified.
• The operator command arc standing is packaged in the served field kit under the handshake command specification, carrying the canonical verifier revised under specification v1.0 and applied by name in its own standing document and guide. Its packaging battery in the rulings form passed 41 checks in all at the two-account strength the specification names as its floor.
• The node channel in backend v27 carries the canonical verifier's verdicts unmodified, from a vendored copy byte-identical to its canonical home and revised under specification v1.0. Its staging battery passed 23 of 23 with the addressing regression at 30 of 30, and the production copy it serves returned standing_verified for Nodes 002, 003, and 007 from the published record at eleven entries.
• The application renders the channel's verdicts without recomputing them, and its render suite stands at 135 checks green of 135 against the channel's recorded verdict objects. The application holds no channel session in the current build, so no mailbox thread yet carries a verdict.
• The rulings revision's fixture battery passed 30 of 30 against the revised machinery and verifier, proving a governance revocation honored only with a countersignature from a second custody seat, a self revocation honored on its single signature, and verdicts anchored to the checkpoint key that signed their basis across a rotation.

What the protocol does not solve

The verifier proves statements about keys and about a signed public record. It proves that an address recomputes from a key, that a signature was made by whoever holds that key, that a ledger chain recomputes, and that a checkpoint signature binds the copy in hand. Everything the network actually means by trust rests partly on those proofs and partly on things no proof in this design touches. Standing is meaningful because admission is a governed human act, because the economics make fake nodes unprofitable, and because one institution's checkpoint key anchors the published record. Those groundings are named below, one by one, with the path past each anchor stated as design where a design exists and as open where none does.

Residue one. Sybil grounding is governance and economics, never cryptography

Anyone can generate an Ed25519 key in a fraction of a second, at no cost, forever. An address therefore proves that a key exists and that someone holds it, and it proves nothing about how many other keys the same holder has made. The protocol cannot distinguish one operator with one node from one operator with ten thousand nodes, and no change to the cryptography can make it do so. The network's actual Sybil grounding has two parts, and neither is a proof. The first is governed admission, because a proposal is settled by the institution's checker and its operator process before any standing exists, and a key nobody admitted has no standing to abuse. The second is the anti-Sybil economics of the adopted schedule, whose published appendix works the attack arithmetic in the open and shows the attacker's liquid yield at zero across the leak paths it models. A stranger reading this design should take the point at full size. If governed admission weakens, or the economics are shown wrong by measurement, the Sybil resistance of this network weakens with them, and the cryptography will not notice.

Residue two. Every verdict anchors to one checkpoint key

Every standing verdict in this design is computed from a copy bound by a checkpoint, and every checkpoint in the registry's history carries one key identifier, arc-registry-checkpoint-1. The private half of that key is a single file in the registry home. The security sweep of October 19, 2026, recorded that the key rests as a single file with no rotation or revocation record, and that state of affairs stands today. The consequence is plain. Whoever holds that key can sign a checkpoint binding a ledger of their own construction, admitting their own nodes and revoking anyone's standing, and every verifier that trusts the published public key will accept the result as the record. The design's own revocation machinery sharpens the point, because the governance revocation path deliberately gives this same key the power to withdraw standing. The power is the point, for the compromise case, and the concentration is the residue.

The path past this anchor has three parts, and each is stated at its true strength. Key rotation with signed succession is a design, not a build, in which the current key signs a checkpoint that introduces its successor and verifiers follow the chain. Checkpoint signing under the adopted custody rule, treasurer plus one other of three seats, is adopted doctrine whose sittings have not yet run, so the two-of-three form exists on paper and the single file exists in fact. Key pinning in shipped surfaces, where the application and the channel carry the expected checkpoint fingerprint and refuse a copy signed by any other key, is a design the integration stages can build, and the verdict contract already carries the fingerprint on its face for exactly this purpose. Until those land, the honest sentence is the short one. The published record is as trustworthy as one well-kept key.

Residue three. The center is dark at verification time, not absent from the system

The center-dark proof shows that verification needs no live center, and that is a real property worth having. It does not show that the system has no center. Admission is performed by the institution, in this era by Noetica under KORE admission for the founder, and the registry a stranger verifies against is the registry that process published. Two operators who have never met can indeed check each other's standing without asking anyone live, and what they are checking is a record a center admitted and a center signed. Federation in this design means the center publishes and steps back, not that no center exists. The path past this anchor would be plural registries whose checkpoints cross-sign one another, or an admission process run by the operators themselves under a shared rule, and neither is designed here. Both are open. A reader who wants trust with no institution in it at all is reading the wrong design, and this statement would rather say so than let the center-dark result be misread as that stronger claim.

Residue four. A verdict is only as fresh as the copy in hand

The protocol prints the basis checkpoint on every verdict, so staleness is visible. Visible is all it is. A party who can keep a victim reading an old copy can hide a revocation from that victim indefinitely, because the old copy still verifies perfectly and still reports the revoked node as standing. The verifier cannot force freshness, and no purely local check can. The path past this anchor is peers comparing checkpoint heads with one another, so a stale copy is exposed by any fresher neighbor, together with a published expectation about checkpoint cadence. Both are design directions, neither is built, and the exposure stands in the meantime. Any surface that renders a verdict without rendering its basis date has thrown away the one protection the protocol does give, and the specification says so.

Residue five. Identity proves a key, and the record claims the rest

An admission entry names a node and an operator in ordinary words, and those words are claims the governed admission process accepted, not facts the cryptography established. The proofs in this design bind keys to addresses and signatures to keys. The binding between a key and a person, a company, or a place comes from the proposal the operator signed and the process that settled it. Locality is the operator's own published choice, at the precision the operator chose, and it is evidence of what the operator said and of nothing else. A verdict that reports a name and an operator is reporting the record's contents at the strength of the record, and the verdict contract carries them as data rather than as verified attributes for exactly this reason.

Residue six. Standing says nothing about reachability or behavior

Every admission in the current registry carries a null endpoint, and standing verification would succeed for a node that has been switched off for a year. Standing also says nothing about how a node behaves once trusted, what work it will accept, or whether its own records are honest beyond the chain the registry holds. Those questions belong to presence, to the settlement layer's own evidence, and to the trust policies nodes apply after standing is known. A surface that renders a verified standing as a green light for consequential work without those layers has overstated this protocol, and the specification's scope section exists to prevent exactly that reading.

Residue seven. The public record is public, and permanent

The ledger names operators, coarse localities, and now revocation reasons, in a record designed to be copied by anyone and never edited. Standing verification adds no disclosure of its own, and that is the good half. The hard half is that admission and revocation are permanent public facts about named operators, correctable only by further entries that also stay public. An operator weighing registration should weigh that permanence with open eyes, because this design cannot offer a quieter version of a public record and remain the design it is.

What Stage 1 itself leaves unproven

The residue statement closes with what its own first stage left unproven, written at Stage 1 and carried here with one sentence recut for the public page.

Stage 1 proves the verifier against the true published record and against fixture nodes on a scratch copy. The revocation demonstrations use fixture keys created for fictional nodes, because the real checkpoint private key never leaves the registry home and no real node's private key was available to this run or should have been. The mechanism is therefore proven at fixture strength for revocation and at full published strength for standing and refusal of the unenrolled. The first governance revocation of a real standing, if one is ever needed, will be the machinery's first live exercise, and the registry act stage is where a real revocation entry first becomes possible at all. The introduction edge is designed and unbuilt, and its open points are left open in the specification at Section 8.

Open questions in this specification

This specification leaves five of the following points open and rules two of them. The five open points stand here as open questions in the protocol. Until a later revision settles them, an implementation should not assume an answer to any of the five.

• F1. Whether introductions are recorded in the ledger as their own entry kind, or travel only as signed objects held by the parties. The draft designs them as signed objects.
• F2. Whether an introduction can be withdrawn, and by whom.
• F3. Whether an introduction's scope may name intended roles or capabilities, or names identity alone as this draft has it.
• F4. The default lifetime of an introduction, and whether expiry is mandatory.
• F5. A governance revocation signed by the registry checkpoint key requires a countersignature from a second custody seat before a verifier honors it.
• F6. Whether the departure entry the registration record anticipates ships in the same registry act as the revocation kind, or in a later one.
• F7. The checkpoint key rotates only by a governed act recorded in the ledger, signed by the old key and countersigned under the custody rule, naming the new key and effective from a stated checkpoint forward, and verdicts anchor to the key that signed their basis checkpoint.

Two of these stand on the grade's face. F5 and F7 are the flags the sealed grade statement carries as ruled, and they stand ruled and implemented here.

Conformance

An implementation conforms to this specification when it produces the verdict contract of Section 5, applies the semantics of Section 6 exactly, and passes the proof battery the Stage 1 report records. An implementation conforms to this revision when it also honors a governance revocation only with a valid countersignature from a second custody seat, refuses a rotation entry whose document lacks a valid countersignature, and keeps a verdict anchored to a pre-rotation basis verifying after the rotation stands, proven by the extended battery the revision's report records. A surface that renders verdicts conforms when it renders the canonical verifier's output without recomputing, rewording, or upgrading it.

The protocol stands as specification v1.0, written October 20, 2026, revising draft v0.1 of October 19, 2026, which stands unedited beside it. It is carried into the flagship repository on the branch docs/federation-trust-20261019, and whether it merges to main is the founder's word. This page is generated from that specification and from the residue statement draft beside it, and it is regenerated rather than edited.

Status, plainly. The protocol stands at specification v1.0 and its grade stands as the face above states, with F5 and F7 ruled and implemented. Stranger verification is possible from the published record, and this page claims exactly that and no more.