I've been building in the smart account and account abstraction space for a while now, and one problem keeps coming up: how do you enforce rules on what a wallet can do without taking away the owner's control?

Think about it. DAOs hold millions in treasuries with minimal guardrails. AI agents are starting to operate wallets autonomously. And ERC-4337 smart accounts are getting more powerful every day. But the tooling to actually constrain what these wallets can do? It's either too rigid, too centralized, or just doesn't exist.

That's why I built PolicyKit — a policies-as-code SDK that lets you define composable, enforceable transaction policies with both on-chain and off-chain evaluation.

The Problem

Let's say you're running a DAO and you want to enforce that:

• The treasury can only interact with approved DeFi protocols

• No single execution can move more than 10 ETH

• There's a weekly spending cap of 50,000 USDC

• There's a cooldown between executions

Or you're building an AI agent that trades on Uniswap, and you need to make sure it can't drain the wallet, can't call approve() on random contracts, and can't execute trades with more than 50 basis points of slippage.

Today, you'd either build all of this from scratch, trust a centralized service to enforce it, or just... hope for the best. None of those are great options.

How PolicyKit Works

PolicyKit introduces a three-tier rule system:

Tier 1 — Stateless On-Chain Rules. These are instant and fully trustless. Allow/deny specific target addresses, allow/deny specific function selectors, set max ETH value per transaction. Pure smart contract logic, no external dependencies.

Tier 2 — Stateful On-Chain Rules. Also on-chain and trustless, but they track state. Spending limits over time windows, cooldowns between transactions. The contract keeps track of everything.

Tier 3 — Off-Chain Rules. This is where it gets interesting, and where Lit Protocol comes in.

Some rules just can't be evaluated on-chain efficiently. Checking swap slippage requires decoding DEX calldata and comparing against market prices. Simulating a transaction before execution requires an eth_call. Running custom governance logic might need external data. These are all things that need off-chain computation — but you don't want to trust a centralized server for it.

PolicyKit uses Lit Actions running on Lit Protocol's decentralized TEE network to evaluate Tier 3 rules. When a transaction needs off-chain evaluation, a Lit Action fetches the policy from IPFS, runs all the checks, and if everything passes, a Lit PKP threshold-signs an EIP-712 attestation. The smart contract then verifies that signature on-chain before allowing the transaction to proceed.

No centralized server. No single point of failure. Just decentralized, verifiable policy enforcement.

What It Looks Like in Code

Building a policy feels natural:

import { PolicyBuilder } from "@policykit/sdk";

const policy = new PolicyBuilder("agent-guardrails")
    .allowTargets([UNISWAP_ROUTER])
    .denySelectors(["approve(address,uint256)"])
    .maxValue(parseEther("0.1"))
    .spendLimit(USDC_ADDRESS, 1000n * 10n ** 6n, 86400) // 1000 USDC/day .cooldown(60) // 1 min between txs .requireSimulation() .failMode("CLOSED") .build();

That's a full policy for an AI agent wallet: only Uniswap, no approvals, max 0.1 ETH per tx, 1000 USDC daily limit, cooldown, and mandatory transaction simulation. If the Lit network is unreachable, fail closed — block everything. Safety first.

Deploy it with one call:

await policyKit.deployPolicy(policy);

The SDK pins the policy to IPFS, registers it on-chain, and you're done. The policy is now enforced for every transaction on that account.

Why Lit Protocol Was the Right Choice

I evaluated several approaches for off-chain rule evaluation, and Lit Protocol stood out for a few reasons:

1. Decentralized execution. Lit Actions run across a distributed network of TEE nodes, not on a single server I control. This matters when you're building security infrastructure.

2. Threshold signatures. Lit PKPs give us threshold-signed attestations. No single node can forge an approval — you need consensus across the network.

3. Programmability. Lit Actions are just JavaScript. I could implement slippage checks, transaction simulation, custom governance logic — anything that can be expressed in code.

4. Encryption. PolicyKit supports encrypted policies stored on IPFS. Lit's access control lets us decrypt policy logic only within the Lit Action execution environment. This means sensitive policy details — like specific thresholds or approved addresses — can stay private.

The combination of on-chain trustlessness for simple rules and Lit-powered decentralized evaluation for complex rules gives PolicyKit a security model I'm genuinely comfortable with.

Use Cases

DAO Treasuries. Define spending limits, approved protocols, cooldowns, and governance checks. Fail-open mode ensures the DAO is never locked out of its own funds.

AI Agent Wallets. As agents become more autonomous, the guardrails need to be just as robust. PolicyKit gives you fine-grained control over what an agent can and can't do, with fail-closed mode for maximum safety.

ERC-7579 Smart Accounts. PolicyKit ships as an ERC-7579 module, so it plugs directly into the smart account ecosystem. If your account supports 7579 modules, you can add PolicyKit.

What's Next

PolicyKit is open source and I'm actively building it. The contracts are written in Solidity with Foundry, the SDK is TypeScript, and the whole thing runs as a Turbo monorepo.

I'd love to get feedback from the Lit community on the Tier 3 evaluation model, and from the smart account community on the ERC-7579 integration. If you're building with AI agents, DAOs, or smart accounts and want programmable guardrails, give PolicyKit a look.

Check out the repo, try the examples, and let me know what you think.

— Rodrigo Serviuc Pavezi

