# Draft ASF proposal would register versioned commitments for Ethereum agents

Canonical: https://forkbrief.com/news/49ec25ce-871e-43d6-a70e-182f9f292c6f
Published: 2026-10-25T18:49:55.458Z
Publisher: Fork Brief

An open ERC filing proposes attributable bindings and registry checks, while leaving permission and enforcement verification to applications.

Gary Yang opened an Ethereum ERC [pull request](https://github.com/ethereum/ERCs/pull/2113) on October 25 proposing registries that record which account accepted a particular version of an agent’s operating requirements. The Agent Safety and Security Framework, or ASF, remains a Draft proposal in open, unmerged PR 2113. Its document uses 9999 as a placeholder, not an assigned ERC number.

The [design](https://github.com/ethereum/ERCs/blob/94e318a643e00f886dc638ffacb93916103ab203/ERCS/erc-9999.md) separates a reusable Safety Specification from a Safety Binding. A specification is a content-addressed document with immutable versions. A binding identifies the adopting account, subject, scope, chosen version, validity window and declared enforcement locations. Publishing version two would not silently rewrite an account’s acceptance of version one. Each binding would pin the specification’s content hash; changing a document’s locator would leave that hash and existing adoption unchanged.

A registry check would return Satisfied, NotSatisfied or Unknown, with reasons. Consumers could require all listed clauses, any clause or a specified number. These results concern the registered adoption relationship. They do not decide whether an action is permitted or demonstrate that a declared control actually operates.

The filing includes Solidity reference interfaces and [consumer examples](https://github.com/garyyang-finchip/agent-safety-framework). In the proposed account example, an operator’s execute call would consult the binding registry before forwarding a call. For a pending submission on the task adapter’s judged path, Satisfied leads to acceptance, NotSatisfied to rejection, while Unknown reverts and leaves the task’s existing judgment clock in force. These are code examples in the proposal, not executed demonstrations or evidence of a live integration.

Applications would still have to verify that an adopter can represent the named subject, fetch and verify referenced documents, and apply their own permission rules. The record identifies who made a commitment and the version they chose; it does not certify an agent.

A separate [draft ERC-8419 KYA model](https://tokenprimer.com/news/f8d9c00d-da8d-48a1-a8f1-3da824559eed) covers assertions about agents, a related registry question.

## Sources

- [Agent Safety and Security Framework reference repository, observed revision2 draft v0.3](https://github.com/garyyang-finchip/agent-safety-framework) — Gary Yang, ASF reference repository
- [Add ERC: Agent Safety and Security Framework](https://github.com/ethereum/ERCs/pull/2113) — Gary Yang, Ethereum ERCs pull request
- [ASF Draft specification at PR2113 head 94e318a643e0](https://github.com/ethereum/ERCs/blob/94e318a643e00f886dc638ffacb93916103ab203/ERCS/erc-9999.md) — Gary Yang, Ethereum ERCs proposed file
- [Draft ERC: Agent Safety Framework (ASF) — attributable adoption of versioned safety specifications](https://ethereum-magicians.org/t/draft-erc-agent-safety-framework-asf-attributable-adoption-of-versioned-safety-specifications/30073) — Ethereum Magicians

- [Editorial policy](https://forkbrief.com/editorial-policy)
- [Request a correction](https://forkbrief.com/corrections)