Inspiration
Autonomous financial agents are becoming capable of researching markets, generating trading intentions, checking risk constraints, and preparing transactions. However, allowing agents to act independently introduces a coordination problem: different institutions may have compatible or offsetting needs, but they cannot freely share proprietary strategies, portfolio positions, internal risk limits, or client-sensitive information.
Sending every order directly to an external venue can also create unnecessary market impact, fees, and operational complexity. For example, if one agent intends to buy 100 units while another intends to sell 80 compatible units, most of their exposure can be coordinated internally. Only the remaining 20 units need to reach an external execution venue.
CipherMesh was inspired by this gap between agent intelligence and safe financial execution:
How can autonomous financial agents coordinate compatible intentions while preserving human control, minimizing unnecessary external exposure, and disclosing only what each participant needs to know?
What CipherMesh Does
CipherMesh is privacy-aware, human-governed coordination and netting infrastructure for autonomous financial agents.
In the current prototype:
- Two agents representing independent principals generate compatible BUY and SELL intentions.
- Each intention receives a separate, resource-bound approval request.
- Only the designated approver for that principal can approve the intention.
- Approved intentions enter a shared coordination batch.
- The system calculates gross demand, the internally matched quantity, and the residual net exposure.
- Only the residual exposure produces a simulated external execution job.
- Approval, verification, matching, netting, execution, and audit events remain linked through a traceable lifecycle.
For gross BUY quantity (B) and gross SELL quantity (S), the simplified compatible match is:
[ M = \min(B,S) ]
The residual exposures are:
[ R_B = B-M,\qquad R_S = S-M ]
In our deterministic demo:
[ B=100,\qquad S=80,\qquad M=80 ]
Therefore:
[ R_B=20,\qquad R_S=0 ]
Instead of externally executing 180 units of gross intentions, the prototype internally matches 80 and generates one simulated BUY execution job for the remaining 20.
How We Built It
CipherMesh combines a Python agent runtime with a financial coordination and execution lifecycle.
The agent layer uses structured tasks, constrained tool access, risk capsules, typed artifacts, and human-in-the-loop approval. Research, quantitative analysis, and risk stages produce a structured transaction intention rather than allowing an agent to directly trigger execution.
Each approval is bound to specific resources and transaction attributes, including:
- Principal and designated approver
- Task and intent identifiers
- Asset and direction
- Exact quantity and price constraint
- Version and digest
- Expiration time
Before an intention can enter a shared batch, the backend revalidates its approval, digest, constraints, and proof receipt. Missing, rejected, expired, or modified intentions fail closed.
The netting layer uses authoritative decimal arithmetic to calculate:
- Gross BUY and SELL quantities
- Internally matched quantity
- Residual BUY and SELL exposure
- External execution quantity
The results are persisted alongside the batch, execution job, and audit events. Repeated or concurrent settlement requests are handled idempotently so that the same batch does not create duplicate execution jobs.
The judge-facing interface was built with React, Vite, and TypeScript. It includes:
- A Netting view for independent principals, approvals, gross intentions, internal matching, residual exposure, simulated execution, and audit events
- A Privacy & Disclosure view showing which fields are private, disclosed, committed, verified, audit-only, or not currently protected for each system participant
The backend and persistence layers use Python, API services, SQLite, and Alembic migrations. Automated validation covers authorization failures, expired approvals, digest tampering, proof expiration, accounting invariants, idempotency, API behavior, and frontend rendering.
Challenges We Faced
Binding human approval to the exact action
A generic “approve this task” button is not sufficient for a financial system. Approval must authorize one exact version of one exact intention. We therefore bound approvals to the principal, approver, task, intent, asset, side, quantity, price constraint, digest, version, and expiration time.
If an approved intention is later modified, the binding no longer matches and settlement is rejected.
Preserving financial correctness
Financial quantities cannot safely rely on ordinary binary floating-point calculations. The prototype therefore uses an authoritative decimal accounting layer and validates invariants such as:
[ B=M+R_B ]
[ S=M+R_S ]
It also cross-checks these results against the existing batch-auction output and rejects inconsistent accounting.
Preventing duplicate execution
Retries are normal in distributed and financial systems, but a retry must not create a second trade. We added deterministic identifiers, persistent batch state, idempotency checks, and tests for repeated and concurrent settlement requests.
Communicating privacy honestly
Privacy is not a single feature or a checkbox. It depends on who can see each field, at which stage, and under what conditions.
The current matching process is not private matching. The Stage 1 demo uses fixture proof receipts and a Mock Router with simulated funds. The project therefore includes an explicit disclosure matrix showing both the protections already implemented and the boundaries that remain future work.
InnovateX 2026 Development
CipherMesh builds on a pre-existing research and engineering foundation that included the agent protocol, dynamic runtime, proof-provider abstraction, batch-auction components, mock execution lifecycle, and evaluation framework.
During InnovateX 2026, the project was extended with meaningful new development:
- Two independent principals and designated approvers
- Resource-bound approval semantics
- A shared multi-agent coordination batch
- Authoritative decimal netting
- Residual-only simulated execution
- Netting and privacy-disclosure interfaces
- P0-specific security, accounting, and idempotency tests
- A deterministic, offline-reproducible demonstration
This separation is intentional: the submission does not represent the entire platform as having been created from scratch during the hackathon.
What We Learned
The most important lesson was that agent autonomy in finance is not only an intelligence problem. It is also an authorization, coordination, accounting, privacy, and audit problem.
We also learned that internal netting provides a clear bridge between multi-agent coordination and real financial value. The value is not simply that two agents can communicate; it is that compatible intentions can reduce the amount of exposure sent to external venues while preserving explicit human control.
Finally, building the disclosure matrix reinforced that privacy must be communicated as a lifecycle property. A system should state exactly which data is protected, committed, disclosed, or still visible instead of making a broad and unverifiable privacy claim.
Current Scope and Next Steps
The current prototype uses a Mock Router and simulated funds. Fixture proofs are not presented as real zero-knowledge proofs, matching is not currently private, and no real-money or on-chain asset settlement occurs.
The next development stages are:
- A chain-agnostic settlement adapter and safe local/testnet integration
- Private circuit inputs and circuit-level commitment binding
- Stronger cross-organization identity and resource-level RBAC
- Database-level or distributed coordination locks
- Expanded multi-agent batches and matching policies
- Production-oriented monitoring, recovery, and infrastructure controls
CipherMesh’s long-term goal is to become a verifiable coordination layer between autonomous financial agents and external execution venues—allowing agents to cooperate without surrendering human governance or unnecessarily exposing everything they know.
Log in or sign up for Devpost to join the conversation.