The Touchstone Stack

Disclosures arrive as prose, on a schedule the reader does not control, and they change. A risk team re-reads them by hand and writes the conclusion into a spreadsheet; nothing downstream can tell which sentence the conclusion came from, or whether that sentence still says the same thing.

Includes

• AI Control Compiler — proposes candidate controls that cite byte-exact spans of the issuer's own documents. A human approves or declines each one, and the decision is recorded as an EIP-712 signature, not a checkbox. Control language →
• Evidence Monitor — scheduled captures of every source, digest-addressed, so a later edit to a page shows up as a different digest instead of disappearing into the same URL.
• Policy Profiles — versioned subsets of the approved controls, each published under its own registry key: disclosure-freshness:1 and nav-settlement:1.
• Source & provenance engine — every result traces back to the retrieval that produced it: which source, captured when, at which content digest, and which control the bytes were cited for.

Turn changing disclosures into versioned, cited and machine-checkable policy.

Live today

9 controls approved and 7 declined against 7 monitored evidence sources, published as versioned policy profiles.

Proof point

Every decision in the approval ledger carries the approver's recoverable signature — approver 0x537873b087654395CB0A487B50d0bFBe15fA16Bc, ledger digest 0xb2d8ab788a0ac43b18d0438ba50daf7e3a098003ea0650d8561c0cbb475f5c91. Recover the address from the signature and you have named the human who said yes.

See how a control is compiled and cited →

A protocol that wants to accept a tokenized fund has no way, inside a transaction, to ask whether the evidence behind it is current. So it either trusts an off-chain process it cannot see, or it declines the asset entirely.

Includes

• Registry v2 — EIP-712-attested reports that a relayer can submit without being the reporting authority, so publication cannot be stopped by one hot key. Registry →
• Registry v1 — publisher-authenticated commitments, still live and still read on both chains; a later report corrects an earlier one by naming it, never by overwriting it.
• AssetGate policy gates — one immutable question, check(assetKey) → (allowed, reason), with the policy id, policy root, control-set root, approval digest, publisher and freshness bound at construction. Nobody can widen the gate afterwards. Reports expire at end of day UTC and re-publish at the daily window, so a record that stops arriving withdraws the gate's answer by itself. AssetGate →
• GuardedAction decision receipts — permitted and refused, both as real transactions. A refusal leaves the same kind of evidence a pass does, with the contract's own reason string attached.

Permit, block or suspend an action from a current policy verdict.

Live today

Both registries and the policy gates run on X Layer mainnet and testnet. Registry v2 on mainnet is 0x0dAb4A5B7dd24434Ab6564734E26d3d76985352C; on testnet it is 0xBaE680e671e0451b95c9b09eD15F70C3E1EA7720.

Proof point

9 enforcement transactions across both chains, permits and refusals alike. The mainnet gate at 0xAac48DC261B04737FDCB101D5049395121034a83 first answered allowed for the disclosure-freshness policy on 2026-08-19; verdicts expire at end of day UTC and renew at the daily window — check it live.

AssetGateV2 and RWAAdmissionController are deployed on both chains. Mainnet: 0x8641CF6d40524AC55aBd0a02601AfBd374EFB059 and 0x5C5265392701A99cbB137aF8116E0F97f630329A. Testnet: 0xE1e2C897A43674bba6c3fbE6584a703a09939930 and 0x1822Cde72cD1aB560d8fdD795Ac6971b122BbA28.

See the gate's pins and its two receipts →

A claim you can only read on the publisher's website is a claim you have to take on trust. An auditor needs to recompute the result from the bytes, on their own machine, and get the same answer or a specific disagreement.

Includes

• Signed bundles — the report, its control results, the evidence digests, the approval ledger and the registry attestation, in one downloadable file under one signature.
• In-browser verifier — the Policy Terminal's verify panel runs the checks locally in your tab. Nothing is uploaded, and the panel states what it does not check. Open the Terminal →
• CLI and manual recipes — the same checks from a shell, or step by step, so a reviewer can follow them without running our code. Verification bundles →
• Correction history — supersession is explicit and sequenced: a correction names the report it corrects, and the corrected report stays published and checkable.

Verify the report independently without trusting the website.

Live today

25 reports published across 2 chains, 20 of them confirmed, with the signed bundles retained alongside them.

Proof point

23 downloadable bundles — and every published claim on this site is rendered from one canonical data source at build time, so a page cannot drift from the record it describes.

Verify a bundle yourself →