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 Complianceby standardizing a Policy Engine
Each rule is packaged in small contract called artifact
Each artifact contract can be reused by other policies and has to expose minimal interface (init, exec) and self-descriptors
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
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
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.
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.
Yep, improvements/role escalations (or any other action) can be constrained by policies
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)
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
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.
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.
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.
Regarding privacy (or onchain verificaion): any logic that can be coded as a smart contract can be converted to a policy artifact. I just need to find time to create an example using verifiable credentials – the same standard that Privado.id is built on top. This should give zero friction and work smoothly. like a clockwork.
__
@denniswon Do you have any specific questions about the standard?
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?
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.
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?
@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.
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?
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?
