COMPLYR LogoComplyr

FHE Compliance Model

Deep dive into the metadata schema and client-side FHE flow.

Compliance Model & FHE

Compliance Dashboard

The compliance metadata schema

Complyr captures two dimensions of compliance metadata per recipient per payment:

Jurisdiction — the regulatory jurisdiction applicable to the recipient. Mapped to a uint8 enum on-chain.

CodeValueLabel
0NONENot specified
1US_CAUS — California
2US_NYUS — New York
3US_TXUS — Texas
4US_FLUS — Florida
5US_OTHERUS — Other
6UKUnited Kingdom
7EU_DEGermany
8EU_FRFrance
9EU_OTHEROther EU
10NGNigeria
11SGSingapore
12AEUAE
13OTHEROther

Category — the expense classification for the payment. Mapped to a uint8 enum on-chain.

CodeValueLabel
0NONENot specified
1PAYROLL_W2Payroll (W2)
2PAYROLL_1099Payroll (1099)
3CONTRACTORContractor
4BONUSBonus
5INVOICEInvoice
6VENDORVendor
7GRANTGrant
8DIVIDENDDividend
9REIMBURSEMENTReimbursement
10OTHEROther

How FHE encryption works in Complyr

Complyr uses Zama's relayer-sdk-js for client-side encryption. The encryption flow is:

1. Instance creation. The SDK is loaded from Zama's CDN and initialised with SepoliaConfig, which contains the correct KMS, ACL, and gateway addresses for Zama Sepolia.

2. Input encryption. For each recipient's category and jurisdiction values, the frontend creates an EncryptedInput targeting the ComplianceRegistry contract address and the relay wallet address as the authorised caller:

const input = fhevm.createEncryptedInput(REGISTRY_ADDRESS, RELAY_ADDRESS);
input.add8(categoryValue); // uint8 enum value
const encrypted = await input.encrypt();
// Returns: { handles: Uint8Array[], inputProof: Uint8Array }

3. Handle and proof extraction. The resulting ciphertext handle (32 bytes) and zero-knowledge proof are encoded as hex strings and submitted to the registry. The canonical path is via the LayerZero bridge (ComplianceBridge → ComplianceReceiver → ComplianceRegistry). On testnet, the Flow EVM → Sepolia route has no DVN configured, so a relay API submits records directly to the registry with the same payload structure, proving the integration works end-to-end independently of the missing testnet infrastructure.

4. On-chain validation. FHE.fromExternal(handle, proof) validates the proof and returns a live euint8 handle bound to the Zama coprocessor.

5. ACL permission grant. The registry calls FHE.allow(value, address) to grant decryption rights to the master EOA and any active auditors.

6. Decryption. An authorised party decrypts their records by generating a keypair, creating an EIP-712 token scoped to the registry contract, signing it with their wallet, and calling fhevm.userDecrypt(handles, privateKey, publicKey, signature, ...). The Zama KMS validates the signature, checks ACL permissions, and returns plaintext values.

The trust model

Complyr does not enforce the accuracy of the metadata a company submits. A company self-reports its categories and jurisdictions, consistent with how traditional accounting works — accountants self-report but bear legal liability for what they commit. Complyr enforces:

  • existence of compliance records
  • immutability of records
  • cryptographic linkage to transactions

Once a compliance record is committed, it cannot be altered or deleted. The combination of a deterministic intent identifier and an immutable on-chain record provides the same accountability primitive as a signed accounting entry in traditional finance.

The system is designed to give regulators a credible compliance ledger, not to replace the legal obligations of the business.

On this page