Nothing here asks for your faith. Every row names the mechanism, then hands you the way to test it — because a guarantee you cannot check is just a slogan with better typography.
Signatures are real cryptography, not decoration.
verifiable nowWhat backs itEd25519 sign/verify and SHA-256 run through the browser's own Web Crypto (crypto.subtle). No hand-rolled hashing anywhere in the proof path.
How you checkOpen the live verifier and tamper with a signed request — the signature check fails on its own. Or open DevTools on any page and call crypto.subtle yourself.
await crypto.subtle.verify({name:'Ed25519'}, pub, sig, tamperedBytes) // falseRun the verifier →Two independent implementations reach the same verdict.
verifiable nowWhat backs itA second engine written in Rust — sharing no code with the TypeScript one — implements the same Border Control algorithm. A standard is only real when two implementations agree. Read the limit precisely: both were written by us, so this demonstrates implementation diversity, not third-party adoption. The milestone we have not reached is someone unrelated to this project building a conformant verifier from the written spec alone.
How you checkClone the public repository and run its hostile conformance suite. It asserts the exact reason code for every vector. Then run the two cross-runtime harnesses. The first pushes the same escalation cases through both engines and compares the verdict AND the dimension that refused — agreeing on a refusal is weaker than agreeing on why. The second compares the §10 receipt proof hashes, which is stronger still: a field one runtime fails to commit shows up as a mismatch even when both return the same decision. Note the published 0.1.0 on crates.io is immutable, so the registry still serves the older attenuation rule until a semver bump; the repository is current.
cargo test # 49 passed; 0 failed
cargo run --example cross-check | npx tsx scripts/cross-runtime-check.ts # 16/16 agree
cargo run --example receipt-proofs | npx tsx scripts/receipt-proof-check.ts # 6/6 proofs identicalRead the Rust implementation on GitHub →The verifier is installable, not just readable.
verifiable nowWhat backs itBoth crates are published on crates.io at 0.1.0, so the verifier can be added as a versioned dependency instead of copied by hand. That version is immutable — it can never be replaced, only superseded. Read the limit precisely: publishing makes the standard reachable, not adopted. A registry entry is distribution, not endorsement.
How you checkAdd the crate to an empty project and build against it. The verifier you compile is the one we published, not a copy we handed you.
cargo add echo-authority-core # 0.1.0See it on crates.io →It speaks DID, Verifiable Credentials and KERI — and still refuses to call them authority.
real · limit labeledWhat backs itA live bridge resolves DIDs, verifies credentials against the issuer's current key state, and walks KERI-style key event logs with pre-rotation, so a stolen signing key cannot rotate an identifier to a key nobody pre-committed to. A credential may satisfy a condition on a grant; a credential that carries a capability throws before its signature is even checked. Read the limit precisely: this interoperates in structure, not in full spec conformance — SPKI base64 instead of publicKeyMultibase, no JSON-LD canonicalisation, local rather than networked DID resolution.
How you checkRun the suite. The case that matters most is a DID and a credential that both verify completely and still mint nothing — because identity is not authority. Then check that a credential signed by a rotated-out key gets its own verdict, distinct from a forgery.
npx tsx scripts/authority-did.test.ts # 34 passed; 0 failed
# did-identity-only -> IDENTITY_IS_NOT_AUTHORITYTranslate a credential yourself →The rules are falsifiable, not vibes.
verifiable nowWhat backs it18 published conformance vectors, each asserting the exact reason code a conformant verifier MUST return — value caps, expiry, replay, forbidden capability, delegation subset, and more.
How you checkRun the suite in the page and watch every vector go green, then download the vectors as JSON and check them against your own implementation.
conformance-vectors.json → assert borderCheck(v) === v.expectedReasonDownload the vectors →The history cannot be rewritten behind your back.
verifiable nowWhat backs itAn RFC-6962-style append-only Merkle log. Inclusion proves an entry is committed under a signed root; consistency proves the old log is an exact prefix of the new one.
How you checkVerify an inclusion proof, then tamper with a past entry — the consistency proof fails and the witness refuses to cosign.
verifyInclusion(leaf, auditPath, signedRoot) === trueBreak the log yourself →No single signing key is the root of trust.
real · limit labeledWhat backs itThree separately keyed witness services, each with its own stable published Ed25519 key, cosign checkpoints. A run is only anchored at a 2-of-3 quorum, so no single key can forge or block it.
How you checkFetch the public roster and re-verify each cosignature yourself against the key it publishes. Every endorsement is independently checkable — but note the limit: separately keyed is not independently operated. All three still run on our infrastructure, so one operator could in principle move all three keys. The quorum is real cryptography; it is not yet real federation.
curl /api/witness # roster: id + publicKey (never a secret)Re-verify the quorum →The ledger is anchored on Bitcoin — not just on our word.
verifiable nowWhat backs itThe anchor-chain tip (one hash committing the whole ordered history) is submitted to real OpenTimestamps calendar servers. Once a block confirms it, the committed prefix cannot be altered or backdated without breaking the anchor. What Bitcoin attests is when this commitment existed — not that every logged event was true, nor that nothing was omitted before the tip was committed.
How you checkDownload the .ots proof and verify it with the standard OpenTimestamps client. It trusts neither us, nor the calendars, nor our database — only Bitcoin.
ots verify echo-anchor-<tip>.otsDownload an .ots proof →Proof crosses. Data never does.
verifiable nowWhat backs itA structural boundary, not a promise: the publish path whitelists exactly four fields and requires an opaque commitment — anything else throws. The database tables have no column for content, payer, or payee at all.
How you checkTry to smuggle content past the boundary in the live console. It refuses by construction, before anything is written.
assertNoLeak({...entry, secret:'x'}) // throwsAttempt the leak →An over-reaching app cannot even form a request.
verifiable nowWhat backs itThe Authority Object's forbidden set is enforced when the object is constructed — a grant asking for a recovery fragment, a birthdate, a blank cheque, or no expiry cannot be built at all.
How you checkOpen the consent sheet and look at the refused asks. Each one shows the actual rule the engine tripped — the refusal is computed, never written by hand.
mintAuthorityObject(draft) // throws: unbounded-scopeWatch it refuse →The server that carries your data cannot read it.
verifiable nowWhat backs itVaults are sealed in the browser with AES-256-GCM; the relay stores ciphertext and rejects anything that looks like plaintext. Keys are wrapped device-to-device with X25519 and never reach the server.
How you checkRun the sealed-box loop, then ask the relay for the raw stored blob and read it yourself — it is ciphertext.
GET /api/relay/blobs/:id # body_b64 = ciphertext onlyRead what the relay stores →Revocation is real and it survives a reload.
verifiable nowWhat backs itRevoking a delegation writes to your own device and is re-read on load. The kill switch revokes every standing grant at once.
How you checkRevoke a delegation, reload the page, and confirm it is still revoked and the agent still cannot act.
Revoke and reload →Offline payments are genuinely signed — the transport is simulated.
real · limit labeledWhat backs itSigning, queueing, sync, replay protection, and double-spend prevention are all real. But a browser cannot advertise over Bluetooth to another browser, so peer discovery is simulated and labeled as such.
How you checkTamper with a payment packet in transit — the receiving side rejects it on the signature. True phone-to-phone discovery needs a native app.
verifyPayment(tamperedPacket) === falseTamper with a packet →The Solana rail is wired but not yet live.
real · limit labeledWhat backs itThe Echo-ID-to-Solana-address mapping and the signed authorization are real cryptography. The on-chain transaction is simulated until the token exists — one function swaps, and the governance model does not move.
How you checkVerify the address binding yourself: a Solana address is an Ed25519 public key, so the signature proves the address authorized the link.
verifySolanaLink(link) === trueCheck the binding →