DApps keep re-implementing ad-hoc validation and compliance rules (roles, kyc, allowlists, limits, workflows, and other legally required validatons). It’s brittle to upgrade, hard to audit, and not reusable across projects.This ERC standardizes a Universal 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 bundles/orchestrates them as a Directed Acyclic Graph so apps can compose complex policies from simple building blocks and update them incrementally (swap/append artifacts instead of redeploying app 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
ERC-8006
ERC Authors list:
@Vlad, @Vitali
12 Likes
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
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
Hey, thanks for your interest!
- 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
2 Likes
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
