Architecture & Flow

How Complyr Works

At a high level, every Complyr payment follows a consistent sequence:

1. Intent creation. A business creates a payment intent through the Complyr interface or directly via contract call. Along with recipient addresses and amounts, they attach compliance metadata: an expense category and a jurisdiction code per recipient.

2. Client-side encryption. Before anything reaches the blockchain, the compliance metadata is encrypted in the user's browser using Zama's fhEVM JavaScript SDK. The resulting ciphertext handles and zero-knowledge proofs confirm that the encrypted values are well-formed, without revealing the underlying data.

3. Payment execution on Flow EVM. The smart wallet executes the payment. For single and batch transfers, funds move immediately. For recurring payments, the intent is registered with the on-chain scheduler and funds are locked until each payment cycle executes.

4. Cross-chain compliance dispatch. The Compliance Bridge — a LayerZero V2 OApp deployed on Flow EVM — encodes the compliance report and sends it to Zama Sepolia. On mainnet this route has full DVN coverage. On testnet, no DVN is configured for the Flow EVM → Sepolia path, so a relay API submits records directly to the registry to demonstrate the integration end-to-end.

5. Encrypted record storage on Zama. The Compliance Receiver on Zama decodes the incoming message and calls the Compliance Registry, which validates the zero-knowledge proofs, materialises the FHE ciphertext on-chain, and grants access to the company's master wallet.

6. Selective decryption. The company owner or an authorised auditor can decrypt their compliance records at any time by connecting their wallet and signing an EIP-712 request through the Zama decryption gateway.

Architecture

Complyr spans three distinct layers. Each layer has a specific responsibility and communicates with the others through well-defined interfaces.

┌─────────────────────────────────────────────────────────────────┐
│                        APPLICATION LAYER                        │
│    Next.js · Privy · fhevmjs · Permissionless · Skandha (AA)    │
└────────────────────────────┬────────────────────────────────────┘
                             │ UserOperations (ERC-4337)
┌────────────────────────────▼────────────────────────────────────┐
│                  SMART CONTRACT LAYER — Flow EVM                 │
│   SmartWallet · SmartWalletFactory · IntentRegistry             │
│   ComplianceBridge (LayerZero OApp) · VerifyingPaymaster        │
└────────────────────────────┬────────────────────────────────────┘
                             │ LayerZero V2 cross-chain message
┌────────────────────────────▼────────────────────────────────────┐
│              CONFIDENTIAL RECORD LAYER — Zama Sepolia           │
│         ComplianceReceiver (OApp) · ComplianceRegistry          │
│                    (euint8 FHE ciphertext)                      │
└────────────────────────────┬────────────────────────────────────┘
                             │ Event indexing
┌────────────────────────────▼────────────────────────────────────┐
│                    DATA LAYER — Envio Indexer                   │
│              GraphQL API · Transaction history                  │
└─────────────────────────────────────────────────────────────────┘

ERC-4337 Bundler

Complyr uses account abstraction (ERC-4337) so that businesses interact through smart wallets rather than EOAs. UserOperations are routed through a self-hosted Skandha bundler deployed on Railway, because no public bundler currently supports Flow EVM testnet.

The bundler receives signed UserOperations from the frontend via Permissionless.js, validates them, and submits them to the EntryPoint contract on Flow EVM. The VerifyingPaymaster sponsors all gas fees, meaning users never pay gas directly — every transaction is gasless from the user's perspective.

In production, the paymaster would verify an off-chain signature to authorise gas sponsorship. In the current testnet implementation, sponsorship is unconditional for demo frictionlessness.

Data Layer — Envio Indexer

The Envio indexer provides the real-time transaction history that powers the Complyr dashboard. It runs on Envio's hosted infrastructure and indexes 7 event types across 3 contracts on Flow EVM:

SmartWallet events:

• Executed — single payment transfers
• ExecutedBatch — batch payment transfers
• IntentBatchTransferExecuted — scheduled payment batch executions
• IntentTransferSuccess — individual successful transfers within a scheduled batch
• TransferFailed — failed transfers within a scheduled batch
• WalletAction — all wallet operations with function selector tracking

SmartWalletFactory events:

• AccountCreated — new business account deployments

IntentRegistry events:

• IntentCreated — new recurring payment schedule creation
• IntentExecuted — scheduled payment execution
• IntentCancelled — schedule cancellation with refund

The indexer exposes a GraphQL API that the frontend queries for transaction history, wallet metadata, and intent state. Three entity types are maintained: Wallet (aggregate account data), Transaction (individual indexed events), and Intent (recurring payment state for cross-referencing executions).

Contact Book

Complyr includes a built-in recipient address book backed by a Neon PostgreSQL database. Companies can save, label, and reuse recipient addresses together with their associated compliance defaults — preferred jurisdiction and expense category — so they do not need to re-enter compliance metadata for repeated payments to the same party.

Contacts are scoped per company, keyed by the Flow proxy address. When a contact is selected in the payment form, the jurisdiction and category fields are pre-populated automatically, ensuring consistency across compliance records over time.

The contacts API is served from apps/web/src/app/api/contacts and backed by Drizzle ORM on Neon PostgreSQL. The contact schema stores: wallet proxy address, recipient address, label, default jurisdiction, and default category.