I've been building in the smart account and account abstraction space for a while now, and one problem keeps coming up: how do you enforce rules on what a wallet can do without taking away the owner's control?

Think about it. DAOs hold millions in treasuries with minimal guardrails. AI agents are starting to operate wallets autonomously. And ERC-4337 smart accounts are getting more powerful every day. But the tooling to actually constrain what these wallets can do? It's either too rigid, too centralized, or just doesn't exist.

That's why I built PolicyKit — a policies-as-code SDK that lets you define composable, enforceable transaction policies with both on-chain and off-chain evaluation.

The Problem

Let's say you're running a DAO and you want to enforce that:

• The treasury can only interact with approved DeFi protocols

• No single execution can move more than 10 ETH

• There's a weekly spending cap of 50,000 USDC

• There's a cooldown between executions

Or you're building an AI agent that trades on Uniswap, and you need to make sure it can't drain the wallet, can't call approve() on random contracts, and can't execute trades with more than 50 basis points of slippage.

Today, you'd either build all of this from scratch, trust a centralized service to enforce it, or just... hope for the best. None of those are great options.

How PolicyKit Works

PolicyKit introduces a three-tier rule system:

Tier 1 — Stateless On-Chain Rules. These are instant and fully trustless. Allow/deny specific target addresses, allow/deny specific function selectors, set max ETH value per transaction. Pure smart contract logic, no external dependencies.

Tier 2 — Stateful On-Chain Rules. Also on-chain and trustless, but they track state. Spending limits over time windows, cooldowns between transactions. The contract keeps track of everything.

Tier 3 — Off-Chain Rules. This is where it gets interesting, and where Lit Protocol comes in.

Some rules just can't be evaluated on-chain efficiently. Checking swap slippage requires decoding DEX calldata and comparing against market prices. Simulating a transaction before execution requires an eth_call. Running custom governance logic might need external data. These are all things that need off-chain computation — but you don't want to trust a centralized server for it.

PolicyKit uses Lit Actions running on Lit Protocol's decentralized TEE network to evaluate Tier 3 rules. When a transaction needs off-chain evaluation, a Lit Action fetches the policy from IPFS, runs all the checks, and if everything passes, a Lit PKP threshold-signs an EIP-712 attestation. The smart contract then verifies that signature on-chain before allowing the transaction to proceed.

No centralized server. No single point of failure. Just decentralized, verifiable policy enforcement.

What It Looks Like in Code

Building a policy feels natural:

import { PolicyBuilder } from "@policykit/sdk";

const policy = new PolicyBuilder("agent-guardrails")
    .allowTargets([UNISWAP_ROUTER])
    .denySelectors(["approve(address,uint256)"])
    .maxValue(parseEther("0.1"))
    .spendLimit(USDC_ADDRESS, 1000n * 10n ** 6n, 86400) // 1000 USDC/day .cooldown(60) // 1 min between txs .requireSimulation() .failMode("CLOSED") .build();

That's a full policy for an AI agent wallet: only Uniswap, no approvals, max 0.1 ETH per tx, 1000 USDC daily limit, cooldown, and mandatory transaction simulation. If the Lit network is unreachable, fail closed — block everything. Safety first.

Deploy it with one call:

await policyKit.deployPolicy(policy);

The SDK pins the policy to IPFS, registers it on-chain, and you're done. The policy is now enforced for every transaction on that account.

Why Lit Protocol Was the Right Choice

I evaluated several approaches for off-chain rule evaluation, and Lit Protocol stood out for a few reasons:

1. Decentralized execution. Lit Actions run across a distributed network of TEE nodes, not on a single server I control. This matters when you're building security infrastructure.

2. Threshold signatures. Lit PKPs give us threshold-signed attestations. No single node can forge an approval — you need consensus across the network.

3. Programmability. Lit Actions are just JavaScript. I could implement slippage checks, transaction simulation, custom governance logic — anything that can be expressed in code.

4. Encryption. PolicyKit supports encrypted policies stored on IPFS. Lit's access control lets us decrypt policy logic only within the Lit Action execution environment. This means sensitive policy details — like specific thresholds or approved addresses — can stay private.

The combination of on-chain trustlessness for simple rules and Lit-powered decentralized evaluation for complex rules gives PolicyKit a security model I'm genuinely comfortable with.

Use Cases

DAO Treasuries. Define spending limits, approved protocols, cooldowns, and governance checks. Fail-open mode ensures the DAO is never locked out of its own funds.

AI Agent Wallets. As agents become more autonomous, the guardrails need to be just as robust. PolicyKit gives you fine-grained control over what an agent can and can't do, with fail-closed mode for maximum safety.

ERC-7579 Smart Accounts. PolicyKit ships as an ERC-7579 module, so it plugs directly into the smart account ecosystem. If your account supports 7579 modules, you can add PolicyKit.

What's Next

PolicyKit is open source and I'm actively building it. The contracts are written in Solidity with Foundry, the SDK is TypeScript, and the whole thing runs as a Turbo monorepo.

I'd love to get feedback from the Lit community on the Tier 3 evaluation model, and from the smart account community on the ERC-7579 integration. If you're building with AI agents, DAOs, or smart accounts and want programmable guardrails, give PolicyKit a look.

Check out the repo, try the examples, and let me know what you think.

— Rodrigo Serviuc Pavezi