Smart Contracts

The project includes two sets of EVM contracts. The pilot contracts verify and mirror current pilot-transfer-v3 proofs; they exist in source and are tested locally, but are not deployed to any shared network. The legacy contracts serve the 16-signal demo profile; the Sepolia addresses below are historical testnet records of those. None of these contracts has been independently audited.

Pilot contracts (source, not deployed)

PilotGroth16Verifier checks the eight-signal pilot proof against a verification key and artifact manifest digest fixed at construction. It reports proofProfile as pilot-transfer-v3 and assurance as development-unapproved. Pairing alone does not reconstruct the transfer statement, check current state or consume a nullifier.

PilotCurrentRegistry publishes tenant checkpoints (revisioned heads for issuance, issuers, sanctions, credential, policy, valuation, participants and authorization) and statement bindings from one assigned publisher per tenant. inspect is a read-only call that checks a proof against a published statement, including the chain ID, the registry’s own address and the expiry. It then mirrors receipts that PostgreSQL has already consumed. It cannot create an authorization, and it cannot detect a publisher that lies about private records. See the registry trust boundary .

Legacy contracts: historical Sepolia deployment (July 20, 2026)

The July 20, 2026 manifest in packages/contracts/deployments/sepolia.json is a historical record of the legacy 16-signal demo. It is not a 0.7.2 deployment. The deployed registry has no VerifierRouter, and the current contract source is not applied to these addresses. Bytecode was present at all five on September 5, 2026.

Groth16Verifier

Checks cryptographic proof validity against its verification key. That check alone does not establish source authenticity, current state, legal compliance or authorization to execute a transfer. Verifiers and artifacts must match the intended proof version.

ComplianceRegistry

The development registry coordinates proof acceptance with other contracts. Its source checks duplicate transfer records, dependency pause/freshness, active VASP and submitting wallet, chain/contract domain, expiry and future timestamps, sanctions/issuer roots, transfer reference, configured thresholds, revocation and nullifier use. The current development code routes cryptographic verification through a versioned verifier router and configured selector.

Successful acceptance records the proof and consumes a nullifier. Read-only cryptographic verification in an SDK is a different operation. A recorded proof is not itself evidence of successful transfer settlement.

Legacy verifier rotation in source

Each scheme/version selector binds permanently to one verifier address and runtime code hash. Registration, changing the default and retirement require separate timelocks. Emergency disable takes effect immediately, including during retirement grace. These controls use the legacy 16-signal Groth16 interface; another proof system requires a reviewed adapter.

After a default swap, an in-flight statement can use verifyAndRecordWithSelector for at most 24 hours, subject to its own expiry and all current-state checks. The old declared transfer timestamp must precede cutover. Router retirement adds its own 24-hour limit; the earlier deadline governs. A retired verifier cannot remain the default. Both submission paths share records and nullifiers, and the domain continues to bind to the registry address.

The recorded Sepolia manifest has no router address and does not gain these source changes in place. See the decommissioning runbook  for the initial migration, delayed calls, recovery and historical shutdown evidence.

VASPRegistry

Stores registered VASPs, authorized submitting wallets, jurisdictions, discovery endpoints and the issuer Merkle root. Registration and directory metadata must be interpreted under an explicit trust policy; they do not independently establish licensing or factual credential validity.

SanctionsOracle

Stores a current root, update time, leaf count and bounded history. Controls include a one-hour update cooldown, a configured staleness window and a leaf-count floor. The history is a ring of up to 1,000 records, not a complete long-term evidence archive.

SanctionsRootRelay

Forwards authorized root updates to the oracle. A local tree rebuild is not evidence that every intended chain received its update.

Development

cd packages/contracts
npx hardhat compile
npx hardhat test

Use the ABI and deployment configuration for your exact target. Existing testnet addresses must not be represented as an independently audited production release.