ERC-8006: Universal Policy Engine (programmable compliance)

ERCs
, , , ,
1

ERC-8006

DApps keep reimplementing ad hoc validation and compliance rules (roles, KYC, allowlists, limits, workflows, and other legally required validations). This approach is brittle to upgrade, hard to audit, and not reusable across projects. This ERC enables Programmable Compliance by standardizing a Policy Engine

  1. Each rule is packaged in small contract called artifact
  2. Each artifact contract can be reused by other policies and has to expose minimal interface (init, exec) and self-descriptors
  3. A Policy Handler (the recommended approach) bundles and orchestrates policy artifacts as a Directed Acyclic Graph (DAG), allowing applications to compose complex policies from simple building blocks and update them incrementally by swapping or appending artifacts instead of redeploying application logic
  4. All parameters flow as bytes for uniform on/off-chain integration; variables can be introspected for tooling.

It’s universal by design – applicable across data domains and attachable to any contract as method-level hooks (pre/post) to gate calls and chain validations. Reference implementation in ERC assets.

General and simplified yet precise view of how it works

simple_policy_bird_eye_view 2
simple_policy_bird_eye_view 21920×3223 238 KB

ERC Authors list:
@Vlad, @Vitali

18 Likes
New EIP: A Standard for Composable Token Policies (RWAs, Gaming & More)
2

An excellent story for gamification processes. You can build custom complex systems resembling MPORG, conditionally WoW. Artifacts can be ers721/1155, and their improvements are coordinated by high-level policies (for example, physics from Oracle). I like your approach. Thank you.

Sorry for my English, translated from Russian.

1 Like
3

The mechanic looks particularly interesting for social DAOs, where actors/delegates/conditional guilds or factions can be endowed with a life cycle through artifacts and, for example, have “research trees.” But for such a system, a certain general primitive of Web3 generation experience must be built up, accessible to all interested parties. It is only necessary to take into account sibyl scams (for example, using a quadratic approach when improving levels), BUT then all these Leyer3, Galaxies, and other systems can be brought to conditional common denominators through policies.

1 Like
4

Hey, thanks for your interest!

  1. Yep, improvements/role escalations (or any other action) can be constrained by policies
  2. The artifacts themselves though are not originally intended to be tokens, cause the “fungibleness” is not the same here as “interoperability” and “reusability” in this case. It is rather a reverse story, policy and its artifacts can constrain erc20, erc721’s transfer method (or other hook, whatever)
  3. So, artifacts can be reused, and they not obligatory should be token-like (while technically it’s possible). The only obligation for artfact is to implement IArbitraryDataArtifact interface
2 Likes
5

Hey! I think there’s a small misunderstanding — ‘artifacts’ here aren’t ‘game artifacts.’
The term ‘artifact’ is used in the sense of ‘a unit intended for a specific function,’ not as ‘a unique collectible item.’ These are just functional components — like addition, subtraction, price queries, etc. So they don’t have much in common with NFTs or other game-fi artifacts.
Regarding DAO policies — while they’re not typically used to store data, I do get your point about what you were aiming to achieve with them!
You can absolutely design a policy system that evaluates a participant’s current level using some standardized inputs. Of course, the evaluation strategy can be arbitrary — say, a quadratic model. In that case, the policy effectively becomes an authorization guard.

2 Likes
9

Great observation — and excellent work on ERC-8006.

The Newton Protocol is tackling a very similar challenge, but from a complementary angle. In Newton, policy evaluation occurs off-chain through a decentralized network of Newton Operators, each capable of verifying rules against verifiable data sources (via MPC, TEE, and ZK-based proofs). The result of each policy evaluation produces an on-chain Proof-of-Compliance, emitted as a verifiable by-product of the network’s consensus process.

This architecture aims to make compliance and rule enforcement composable, verifiable, and chain-agnostic — allowing developers to plug in any policy engine or attach proofs directly to transactions or intents.

I’d love to hear your thoughts on potential alignment between ERC-8006 and Newton’s approach, and explore whether our initiatives could converge or interoperate. It seems like there’s strong synergy between ERC-8006’s on-chain modularity and Newton’s off-chain verifiability layer.

Looking forward to continuing the conversation.

3 Likes
10

Hi Dennis, and thank you!

I’m gonna deep dive into the litepaper – the on-chain policy engine is a rare thing, and I think we and any other policy builder should learn from each other and discuss this topic endlessly, especially if it’s open source.

When it comes to privacy (or on-chain verification), any logic that can run as a smart contract can also be packaged as a policy artifact – a reusable building block that you can use as policy lego.

For example, a policy artifact could use verifiable credentials based on the same standards as Privado ID.

That makes it easy to support KYC policy check, as well as any other scenario where a verifiable identity can be represented as one of the policy rules.

