Latch

Give agents money, not your wallet. Latch is a private spending gate for AI agents, built with zero-knowledge proofs on Midnight.

Comment

Inspiration

AI agents increasingly need to purchase datasets, renew infrastructure, pay for security services, and interact with DeFi while their owners are offline.

Giving an agent unrestricted wallet access is dangerous. A compromised workflow, prompt-injection attack, or faulty decision could become an unlimited financial liability. Publishing every spending rule on-chain is not ideal either because budgets, categories, and limits may reveal sensitive operational information.

Latch is built around one principle: every payment must pass a private gate.

Instead of giving an agent control of an entire wallet, the owner delegates a narrow, revocable spending capability. A payment must satisfy its private rules before it can be authorized.

What it does

Latch demonstrates privacy-preserving delegated payments using a Compact smart contract deployed on Midnight Preprod.

The submission has two clearly separated parts:

  1. A live Compact contract deployment completed through a connected Lace wallet
  2. An interactive policy simulator that mirrors the contract’s authorization rules

Local simulation · Contract-equivalent logic

Simulator actions are not live on-chain transactions. They provide an instant, transparent way to explore the same capability rules implemented by the deployed contract.

Each capability can define:

  • Total spending budget
  • Per-payment limit
  • Allowed spending category
  • Maximum number of uses
  • Revocation status
  • Replay protection

The simulator demonstrates the full policy lifecycle:

  1. Capability creation → createCapability
    The owner creates a constrained spending policy.

  2. Valid request → authorizeSpend approval
    CodeShield requests payment for a security report and satisfies the policy.

  3. Invalid request → authorizeSpend rejection
    AlphaSignal requests payment for a trading dataset that exceeds the policy. The Owner sees a useful private explanation, while the Public Observer receives only a generic rejection.

  4. Replay attempt → authorizeSpend rejection
    Reusing an approved request is blocked through nullifier-based replay protection.

  5. Revocation → revokeCapability
    The owner revokes the capability. The simulator disables additional requests, reflecting the contract’s revoked-state enforcement.

Latch also provides two separate views:

  • Owner View: shows private policy and management information
  • Public Observer View: shows only commitments, status, and restricted receipts

The Public Observer is generated from a dedicated allowlisted data model. Private limits, spending rules, and rejection reasons are never passed into that interface.

Live Preprod deployment

The MOAT Compact contract is deployed on Midnight Preprod.

  • Network: Midnight Preprod
  • Status: Contract deployed
  • Wallet: Lace
  • Contract address:
    3f45a282f188b82e5e8b029825a9057e2f3a295cd48b015eff73949eff8d8a25
  • Transaction ID:
    002d6d4d1f5f3965db970e14071947b895ca5a4aed76f5a0e5c8ba29384e333d64

This proves that the Compact contract is live. It does not imply that simulator actions are Preprod transactions.

How we built it

The frontend uses TypeScript, React, and Vite, structured around a typed MoatClient abstraction that separates the interface from blockchain-specific code.

The Compact contract implements three private circuits:

  • createCapability
  • authorizeSpend
  • revokeCapability

Together, they model:

  • Agent authorization
  • Per-payment limits
  • Total-budget enforcement
  • Category restrictions
  • Maximum-use limits
  • Revocation
  • Nullifier-based replay protection

Commitments are domain-separated using namespaces including:

  • MOAT_OWNER_V1
  • MOAT_POLICY_V1
  • MOAT_CAPABILITY_ID_V1

Wallet connectivity uses the Midnight DApp Connector and Lace. The application safely handles duplicate providers, delayed authorization, stale sessions, network changes, and recoverable wallet errors.

Privacy is enforced throughout the data flow. Wallet addresses, balances, seeds, private state, witnesses, raw transactions, and provider payloads are never exposed through interface diagnostics.

Challenges we ran into

Our biggest challenge was demonstrating real privacy without overstating the implementation.

Privacy required more than hiding interface elements. We built separate Owner and Observer data models, sanitized copied and exported information, and added automated tests to detect private-data leakage.

Integrating Lace also required handling real browser-wallet behavior, including duplicate provider aliases, delayed authorization, network changes, correct method binding, and Connector API 4.0.1 transaction responses.

Finally, we kept the integration boundary honest. The contract deployment and Lace connection are real, while the public capability walkthrough is clearly labeled as a local, contract-equivalent simulator.

Accomplishments that we're proud of

Latch includes:

  • A Compact contract deployed on Midnight Preprod
  • Three compiled private circuits
  • Real Lace wallet connectivity
  • Private policy commitments
  • Replay protection and revocation
  • Separate Owner and Public Observer data models
  • Privacy-safe diagnostics and clipboard handling
  • A complete interactive policy simulator
  • Automated privacy, wallet, contract, and interface tests

Latch never fabricates transaction hashes, treats wallet connectivity as proof of a capability transaction, or silently replaces a failed blockchain operation with simulated success.

Every result clearly distinguishes between the live Preprod deployment and the local policy simulator.

What we learned

Privacy-preserving payments require two kinds of correctness:

  • Transaction correctness: only valid requests should be authorized
  • Disclosure correctness: interfaces, receipts, logs, and errors must reveal no more than intended

We also learned that useful AI autonomy does not require unrestricted financial authority. Narrow, revocable capabilities offer a safer foundation than giving agents direct access to permanently funded wallets.

What's next

Our immediate next step is connecting the public application’s complete createCapability, authorizeSpend, and revokeCapability workflow to the deployed Preprod contract.

Future plans include:

  • Multiple capabilities per Owner
  • Expiration and renewal policies
  • Recurring payment capabilities
  • Persistent encrypted private state
  • Better audit exports
  • A separately deployed Public Observer
  • SDK support for autonomous-agent frameworks

Latch can ultimately become a private authorization layer for autonomous finance letting AI agents pay for services without giving them unrestricted control of an owner’s wallet.

Built With

Share this project:

Updates