Limitations & Roadmap
Honest constraints in the current implementation and the most important next steps for the product.
Current limitations
Testnet product
Complyr currently targets Ethereum Sepolia. This is demo-stage infrastructure, not production-ready treasury software. The contracts have not been through the security and operational review expected for live business funds.
Auditor removal is not full cryptographic revocation
Removing an auditor does not retroactively revoke every past FHE permission already granted to ciphertexts. It removes the auditor from the active access list and prevents future access flows, but historical permissions may remain usable through the KMS path.
This is an important trust-model limitation and should be understood clearly by anyone evaluating the system.
Narrow scope enums and limits
The current contracts enforce hard-coded bounds:
- maximum
5auditors per company wallet - maximum
20active review tests per company wallet - category IDs limited to
1..10 - jurisdiction IDs limited to
1..13
These limits are sensible for a demo, but not enough for a broader enterprise product.
Reference IDs remain plaintext
Amounts, categories, and jurisdictions are encrypted, but reference IDs are not. This was a deliberate usability tradeoff. Reference IDs link an onchain payment record back to a business's internal accounting system — without them, the audit trail is cryptographically strong but difficult to reconcile against real business records.
Encrypting them with Zama FHE is non-trivial. The Zama type system supports fixed-size numeric types but has no native string type. The most viable path would be to hash the reference ID onchain and store the plaintext offchain — but that would break the current audit trail linkability. This is included in the near-term roadmap.
No native regulatory rules engine
Complyr stores context and enables private review, but does not enforce jurisdiction-specific rules such as tax withholding logic, sanctions screening, invoice validation, or reporting deadlines. It is better described as private audit infrastructure than a complete compliance automation stack.
Roadmap
Near term
Stronger auditor workflow. The current portal proves the concept. The next step is a fuller workflow for historical review, exports, and cleaner regulator-facing reporting.
Better privacy controls for identifiers. Reference IDs should become optionally private — either encrypted offchain or replaced with a hash — so teams can choose between usability and stricter privacy.
Medium term
Jurisdiction-aware reporting packs. The current dashboards can summarize and export decrypted records, but do not yet produce regulator-ready reporting packages by jurisdiction.
Richer policy primitives. Businesses should be able to define rules such as required categories, approved jurisdictions, and budget thresholds before a payment is allowed through.
Broader payment coverage. The model should expand beyond the current fixed category and jurisdiction enums to handle more realistic global treasury operations.
Long term
Mainnet deployment with formal review. Production use requires audited contracts, hardened relayer and automation assumptions, and a clearer operational trust model.
Proof-based regulatory attestations. Complyr should move from "decrypt and inspect" toward "prove and verify," where businesses generate attestations about their ledger without exposing raw records.
Deeper compliance integrations. The long-term opportunity is connecting private onchain audit data to the real workflows businesses and regulators already use.