@denniswon Do you have any specific questions about the standard?

1 Like
11

If you have could you share your estimates of how using ERC-8006 affects the gasUsed of a typical transaction compared to an equivalent inline implementation of the same checks using regular require statements/modifiers?
For GameFi (or MMO RPG mentioned above) or high-frequency trading scenarios on DEXes, even a small increase in gasUsed per operation (on the order of a few thousand gas) can significantly impact unit economics/revenue, especially for dApps on L1.

Am I correct in understanding that, in exchange for reducing complexity and risks when updating compliance logic (by outsourcing it to a universal Policy Handler and artifacts), we effectively shift additional gasUsed overhead onto each user transaction?

Do you have any benchmarks or profiling results for the reference implementation (for example, for policies with 3 to 5 artifacts in the DAG) that you could share? And do you consider this overhead acceptable for high-throughput scenarios?

2 Likes
12

Hi @vitali_grabovski,

I reviewed ERC-8006.

I like the structure and flexibility this standard provides for sets of compliance rules.

I was enlightened by your All-Bytes approach in IArbitraryDataArtifact. I really like the flexibility that provides.

I had the thought that perhaps an function artifactURI() external pure returns (string memory desc); function could be useful in IArbitraryDataArtifact.

This function could return a URI, such as a URL to additional information and documentation about an artifact. This is in case the description is not enough. If the description is already enough then artifactURI() could just return an empty string. But I am not familiar enough with artifacts in reality to know if a artifactURI() function would be useful enough to add.

2 Likes
13

Hello,

Thank you for this proposal! I find the concept of an interface for a policy engine really cool and useful.

I am just wondering if it could be relevant to split the interface in two different ERC.

a) One to represent the required entrypoint in the target smart contract
b) One to represent the policy engine

For a), I will be more favorable to just define a way to send the context to the policy engine, in a similar way that what Chainlink does for their ACE smart contract. See chainlink-ace/packages/policy-management/src/core/PolicyProtected.sol at e0babf820a1fcac13e446c99d650f3e3400c2df8 · smartcontractkit/chainlink-ace · GitHub

2 Likes
14

Hi @denniswon

I’ve been thinking about a lighter, off-chain layer that runs before a transaction is even formed - an agent checks its own intent against a policy locally, before anything touches a contract. Different from 8006 (on-chain gating) and Newton (decentralized operator network) in that it’s meant to be cheap and client-side, not verified infrastructure.
Does something like that already exist, or would it be redundant with what’s here?

1 Like
15

@Anandi Something like that exists in spirit, and the distinction worth naming is the one that decides whether it actually closes the loop: a lightweight, pre-transaction, off-chain check is the right shape (cheap, client-side, before anything touches a contract) — but if the same agent is checking its own intent, it shares the exact blind spots and training-data priors that produced the intent in the first place. A different party (or at minimum a different model) doing the check is what catches what the acting agent structurally can’t see about itself.

We run this as a pre-action verdict layer (/review) that’s independent of the acting agent by construction — issued, signed, and published before the action, so it’s checkable after the fact too, not just a local pass/fail the agent could silently skip or misreport. Cheap and client-side is achievable either way; independence is the harder property to get right, and it’s the one that actually separates this from the agent auditing itself.

16

Actually, ERC-8006 essentially wraps everything we’ve been building over the last few years while creating on-chain policies for various business use cases. Regarding your idea, we already have something similar implemented in a much simpler way.

But could you explain why someone would need a dedicated offchain-check step if the final result is still verified by the smart contracts? Is it about who or what (persone or entity) makes this offchain check?

17

Thanks for sharing your thoughts. It seems very interesting to dig into.
Can you share how this is built?

Can you give an example of what the action is, and whether the action is attached/protected with policy too?

18

Good question on both fronts.

On why offchain if the contract verifies the result anyway: verification and judgment are different questions. A policy engine (8006 included) checks whether an action satisfies stated rules – permission, allowlist, threshold. It can’t check whether the rules themselves were the right call for this context, because that judgment happens upstream of any on-chain check. An agent can satisfy every policy artifact perfectly and still be acting on a bad read of the situation. The offchain layer is a second, independent party forming a verdict on the action before it’s attempted, published and signed so it’s checkable after the fact too – not a replacement for policy enforcement, a layer above it.

How it’s built, at the level that matters: an agent calls a review endpoint with the proposed action, gets back a signed verdict (approve/deny/concerns + confidence), and that verdict is published to a public ledger before the outcome settles – so it’s checkable independently later, not just trusted in the moment.

Example action: an agent about to execute an on-chain trade, or spend from a budget – the verdict gates before the transaction is even formed, same shape Anandi described. It composes with a policy engine rather than replacing it: policy can still gate the transaction on-chain, our layer sits upstream, forming the “should this be attempted at all” call.

