Introducing OpenZaps: Bounded Onchain Automation

DeFi is programmable, but using it still requires a surprising amount of manual operation.

Users monitor positions, claim rewards, rebalance liquidity, manage collateral, execute recurring swaps, and respond to changing market conditions. Each action may be straightforward on its own, but the work never really stops.

Agents offer an obvious solution: give software the ability to operate continuously on a user’s behalf.

But that creates a more important question:

How much authority should an agent have?

Giving an agent unrestricted wallet access is simple, but it is the wrong abstraction. A general-purpose agent is probabilistic. It consumes untrusted information, interacts with external tools, and makes decisions under uncertainty. Even a highly capable agent should not have the power to reinterpret a user’s intent or move assets wherever it chooses.

OpenZaps starts from a different premise:

Don’t give the agent a wallet. Give it a bounded capability.

Today, we’re introducing OpenZaps, a system for turning approved DeFi workflows into sealed, immutable policy capsules that a Hermes agent can simulate, submit, monitor, and revoke—without ever receiving discretionary authority over the wallet.

An OpenZap represents permission to perform a particular workflow under a particular set of constraints.

Instead of authorizing an agent to “manage my portfolio,” a user can authorize something closer to:

• Compound rewards back into the same vault.

• Rebalance a specific liquidity position within an approved range.

• Repay a bounded amount of debt if a health threshold is crossed.

• Execute a recurring allocation within a fixed budget and slippage limit.

The agent remains flexible in how it observes, reasons, schedules, and responds. But the space of transactions it can execute is fixed by the policy.

The distinction matters.

A model may decide when to invoke an action. It cannot redefine what it is authorized to do.

Conceptually, a policy capsule could constrain the assets, protocols, contracts, function calls, amounts, price impact, frequency, expiry, destinations, and market conditions associated with a workflow. Once the policy is sealed, the agent cannot quietly widen its permissions. A different policy requires a different capsule and a new user authorization.

The capsule is immutable. Its authority is revocable.

This creates a deterministic security boundary around a probabilistic operator.

Wallets were designed around individual transactions.

A wallet presents calldata, asks the user to approve it, signs it, and broadcasts it. That model works when a person is present for every action. It becomes cumbersome when software is expected to operate continuously.

Agents need a policy-centric authorization model.

A transaction says:

Perform this action now.

A policy says:

You may perform this class of actions, within these boundaries, until these conditions change or this permission is revoked.

Every transaction submitted by the agent is then an instance of an already-approved policy. The user approves the operating envelope rather than every individual operation.

That is the core abstraction behind OpenZaps.

Much of the conversation around agent security focuses on making agents more reliable: better models, better prompts, better monitoring, better tool selection.

Those improvements matter, but they cannot be the final security boundary for onchain assets.

The execution layer must assume that an agent will eventually make a bad decision, misunderstand some context, consume manipulated data, or interact with a malicious external system. The system should remain safe even when that happens.

OpenZaps approaches this through least authority.

An agent does not receive general custody and promise to behave. It receives the minimum capability required to perform an approved task. A failure may interrupt the workflow or produce an undesirable action within the permitted range, but it should not become unrestricted control over the wallet.

The security objective is therefore not:

Make the agent incapable of being wrong.

It is:

Make the consequences of being wrong legible, bounded, and revocable.

OpenZaps is designed to work with Hermes, the open-source agent developed by Nous Research.

Hermes provides the persistent operational layer: memory, reusable skills, scheduling, tool integrations, and the ability to run continuously rather than only during an interactive chat session.

That makes it well suited to tasks such as monitoring onchain conditions, simulating an approved workflow, submitting eligible actions, tracking their results, and reporting back to the user.

But Hermes is the operator, not the owner.

It can reason about the workflow and invoke the capabilities it has been given. It cannot expand those capabilities or acquire discretionary control over the rest of the wallet.

This separation between intelligence and authority is the important part.

The agent can become smarter over time. The permission boundary remains fixed.

Most DeFi automation today is implemented as a private bot, a proprietary interface, or a strategy-specific smart contract.

OpenZaps points toward a more open model: reusable, inspectable workflow capsules that can be created by developers, reviewed by users, simulated by agents, and enforced onchain.

A mature ecosystem could allow:

• Protocols to publish canonical automations for their products.

• Strategists to create specialized workflows without taking custody.

• Wallets to display permissions in a standardized, human-readable format.

• Auditors and monitoring systems to reason about the exact action surface.

• Agents to discover and invoke compatible workflows across applications.

Instead of every agent building bespoke integrations and asking for broad wallet permissions, it could operate through a shared library of narrowly scoped capabilities.

The result would be more than automation. It would be an open coordination layer between users, agents, wallets, and protocols.

OpenZaps launches alongside 0xZAPS, the token associated with the project.

The token was deployed through Clanker on July 21, 2026, with the contract address:

0xDd90bFa4adC7F4401E611AbaC692D939F9F4CB07

The initial announcement identifies 0xZAPS as the token for OpenZaps; its broader utility, governance, and incentive mechanics have not yet been detailed.

Onchain agents will not become useful simply because they gain broader permissions.

They will become useful when users can delegate meaningful work without surrendering control.

OpenZaps is an attempt to make that possible:

Humans define the policy.
Agents handle the operation.
Smart contracts enforce the boundary.

The future of onchain automation should not look like an agent holding your private key and promising to follow instructions.

It should look like an open network of auditable capabilities that agents can invoke—and nothing more.

That is the idea behind OpenZaps.

Bounded onchain automation, with a token to match.

Token contract: 0xDd90bFa4adC7F4401E611AbaC692D939F9F4CB07

Clanker: https://www.clanker.world/clanker/0xDd90bFa4adC7F4401E611AbaC692D939F9F4CB07