Limitations & Roadmap

Limitations & Known Constraints

This section documents the honest edges of the current implementation. We are not a company hiding problems — we are builders who understand their own system.

Testnet only

Complyr currently runs on Flow EVM testnet (chain ID 545) and Zama Sepolia. The infrastructure is not deployed to any mainnet. Contract security has not been audited. Do not use this for real financial transactions.

LayerZero: no DVN coverage on the Flow EVM Testnet → Sepolia route

The cross-chain compliance bridge is fully implemented and deployed. The ComplianceBridge contract on Flow EVM correctly encodes and dispatches messages via LayerZero V2. However, the Flow EVM Testnet → Sepolia route has no DVN (Decentralised Verifier Network) configured in LayerZero's current testnet infrastructure. Messages reach the LayerZero endpoint and are accepted, but are never forwarded — because no verifier network exists for this specific path on testnet.

This is not a limitation of the bridge implementation. The Flow EVM → Sepolia route is supported on mainnet, which is why it was chosen for the architecture. The same contracts and message encoding work correctly on any network where the route has DVN coverage. LayerZero support has been contacted to request DVN availability for this testnet route.

As a functional substitute, a relay API (/api/relay/compliance-record) submits compliance records directly to the Zama registry with the correct payload structure, demonstrating the full end-to-end integration without depending on missing testnet infrastructure. The bridge remains the canonical path for production.

Auditor FHE access revocation is partial

When an auditor is removed, their address is revoked from new records going forward. However, FHE ACL permissions already granted to historical records persist — this is a property of how Zama's on-chain ACL works and cannot be undone without a redesign of the ciphertext storage model. The practical implication is that removing an auditor should be understood as preventing future access, not retroactively restricting historical access.

Recurring payment execution reliability

Recurring payments depend on a keeper service that must remain online. If the keeper goes offline, executions are simply skipped — there is no catch-up mechanism or queuing. The shouldExecuteIntent function checks whether the current time falls within the valid execution window; missed windows are not backfilled. For production use, this would need to be replaced with Chainlink Automation or an equivalent decentralised execution network.

Maximum recipients per intent

The IntentRegistry enforces a hard limit of 10 recipients per intent. This is sufficient for most payroll and subscription use cases but is not suitable for large-scale airdrop-style distributions.

Gas limits on addAuditor for large ledgers

The retroactive FHE access grant loop in addAuditor iterates over all historical records for a company. For companies with hundreds or thousands of records, this call may approach or exceed block gas limits on Zama Sepolia. This is a known limitation of the current architecture and would need to be addressed with a paginated batching mechanism in production.

fhEVM client-side encryption performance

Encrypting compliance metadata in the browser using Zama's WASM SDK is computationally intensive and can take 2–10 seconds per transaction, during which the browser tab may appear frozen. This is an inherent property of the current fhEVM client-side toolkit. Future versions of the Zama SDK are expected to improve this significantly.

Single jurisdiction + category per recipient

The current schema supports one jurisdiction and one category code per recipient per transaction. Multi-jurisdiction or multi-category payments — where a single payment has mixed compliance implications — are not supported in this version.

---

Roadmap

The following capabilities are planned for development after the current release.

Near term

Recurring payments stabilisation. The recurring payment flow (intent creation → scheduled execution via keeper → compliance record linking) is fully designed and implemented but requires additional testing and edge case handling before it can be considered production-ready.

Dedicated auditor dashboard. A purpose-built interface for external auditors and regulators to browse, filter, and export compliance records. The current auditor portal is functional but minimal.

Medium term

Tax reporting interface. Aggregation of encrypted compliance records into jurisdiction-specific report formats (e.g., IRS Schedule C summaries, HMRC categorisation, FIRS-compatible formats for Nigeria). The report generator infrastructure is already in place in the frontend; this extends it with structured export formats.

Multi-jurisdiction and multi-category support. Extending the compliance schema to allow a single recipient to have multiple applicable jurisdictions or categories, necessary for cross-border contractor payments with split reporting obligations.

Compliance health scoring. A richer scoring model that incorporates completeness of metadata, consistency with prior periods, anomaly detection, and jurisdiction-specific threshold checks.

Paginated auditor grant. A batching mechanism for addAuditor that allows safe retroactive access grants on ledgers with large numbers of records, without risk of hitting block gas limits.

Long term

Mainnet deployment. A security-audited deployment to Flow EVM mainnet once the testnet implementation is validated.

On-chain compliance proofs. Rather than relying on auditors to manually decrypt and verify records, generate ZK proofs that attest to specific compliance properties (e.g., "all payments in Q3 were categorised" or "no payments were made to sanctioned jurisdictions") without requiring full decryption.

DAO treasury integration. Support for multi-sig governance over compliance metadata, allowing DAOs to attach compliance records to grant distributions and contributor payments through their existing governance flows.

Programmable compliance rules. Allow companies to define on-chain compliance policy (minimum metadata completeness, jurisdiction whitelists/blacklists, category budget caps) that the smart wallet enforces at transaction time.