Curious how 8006 policies handle it when the input to a rule is the actual problem – e.g. an artifact correctly enforces “spend under $X” but the $X itself, or the context that produced the spend decision, was wrong. Does an artifact ever check upstream data quality, or is that explicitly out of scope for the policy layer?

19

I think both approaches have their own place: off-chain-only is faster and cheaper for lower-stakes actions, while having the contract do final on-chain verification matters more as stakes go up.

1 Like
20

@Anandi

I’m curious which use cases actually require this off-chain step if there is already a mandatory on-chain step that enforces the policy right before the rest of the on-chain action (method) are executed.
What do you have in mind? For example, is it a case where an agent is manipulated into sending 3 USDT to destination B, and because destination B is whitelisted, the policy enforcement passes successfully? In that scenario, there is nothing wrong from the destination policy perspective, but the agent wallet/smart account could still end up being drained. just want to double-check that I understand your point correctly.

My other consideration is about the offchain policy layer if only offchain layer exists. Because in that case if policy is not declared onchain, then where should those rules reside, and in what format?Backend database? Client app? Declared using existing Web2 policy DSL + Rules Engine?

It is possible and even preferable if agent does not require to operate onchain.

Many web2 policy engines and DSLs are there for decades. Especially in traditional finance.

This ERC was inspired by some of them as well.

Based on all of the above, if the final step requires an on-chain interaction, meaning that a smart contract must be invoked, the approach would be to execute the smart contract action (method) in dry-run mode.

There are two approaches we have used to solve similar cases:

1. Prepare the full transaction data and invoke the contract `write` method using `call` mode. If any policy enforcement check fails, the corresponding error will be returned

2. instead of preparing the full transaction, prepare only the policy-specific parameters and call a dedicated public `dryRunCheck` method exposed by the same policy engine that is configured and attached to the target contract and method selector

Both approaches are gas-free and return the policy check result, including an error that helps identify why the enforcement failed.

This should cover many use cases. Not every possible one. But many.

21

Right now, in the version I’ve built, they’re just a JSON file (a policy.json) sitting in the agent’s own execution environment, validated against a published JSON Schema so the shape is at least portable - anyone could implement a different policy engine that reads the same schema, even in a different language, without needing to read my code. So today it’s closest to your “client app” option, not a backend service or an on-chain contract.
That said, I don’t think the schema mandates where it has to live - the same rule object could just as easily be pulled from a backend rules engine, or even published to something like IPFS for auditability, as long as whatever’s checking it emits the same structured verdict. I haven’t built those versions, just the simplest one so far.
On your example - agent gets manipulated into sending to a destination that’s already allow-listed, so the check passes correctly by its own rule but the wallet still gets drained: yeah, that’s exactly the harder case. A policy check, wherever it lives, is only checking the stated intent against a rule. it can’t tell whether the intent itself was already corrupted before the check ran. Your dry-run/call-mode approach solves the speed problem cleanly (didn’t realize that was already gas-free), but I don’t think it or my off-chain version, solves that deeper case either. Still working through whether that needs a different kind of check entirely (maybe something closer to anomaly detection on the intent itself, not just rule-matching against it) or if it’s a separate problem from what a policy engine should even be responsible for.

22

That gap you’re still working through, Anandi – “checking the intent itself, not just rule-matching against it” – is exactly the layer we build, and worth naming: it’s a genuinely different mechanism from anomaly detection, not a variant of it. Anomaly detection flags something that looks unusual against a baseline. A pre-action verdict is a second party – independent of the agent, independent of the policy engine – forming a judgment on whether this specific action is sound given the actual context, signed and published before the outcome settles so it’s checkable after the fact too, not just trusted in the moment.

In Vitali’s example: the destination is allow-listed, so the policy check passes correctly – but “does sending here, now, for this stated reason, make sense” is a context question no rule set can encode in advance, no matter how it’s structured. That’s the layer above policy enforcement, not a stricter version of it.

Concretely: would a structured verdict (approve/deny/concerns + confidence, signed) sitting alongside your policy.json’s pass/fail be worth prototyping? Your schema already proves the pattern you want – portable, engine-agnostic, verdict-shaped – composing a judgment layer on top wouldn’t touch your policy engine at all, just a second check before execution consumes the result.

23

Hi @AccessDenied403 , thank you for those questions!

This ERC is mostly about artifact interfaces and how artifacts can be combined into a graph of nodes. The graph is mentioned in the ERC as the recommended approach and is not covered much.

That is why I also have some thoughts about describing the Policy Handler interface (which includes a graph of nodes) as a separate ERC. I’ll work on that later. The current Policy Handler is still in reference implementation mode, at least in its public version, and my aim is to improve it further. If you would like to take a look, I’ll share it with you via DM. This is b.

1 Like