Introducing the Safe Policy Engine

Discover the Safe Policy Engine, bringing onchain policy enforcement, spending limits, and transaction controls to Safe accounts. Apply to be a design partner.

Dev Pramoth, Safe Labs • 27 October 2026

The Policy Engine lets teams write rules into their Safe accounts and have a smart contract enforce them on every transaction. A co-signer covers rules the chain cannot read. The policy engine will launch in Q4, 2026. Design partners can help shape it now.

Most treasury teams already have rules. A payroll account might pay a fixed set of recipients; a grants committee can release funds up to a certain limit; no signer may be added without notice. Today those rules live in a policy document, and people enforce them by remembering to follow them.

A multisig enforces who can approve. It does not enforce what they can approve. Any transaction that collects enough signatures executes, whether or not it matches the written policy.

Today, we're introducing the Safe Policy Engine. It lets a team write its rules directly into its Safe account, where a smart contract checks every transaction against them before execution. The team keeps control of its accounts. The rules hold without anyone remembering them, and without Safe Labs in the path.

Rules your Safe enforces onchain

The Policy Engine is a set of open-source contracts that attach to a Safe account through the Safe Transaction Guard. Once installed, the guard checks every transaction against the policies the team has set. A transaction that meets policy executes as usual. A transaction that does not meet policy cannot execute, however many signers approve it.

Policies live onchain, in a contract the team owns. Anyone can read them. Nothing offchain creates, stores, or evaluates them. Safe Labs cannot change them, and they keep enforcing if Safe Labs is unavailable.

Policies do not answer to the Safe's own threshold. Removing or loosening a policy waits out a time delay. Otherwise an attacker who tricks the signers into one transaction removes the policy first and drains the account second.

Teams set policies through guided templates. No condition trees and no custom code.

Policies available at launch

Recipient allowlist. Transfers of a tokens go only to approved addresses.
Spending limits. A designated address spends up to a set amount of a token per period, without a full signer threshold.
App allowlist. Contract calls go only to approved contracts and functions.
Authority-change protection. Adding a signer, lowering the threshold, enabling a module, or removing a policy waits out a time delay, requires a co-signer, or both.
Co-signer requirement. Any transaction the policies above do not cover needs a designated co-signer's signature.

Each policy is a separate contract. Each is audited on its own. A team installs only the policies it needs.

Co-signers for rules the chain cannot read

Some rules need information the chain does not have. A rolling limit of $250,000 per week needs transaction history and a price. A signing window of weekdays, 9am to 6pm CET, needs a clock in the team's time zone. Counterparty screening needs a list that changes daily. A guard sees one transaction and nothing else.

The Policy Engine handles these rules through a co-signer. One onchain policy states that any transaction the other policies do not cover needs a co-signer's signature. The co-signer evaluates the transaction offchain against the rules the team wrote, then signs or refuses. Proposers and signers see the result before anyone signs, so a transaction that would be refused never reaches a signing round.

Rules a co-signer can enforce include:

Value caps and rolling limits in fiat terms
Signer requirements, such as one hardware signer and one finance signer per transaction
Signing windows and cool-off periods for first payments to a new recipient
Counterparty screening against a list the team maintains
Simulation checks that refuse a transaction that would revert or lose more than expected

The co-signer is a role, not a service a team must take from Safe. It can be a service run by Safe Labs, a third-party transaction security provider, or a signer the team controls. Rules change without an onchain transaction and apply across every Safe account in a Workspace.

The onchain policies stay the floor. Setup requires at least one, so transactions those policies permit keep executing if the co-signer is down. A compromised co-signer cannot move funds the onchain policies do not allow.

What the Policy Engine gives teams

Written policy becomes enforced policy. Rules the team already has move from a document into the account. A transaction that breaks them cannot execute, so the policy no longer depends on every signer checking it.

Routine work moves without a full signer round. Payroll, grants, and recurring payments run within set limits. Signers keep every decision outside those limits.

Changes to account control become slow and visible. Adding a signer, lowering the threshold, or removing a policy waits out a delay or needs a co-signer. The actions that could take over an account are the hardest ones to perform.

Every control is auditable. Policies are contracts anyone can read. An auditor verifies the rules on the chain, not in a vendor's dashboard.

No new custodian. Safe Labs does not hold your keys, does not evaluate onchain policies, and does not sit between a team and its account. The security model is unchanged.

Rules checked onchain, not on someone else's server

Custody platforms check policy on their own servers, then co-sign the transaction. If that platform is offline, compromised, or changes the rule, the policy stops holding. Many teams chose Safe to avoid that dependence.

The Policy Engine puts the check in a contract the team owns. The question to ask any policy layer is who else has to be online for the policy to hold. For onchain policies, nobody else needs to be online.

The difference shows in the largest institutional losses of the past two years. In each, signers approved one transaction and a different one executed. A policy checked before signing validates an intent. A policy checked at execution validates the transaction that runs. Only the second blocks that attack.

	Policy on a vendor's servers	Safe Policy Engine
Where the rule is checked	Vendor infrastructure, before co-signing	A contract in the Safe account, at execution
Who must be online	The vendor	Nobody
Who can change the rule	The vendor's operators and the customer	A separate signer set or higher threshold, after a time delay
Who can verify the rule	The customer, in the vendor's dashboard	Anyone, onchain
Blocks a transaction that differs from what signers approved	No	Yes
Rules needing price, history, or time	Yes	Yes, through a co-signer

Help shape the Policy Engine before launch

The Policy Engine contracts are audited by two independent security firms. Policy Engine will be available to teams on Safe Pro Business and Enterprise plans by the end of Q4, 2026, starting with the above policies.

Before release, we are opening a Policy Engine Design Partner Program. Design partners test the engine with their Safe accounts on testnet, work directly with the Safe product team, and decide which policy templates ship first.

We want to hear from teams with rules they enforce by hand today. The questions we are working through:

Which rules does your team follow that your Safe does not enforce?
Where does a transaction get approved that your policy says it should not?
Which rules need a co-signer, and who should run it?
What would an auditor need to see?

If your team has a policy requirement, in the list above or not, tell us. The first templates follow what design partners ask for.

Apply to become a Policy Engine Design Partner. For tailored requirements, contact the Safe team.

Policy Engine and Safe Pro

Safe Pro gives teams one Workspace across their Safe accounts, and access to priority support from the Safe team. Business and Enterprise plans add Proposers and spending limits. The Policy Engine extends that control set. Policies are set from the Workspace and enforced onchain, per Safe account.

Safenet is also included in Safe Pro. Safenet checks Safe transactions against a shared security charter before they execute. Independent security firms assess each transaction, and a decentralized validator network attests to the result onchain.

Safe{Wallet} remains free. An account's signers, threshold configuration, and signing rights do not depend on a subscription. Policies set on a Safe account continue to be enforced whether or not the subscription continues. A team that uses the Safe Labs co-signer can switch to a co-signer it controls, or remove the co-signer requirement, without a subscription. Both changes wait out the same time delay as any other policy change.

Your keys. Your rules. Safe enforces them.