Eudemonia
Compliance as a cryptographic primitive.
Created on 21st February 2026
•
Eudemonia
Compliance as a cryptographic primitive.
The problem Eudemonia solves
Institutional cross-border payments have three persistent problems.
Settlement is slow and expensive. SWIFT transfers take 3–5 days and add fixed fees plus FX spread. For a company paying a small group of contractors monthly, the annual cost is material.
Compliance records are not independently verifiable. KYC status, approval sign-offs, and policy versions sit in spreadsheets, inbox threads, and vendor portals. When proof is needed later, it is reconstructed as PDFs. Those artifacts are not cryptographically bound to the payment that executed.
Privacy blocks shared infrastructure. Institutions do not want salary amounts, positions, or counterparty identities exposed on a shared ledger. This creates a coordination failure. End-to-end privacy across request, approval, settlement, and audit remains incomplete in workflows institutions can actually run.
Eudemonia treats compliance as a cryptographic primitive. A request is committed on-chain as a hash. A policy is committed on-chain as a hash with validity constraints. Approvals are signatures. Off-chain, SP1 generates a proof that the policy was applied to the committed inputs. On-chain, ADI verifies the proof and executes settlement only if the proof binds to both the request commitment and the active policy. Sensitive evidence stays off-chain. Disclosure is configurable. The chain retains a replayable audit trail that does not depend on trusting the operator.
Challenges I ran into
-
Making compliance enforceable, not just documented
The difficult part was turning “we ran the checks” into a condition for settlement, without placing private data on-chain. The approach is commitment-based: commit the request (parametersHash), commit the policy (policyHash), prove policy execution off-chain with SP1, and enforce on-chain only when the proof matches both commitments. -
Defining hash boundaries precisely
If the script, the SP1 program, and the contracts disagree on canonical encoding, failures look arbitrary. The fix was to treat the request commitment format and the policy commitment format as hard interfaces, then add tests that fail immediately if any component drifts. -
Privacy versus auditability
Institutions need audit trails. Employees do not want salary or payout address linkability visible to coworkers. The goal is configurable disclosure: keep enforcement public at the level of commitments and proofs, keep sensitive details off-chain or only available under authorized access, and support an Umbra-compatible payout mode for address privacy. -
Keeping scope narrow
It was important to ship one complete workflow end to end: policy, request, proof, settlement, audit. Everything else is treated as an extension rather than part of the MVP. -
SP1 Proof generation time, this was cumbersome my latop would heatup and freeze
Use of AI tools and agents
AI was used for iteration speed: drafting interfaces, checking edge cases, and improving test coverage. The execution path is deterministic: proofs are produced by SP1, verified on-chain, and settlement follows from that verification. There is no ML in the core trust path.
Tracks Applied (3)
Devtopia
ADI Payments Component for Merchants
ADI Foundation
Open Project Submission
ADI Foundation
Technologies used
Cheer Project
Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.