Draft ERC: Agent Safety Framework (ASF) — attributable adoption of versioned safety specifications

What it is

Draft ERC "Agent Safety Framework (ASF)" is a proposal in ethereum/ERCs PR #2113, authored under the GitHub handle garyyang-finchip. The PR uses the placeholder number 9999 until an editor assigns one. It standardizes two objects, one check and one composition rule, and requires only ERC-165. A reference repository holds the implementation, schemas, vectors, worked examples and two consumers.

How it works

A Safety Specification is versioned and content-addressed. Versions are immutable, so publishing v2 changes nothing for adopters of v1, and deprecation is only a signal. A spec names protected interests, applicability, constraints under named profiles, enforcement channels and their location (self, account, runtime, custodian, contract, collective), known bypasses, failure handling for unknown, denied and dependency failure, and pre-accepted remedies.

A Safety Binding records that the adopter, always msg.sender, adopts one pinned spec version for one subject and scope. It carries an external authority basis, declared enforcement locations, a validity window and named interveners with suspend, resume or terminate rights. The adopter is part of every identifier and index key, so the registry cannot attribute a binding to an account that did not accept it. Consumers, not the registry, check whether the adopter was entitled to adopt for the subject, using the permission source the binding references.

Lifecycle states are Active, Suspended and Terminated. Suspension carries one of five restrictions: no new risk, shrink, essential only, de-risk only, full stop.

Derived bindings take a parent's pinned version, stay inside the parent's validity window, require ancestors to hold, and never widen parameters under the profile's declared order.

check(requirement, bindingIds) evaluates clauses (explicit version lists, adopter, subject, scope, required enforcement locations) combined by all-of, any-of or k-of. It returns Satisfied, NotSatisfied or Unknown with a reason per clause. It tests only existence, state, validity, pin, adopter, subject, scope, enforcement and ancestors. It evaluates no policy, never scores, and never counts Unknown as satisfied. The resource's own authority rules decide which bindings are required.

What to do

Reviewers can comment in the thread on four open questions:

• Whether the registry check is the right boundary, or the kernel should normalize denial reasons from external policy mechanisms.
• Whether the derived-binding split is acceptable, with the structural rule on chain and the profile-order rule off chain.
• Whether five restriction values is the right granularity.
• Whether incident and claim records should enter the kernel later.

The author also asks for feedback on the overlap review with the mandate, verdict and delegation proposals.

Caveats

• Declared enforcement locations are attributable commitments, not proof of enforcement. The draft does not decide permissions, evaluate policies or certify alignment.
• Reference consumers: ASFGuardedAccount blocks new exposure under de-risk-only suspension while repayment and cancellation still work. ASFTaskTenderAdapter neither accepts nor rejects on Unknown. The evidence script was rehearsed on Anvil, and the Sepolia run is still to come.