Builder Track · Zama Developer Program

Confidential compliance attestations for institutional onchain finance.

AttestRail enforces eligibility, risk, and exposure rules over encrypted state. Per-user compliance attributes, issuer policy thresholds, and an issuer-wide aggregate exposure counter all stay encrypted. Only the final eligibility decision is revealed.

View on GitHub How it works
Pre-MVP · in development Built on Zama FHEVM. Contracts and demo land during the Builder Track.

The problem

Public chains expose too much. Regulated finance needs the opposite.

RWA platforms, stablecoin issuers, and regulated DeFi applications must verify investor eligibility, jurisdiction, sanctions exposure, risk tier, and transaction limits. Today these checks are handled offchain, or through public allowlists. Both are leaky: allowlists publish counterparty relationships, offchain compliance breaks composability and auditability.

  • Investor identity, jurisdiction, and risk are commercial signal.
  • Issuer exposure thresholds and aggregate utilization are commercial signal.
  • Public eligibility decisions across many checks leak information about all of the above.

How it works

Five components. One encrypted compliance flow.

  1. 1

    Approved attester signs the profile

    An off-chain compliance provider verifies the user's real-world identity, encrypts the attributes for the registry contract and user wallet via the Zama Relayer SDK, and signs an EIP-712 attestation binding the encrypted handles, expiry, and a single-use nonce to the wallet.

  2. 2

    Registry stores the encrypted profile

    AttestRailRegistry.submitProfile verifies the signer is in the approved set, the digest matches, the expiry is in the future, and the nonce is unused — only then does it ingest the ciphertexts via FHE.fromExternal.

  3. 3

    Issuer configures encrypted thresholds

    Public toggles and risk-tier ceiling sit alongside encrypted euint64 values for maxExposure and issuerExposureCap. Issuers can decrypt their own thresholds; the contract uses them in encrypted comparisons.

  4. 4

    Eligibility gate evaluates encrypted state

    PrivateEligibilityGate runs per-user policy checks plus an encrypted issuer-wide aggregate-cap check, then conditionally updates the encrypted aggregate via FHE.select. Blocked checks leave the aggregate untouched without any public branch.

  5. 5

    Only the eligible bit is revealed

    Async public decryption produces the final eligible/blocked result. MockRWAToken.gatedTransfer consumes the finalized check and performs the transfer. Per-user attributes, issuer thresholds, and aggregate utilization stay encrypted across all transfers.

Why FHE, not ZK

Shared, evolving state that no participant ever holds in cleartext.

ZK proves what the prover knows

Zero-knowledge proofs are well-suited to static per-user claims that the prover holds in cleartext: a credential, an inclusion in a list, a balance above a threshold the prover knows. There is always a participant in possession of the secret.

FHE evaluates what no one knows

AttestRail's load-bearing computation is the opposite shape. The issuer-wide aggregate exposure is shared, mutable encrypted state. No participant ever sees its cleartext. FHE evaluates the cap comparison directly, and FHE.select updates the aggregate so blocked checks leave it untouched without any public branch.

ZK approaches cannot maintain that aggregate. There is no prover who knows the value to prove anything about it. This is the primitive that makes AttestRail an FHE product rather than a generic privacy demo.

Trust model

Encrypted attributes are only as trustworthy as their source.

AttestRail does not allow users to author their own compliance state. Approved attesters are external compliance providers — KYC/AML vendors, internal compliance teams, or jurisdiction-specific regulated entities — whose signatures the registry verifies before storing any encrypted profile.

Layer 1 · Zama input proof

Confirms ciphertexts were correctly encrypted for the target user and contract.

Layer 2 · Attester signature

Confirms the underlying values came from an approved compliance source.

Both layers are required. Issuers configure which attesters they trust per jurisdiction or asset class.

Disclosure

Honest about what the eligible bit reveals.

Pattern A — async public decryption — reveals the cleartext eligible/blocked bit by design. This is the minimum disclosure required for a non-confidential mock token to act on the result. It is not a free disclosure: across many checks, eligible/blocked outcomes correlate with private attributes and can leak information about them.

We treat this as a disclosure to be managed, not denied. Production deployments are expected to pair AttestRail with:

  • Per-wallet rate limits on eligibility checks.
  • Batched check finalization across multiple users.
  • Issuer-initiated decoy checks to break attribute-to-outcome correlation.
  • Migration to confidential balances and FHE.select-gated transfers where even the boolean outcome is too sensitive.

The Builder MVP documents this exposure in its architecture and pitch rather than claiming full privacy under sustained observation.

Roadmap

Where we are and where this goes.

Builder Track MVP

  • Attester registry with EIP-712 verification
  • Encrypted compliance profile registry
  • euint64 policy thresholds
  • Encrypted aggregate-cap check via FHE.select
  • Mock RWA token gated by finalized check
  • Mock attester service (Relayer SDK)
  • Frontend demo with investor, issuer, and compliance views
  • Sepolia deployment with measured decryption latency

Next

  • Confidential transfer amounts (externalEuint64)
  • Inference-mitigation primitives: rate limits, batched finalization
  • Real attester integration
  • Selective disclosure flows with explicit FHE.allow per role

Beyond

  • Multi-issuer aggregate constraints
  • Cross-policy exposure netting
  • Confidential settlement primitives for institutional liquidity
  • Pilot integrations with regulated RWA platforms

Building a confidential primitive on Zama.

The repository, architecture documents, and Tech Verification live on GitHub.

View on GitHub Zama documentation