This proposal defines a minimal interface for consuming a confidential policy verdict: a zero-knowledge proof that a proposed agent action was evaluated against a committed policy and permitted, where the policy itself is never revealed on-chain.
A Policy Domain registers a commitment to its ruleset as a statement in the ERC-7812 Evidence Registry. An off-chain policy engine evaluates a candidate action against the ruleset and emits a proof whose public inputs bind the verdict to an ERC-8004 agent identity, the ERC-7812 policy root the decision was made against, a commitment to the action, the address permitted to execute it, an expiry, and a single-use nullifier. A guard contract on any EVM chain verifies that proof locally and gates execution on it.
This standard does not define the policy language, the proving system, or the transport. It defines only the verdict envelope and the verification interface.
The agent standards landing on Ethereum authorize agent behaviour in one of two ways.
The first is retrospective: ERC-8004 records identity, reputation, and validation attestations after an agent has acted. This is useful for relying party selection and useless for interdiction.
The second is mandate-based: a verifier confirms, before execution, that an agent's batch matches an intent the user signed in advance. A bounded mandate meters how much authority an agent has spent. Both approaches derive authority from a principal who signs a specific grant.
A large class of real deployments fits neither. Consider a corporate expense card. The cardholder does not pre-sign each purchase, and the card network's fraud rules are not shown to the cardholder or to merchants. Authority comes from a standing ruleset held by a third party, applied to every transaction, updated without anyone re-signing anything, and deliberately kept secret, because a published fraud rule is a published evasion guide.
Agent deployments in regulated settings have the same shape. An operator maintains screening rules. Agents are subject to those rules whether or not any relying party signed them. The rules change weekly. Publishing them defeats them.
No current standard covers this, and the two obvious workarounds both fail:
Zero knowledge resolves the tension: the verifier learns that some committed policy was correctly evaluated and returned allow, and learns nothing about the policy's contents. ERC-7812 already supplies the missing half, since it defines a registry of blinded statements whose state can be proven in zero knowledge, and it is written abstractly so that later ERCs can build specific use cases on top of it. Nothing in the agent cluster has taken it up.
This ERC is that bridge: ERC-8004 for who the agent is, ERC-7812 for what the policy commits to, and a verdict envelope in between.
This standard hides the policy, not the action. A permitted action executes on a public chain and is public. The confidentiality guarantee is that no observer, including the executing agent, learns the rules that permitted it.
A denied action is never submitted and therefore never disclosed. This is a side effect of the design, not a guarantee it offers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
The normative core of this standard is the Verdict envelope, the actionCommitment definition, and the IConfidentialPolicyVerdict interface. Any compliant Guard MUST implement these.
A Verdict is an integrity property only: it proves the committed interpreter was evaluated over the action and returned ALLOW. It says nothing about whether the underlying policy is correct, fair, or non-malicious. Implementers MUST NOT treat a Verdict that satisfies verify or consume as evidence that the policy behind it is safe. See Security Considerations.
IPolicyDomainRegistry (below) is a RECOMMENDED companion interface for managing domains and roots. Implementations MAY substitute an equivalent mechanism, provided it exposes the semantics that the core interface's ordered checks depend on: identityRegistry for check 2, active for check 3, isRootAcceptable for check 8, and programKey for check 9. It is specified here so that independent Guards and Domains interoperate by default, not to bind the core to a single registry design.
domainId.EvidenceDB SMT root containing the current Policy Commitment.Two hash functions appear in this standard, and each MUST be used only where specified:
actionCommitment and the on-chain event/struct hashing MUST use keccak256, so a Guard recomputes the same digest the EVM produces natively.nullifier MUST use the field-friendly hash H of the target EvidenceDB. Because ERC-7812 requires keys and values to fit the underlying curve's prime field and RECOMMENDS a ZK-friendly hash, H is Poseidon for the deployed singleton registry.A proving backend that exposes an efficient keccak256 primitive can compute both cheaply — whether that is a zkVM precompile (e.g. SP1, RISC Zero) or a circuit DSL's standard-library black-box function (e.g. Noir's std::hash::keccak256, backed by Barretenberg). This standard does not mandate a proving backend; IVerifier is deliberately backend-agnostic. Implementations MUST NOT submit a keccak256 digest as an EvidenceDB value without reducing it into the field.
Every field of Verdict MUST be a public input of the proving program. Implementations MUST NOT place any field of Verdict in the private witness.
decision is one bit, so on its own it collapses every refusal into a single "denied". policyKind keeps the four states the standard distinguishes separable at the surface a relying party actually reads:
policyKind | Meaning | Valid decision |
|---|---|---|
0 (ALLOWED) | the policy authorized the action | 1 |
1 (DENIED) | a rule fired against the action | 0 |
2 (NOT_PERMITTED) | nothing authorized the action | 0 |
3 (COULD_NOT_EVALUATE) | the policy could not be evaluated | 0 |
policyKind MUST be a public input of the proving program, on every program, so a verdict cannot assert a kind its proof did not establish. A decision of 1 MUST carry policyKind == 0; a decision of 0 MUST carry a policyKind in {1, 2, 3}. An implementation MUST reject a verdict whose decision and policyKind disagree, before any other check that could make the disagreement unobservable.
A consumer gating an irreversible action needs this distinction: "a rule refused this" and "no rule authorized this" call for different handling, and a companion that anchors refusals MUST carry the kind through to its read surface rather than recording a generic denial.
The Guard MUST recompute actionCommitment from the action it is about to execute and MUST compare it to Verdict.actionCommitment. A Guard MUST NOT accept an actionCommitment supplied by the caller.
actionNonce MUST be strictly increasing per agentId within a domain. It prevents two identical actions from sharing a commitment. domainId binds the commitment to one policy domain, so a verdict minted under one domain's programKey cannot be replayed as authorization for the identical action under a different domain sharing the same Guard.
consume MUST perform its checks in this order, and MUST revert on the first failure:
v.decision and v.policyKind agree, else VerdictKindMismatch. This is first because every later check can make the disagreement unobservable.domain(v.domainId).identityRegistry != address(0), v.agentId exists in that registry, else AgentUnknown. A domain that declares no identity registry skips this check. It is second for the same reason the first is first: a later check would make an unknown agent unobservable.domain(v.domainId).active is true, else DomainInactive.v.decision == 1, else VerdictDenied.v.executor == msg.sender directly, or executorAuth is a valid EIP-712 signature by v.executor over verdictDigest(v). Else ExecutorMismatch (no signature and msg.sender != v.executor) or ExecutorAuthInvalid (a signature was given but does not validate).block.timestamp < v.expiry, else VerdictExpired.isConsumed(v.domainId, v.nullifier) is false, else VerdictReplayed.isRootAcceptable(v.domainId, v.policyRoot) is true, else PolicyRootRejected.domain(v.domainId).programKey with v as public inputs, else InvalidProof. A verifier that reverts MUST surface as InvalidProof, not as the verifier's own error.Check 5 is not optional. See Security Considerations.
verify MUST apply the same identity condition as check 2, as a boolean short-circuit: it MUST return false, rather than revert, for an agentId that does not exist in a registry the domain declares.
A revoked domain MUST cause isRootAcceptable to return false for all roots immediately, with no grace window. Revocation is the emergency path and MUST NOT be subject to maxRootAge.
identityRegistry MAY be declared at registration or set later by whoever administers the domain, and a registry that permits it to change MUST emit DomainIdentityRegistryUpdated, because the field decides whether the agent-existence check applies at all.
A Policy Domain MUST register its Policy Commitment through an ERC-7812 Registrar as a key/value statement. A Registrar MUST write each version to a distinct key and MUST NOT overwrite a historical statement, because an auditor verifying a past decision needs the ruleset that was live at that version and every proof against it keeps verifying regardless:
where H is the field-friendly hash defined under Hash functions.
policyCommitment MUST NOT be blinded with a commitment key. It is a plain hash of the ruleset.
This is a deliberate departure from ERC-7812's blinding pattern. Blinding would make the commitment unverifiable even to a party holding the ruleset, which destroys the audit path described below. Preimage resistance alone provides the required confidentiality, because a ruleset has enough entropy to resist enumeration. Domains whose rule sets are low-entropy MUST pad them with a high-entropy salt before hashing.
The program proven MUST be a policy interpreter, not a compiled policy. It takes the ruleset as private witness and the Verdict fields as public inputs, and MUST enforce:
policyCommitment that is included in policyRoot, verified by an ERC-7812 inclusion proof against the EvidenceDB structure under H(domainId, version).(chainId, target, value, callData, actionNonce), combined with the public domainId and agentId, hashes to actionCommitment under the definition above.decision.nullifier is derived deterministically as H(domainId, agentId, actionCommitment, actionNonce). Because actionCommitment is a full 256-bit keccak digest and does not fit in H's underlying field on its own, implementations MUST reduce it into two field-sized limbs (e.g. high/low 128-bit halves) before hashing, consistent with the reduction rule in Hash functions.The program MUST NOT accept decision as an input to be attested. It MUST compute it.
Changing a ruleset MUST NOT change programKey. See Rationale.
A domain MAY declare the ERC-8004 Identity Registry its agent ids live in, as Domain.identityRegistry. Where a domain declares one, agentId MUST be a valid token id in that registry, and a Guard MUST reject a verdict whose agentId is not, with AgentUnknown. Existence is an ERC-721 ownership read: a Guard MUST treat agentId as existing if and only if ownerOf(agentId) on the declared registry returns a non-zero address without reverting, and MUST treat a reverting registry as an absent agent rather than propagating its error. A declared address holding no code names no agents, so a Guard MUST reject against it with AgentUnknown rather than reverting without data.
Domain.identityRegistry == address(0) declares no registry. The Guard then performs no existence check, and agentId is an opaque public input this standard binds cryptographically but does not resolve. This is the conditional form of the requirement rather than a universal one because the registry a Guard reads is the one on the chain where the verdict is consumed, cross-chain identity resolution is out of scope here and is deferred to a future ERC, and this standard's hub-and-spoke design (see Rationale) expects verdicts to be consumed on spoke chains where an Identity Registry need not be deployed at all. A domain that declares a registry gets the enforced binding; a domain that cannot gets a standard that stays usable and does not silently claim an identity check it never made.
A Guard SHOULD, after a successful consume, write an attestation to the ERC-8004 Validation Registry recording that agentId satisfied domainId at policyRoot. This exposes the fact of compliance to the public reputation layer while disclosing nothing about the policy. The attestation payload MUST NOT contain the ruleset or any part of it, and SHOULD have the following shape:
Two fields make the attestation composable and unambiguous in a shared registry:
artifactHash is a content-addressed reference to the specific action judged, not a class of actions. It is exactly Verdict.actionCommitment (the canonical PolicyAction hash), so a consumer can confirm the attestation is about one concrete action. Implementations already carry this value. They MUST surface it in the attestation.mechanism is a source-class tag describing how the verdict was reached (self-attested, independent-mediator, ZK-against-secret-policy, public-recomputable). Verdicts of structurally different guarantees written into one registry without this tag can be silently conflated into a single pass/fail signal downstream. A Guard for this standard MUST set mechanism to keccak256("zk-secret-policy").A guarded contract MUST expose policyDomain() and MUST call consume before dispatching the action. It MUST revert the whole transaction if consume reverts.
This is the load-bearing choice.
If the policy is compiled into a circuit, every policy update produces a new verification key, which means a new verifier deployment, on every chain, for every rule change. For a ruleset that changes weekly this is not an operational inconvenience, it is a disqualification.
By proving a fixed interpreter and passing the ruleset as witness, programKey stays constant across policy updates. Only the ERC-7812 root moves. This is why the specification insists the program be an interpreter, and it is why the standard is realistic to operate at all. The interpreter can be written for a zkVM (a fixed guest program, ruleset as data) or directly in a circuit DSL (a fixed circuit that takes the ruleset as private witness, as the reference implementation's Noir circuit does); either way, programKey is a commitment to the interpreter, not to any one ruleset.
Whether keccak256 (used for actionCommitment, matching the EVM's native hash) is cheap to compute in-circuit depends on the backend, not on the zkVM-vs-DSL choice itself: a zkVM precompile and a circuit DSL's black-box keccak256 (e.g. Noir/Barretenberg, used by the reference implementation) are both efficient; a backend without such a primitive would push a domain toward computing keccak256 the hard way or toward a field-friendly-hash-only design.
The cost is asymmetric: the interpreter proves a superset of any single policy, so proofs are more expensive than a bespoke circuit for the same rule. That is the correct trade. Proving cost is paid off-chain by the domain, verification key churn is paid on-chain by everyone.
The reusable, chain-agnostic contribution is the verdict envelope and its verification. Domain and root management is deployment policy, and reasonable operators will differ (a single hub, a per-tenant registry, an existing access-control system). Binding the core to one registry would force those operators to fork the standard. So IPolicyDomainRegistry is specified as the default that makes independent implementations interoperate, while the core interface depends only on the three semantic hooks it actually calls.
ERC-7812 is deployed on Mainnet and Sepolia at a deterministic address and was designed as a singleton specifically so that only a single bytes32 root needs to cross chains to prove registry state. A hub-and-spoke policy deployment needs exactly that and nothing more. It also states that it was written abstractly to let subsequent ERCs build specific use cases on top. This is one. Defining a parallel registry would fragment the trust anchor for no benefit.
A blinded commitment is confidential and not auditable, which is a worse trade than preimage resistance alone. The non-blinded commitment is what enables selective disclosure to auditors (see Security Considerations).
A signature over a verdict can be replayed by anyone who observes it. The nullifier plus executor binding makes a verdict a bearer instrument with exactly one bearer and exactly one use.
decision exists at all if only ALLOW is consumableconsume rejects DENY, but the envelope carries decision because a DENY verdict is a useful off-chain artifact: it is evidence an agent can present to its operator, or an operator to an auditor, that a specific action was refused under a specific root. Keeping one envelope for both avoids a second format. Because decision is computed in-circuit (never attested as an input), carrying it on-chain costs one byte and grants no authority a DENY could abuse.
No backwards compatibility issues. This standard is purely additive and introduces no changes to existing interfaces. Contracts that do not implement IPolicyGuarded are unaffected.
Verdicts are inert without a Guard. Deploying the registry and verifier does not alter the behaviour of any existing agent.
A conformant implementation passes at least the following, expressed against consume unless noted. Each case below is excerpted, unmodified, from the Foundry suite at ConfidentialPolicyVerdict.t.sol, which runs against the shared fixture:
Happy path -- a valid ALLOW verdict from the current root, submitted by v.executor, succeeds, burns the nullifier.
Replay -- re-submitting a consumed verdict reverts VerdictReplayed.
Expiry -- block.timestamp >= v.expiry reverts VerdictExpired.
Executor authorization -- direct submission by any address other than v.executor, with no executorAuth, reverts ExecutorMismatch; a relayed submission with an invalid signature reverts ExecutorAuthInvalid; both even with an otherwise valid proof.
DENY not consumable -- a well-formed refusal, decision == 0 carrying a refusal kind, reverts VerdictDenied.
Decision / kind disagreement -- a verdict whose decision and policyKind disagree is refused by ordered check 1, in both directions, and before any check that could mask it:
Action binding -- a verdict whose actionCommitment does not match the action a guarded contract is about to execute reverts at the guarded contract, before consume is ever called:
Cross-chain / cross-domain replay -- given identical (agentId, target, value, callData, actionNonce), the commitment computed with chainId = 1 differs from the one computed with chainId = 2, and the commitment computed under one domainId differs from the one computed under another, because PolicyAction.commit carries both as leading fields of the preimage. A verdict minted for one chain or domain therefore never matches the commitment a guarded contract recomputes on the other.
Stale-root grace -- a verdict against a root superseded less than maxRootAge ago succeeds; one older than maxRootAge reverts PolicyRootRejected.
Revocation -- after DomainRevoked, every verdict against the domain reverts DomainInactive immediately, with no grace window.
Malformed proof -- verify returns false (does not revert) for malformed proof bytes.
ERC-8004 identity binding -- when the domain declares an Identity Registry, an agentId that does not exist there is refused by ordered check 2, ahead of anything that could mask it, and verify returns false on the same condition. When the domain declares none, the same agentId is consumable, because the check is conditional on the declaration.
Generation-agnostic root grace -- two rotations inside maxRootAge keep every superseded root acceptable until its own window closes. Each retained root is measured against the moment it stopped being current, not against the current root's timestamp, so roots age out on separate schedules.
The suite additionally covers the relayed-consume happy path, supportsInterface, and the ERC-8004 attestation handoff; see the full file for those.
A reference implementation is provided alongside this proposal (CC0), implemented and tested with Foundry and Noir. The Test Cases above, the relayed-consume path, supportsInterface, and the ERC-8004 attestation handoff all run as an executable suite:
ConfidentialPolicyVerdict.sol -- the Guard (verify / both consume overloads / isConsumed), checks in the order specified, and PolicyDomainRegistry.sol, the companion registry (root rotation with maxRootAge grace, immediate revocation). It measures each superseded root's grace against the moment that root stopped being current, not against the current root's timestamp, so rotating twice inside one window does not drop the older generation. It retains eight superseded generations per domain, which bounds both its storage and the scan isRootAcceptable performs; a domain that rotates more often than that inside its own window loses its oldest roots early, rejected sooner than maxRootAge rather than later, so the bound fails closed. A registry that wants the rule without approximation can retain more.IIdentityRegistry.sol -- the single ERC-8004 Identity Registry call the Guard makes, an ERC-721 ownerOf read, declared minimally rather than imported, with MockIdentityRegistry.sol as the test double for the conditional agent-existence check.IVerifier.sol boundary (verifyProof(programKey, publicInputs, proof)), with MockVerifier.sol as the test double the Guard suite runs against.PolicyAction.sol -- the canonical, chain- and domain-separated action-commitment preimage, hashed identically on-chain and in-circuit.SignatureChecker (ECDSA and ERC-1271) -- see verdictDigest and the second consume overload in the Specification.GuardedExecutor.sol -- an example guarded contract that recomputes the canonical commitment before dispatching the action.IPolicyAttestation.sol -- the VerdictAttestation payload, with MockValidationRegistry.sol as the ERC-8004 handoff's test double.IConfidentialPolicyVerdict interfaceId is 0xd6da8150.nargo test passes). It enforces the action-commitment, nullifier, and in-circuit executor-binding obligations from Proving program contract.The Verdict struct and the IConfidentialPolicyVerdict interface together form the normative core, and the implementation carries the exact interface described in the Specification, including the EIP-712 relayed-consume path:
The canonical PolicyAction struct and PolicyActionLib library define the commitment preimage that BOTH the on-chain guarded contract and the proving program hash with keccak256 over the identical field ordering:
GuardedExecutor.sol recomputes the canonical commitment, consumes the verdict, and executes. The executor question is resolved cryptographically: pass executorAuth = "" for direct submission (v.executor == this), or pass an EIP-712 signature by v.executor for relayed submission. The excerpt below elides the custom errors and the nonce lookup helper present in the full contract:
After a successful consume, a guarded contract can write an attestation to the ERC-8004 Validation Registry. The VerdictAttestation struct and PolicyAttestation library produce the canonical payload:
Off-chain proof generation is decoupled from on-chain submission, so a verdict transits a public mempool before it lands. Without executor as a public input, any observer can lift a valid verdict from a pending transaction and front-run its consumption. The binding must be enforced inside the proving program, as a public input the proof commits to. Checking msg.sender in the Guard alone is insufficient, because a Guard is not the only possible consumer of a proof whose public inputs omit the executor. The Specification forbids using tx.origin for this check.
Relayed submission (a signature by v.executor authorizing an arbitrary msg.sender, see Specification) does not weaken this: the proof still commits v.executor as a public input, so front-running the relay only changes who pays gas, not what executes or on whose authority.
Domain.identityRegistry is what makes the ERC-8004 side of the composition enforceable. A domain that declares one gets an agent-existence check on every consume. A domain that declares none gets no such check, and agentId is then only as meaningful as the proof that binds it: a verdict can name an id no registry ever issued, and a VerdictAttestation written after it lands in the public reputation layer keyed on an identity that does not resolve. Relying parties reading attestations are advised to read the issuing domain's identityRegistry before treating agentId as a resolvable identity, and domains on a chain that hosts an Identity Registry are encouraged to declare it. The check is conditional rather than universal because this standard's hub-and-spoke design expects verdicts to be consumed on spoke chains where no Identity Registry need be deployed, and cross-chain identity resolution is deferred to a future ERC. An obligation that the design's own target chains cannot discharge would be enforced nowhere.
A declared registry is trusted at the level of the domain that declared it, and the domain's admin can rotate it. Implementers are advised to monitor DomainIdentityRegistryUpdated for the same reason they monitor DomainProgramUpdated.
maxRootAge exists because a spoke chain's mirrored root lags the hub. Setting it to zero makes verdicts unusable during any sync gap. Setting it high means a rule removed from the policy keeps authorizing actions for maxRootAge seconds on every spoke. Domains are best served treating maxRootAge as their revocation service-level agreement and documenting it. Domains handling adversarial agents do well to keep it under one block time on the slowest spoke, and accept the liveness cost. DomainRevoked is the escape hatch and bypasses the window entirely. It is coarse by design, stopping the whole domain rather than one rule.
A valid proof establishes that the committed ruleset was evaluated faithfully. It establishes nothing about whether the ruleset is correct, fair, or non-malicious. A domain that commits to always allow produces proofs that verify. A verdict is not a safety property (see Specification); it is an integrity property over a policy whose merit is a separate question, answered socially rather than cryptographically.
There are two guarantees an implementer might want, and this ERC carries only the first. Action-level integrity is that the interpreter committed at programKey was evaluated over this action and returned ALLOW, bound to agentId, policyRoot, actionCommitment, executor, and a single-use nullifier. This is what a verdict proves. Interpreter-level fidelity is that this interpreter actually implements the policy the domain intends. This ERC does not prove it. The two look identical on-chain, which is the trap: a deviant interpreter is faithful to itself, applying its own wrong rule consistently, so its proofs verify perfectly while it judges crooked. The verifier cannot separate a correct interpreter from a consistently-wrong one, because each produces valid proofs against its own policyRoot. Fidelity is therefore established out of band. Implementers that need it can publish the interpreter's provenance, its specification commit, implementation commit, review method, and lineage, in a companion registry that is content-addressed to the interpreter hash and append-only in the ERC-7812 pattern, kept beside this standard rather than inside it for the same reason the domain registry is a companion. Such a record makes a claimed lineage permanent, signed, and attributable. It does not make it true. A fabricated ancestor stays possible, only visible and imputable to a name. A fidelity record is best read as a contestable, content-addressed assertion, not as a proof.
A rejected agent cannot see why it was rejected, and cannot tell a correct application of a harsh rule from an incorrect application of a fair one. This is inherent, and it is a real cost of the design rather than an implementation gap. The non-blinded commitment is the mitigation: a domain can disclose its ruleset to a specific party out of band, and that party can verify it hashes to the commitment that was live at a given root and version. This yields selective disclosure to auditors and regulators without public disclosure. Domains are encouraged to publish their disclosure policy: who can compel the ruleset, on what grounds, and within what period. A domain that commits to a ruleset it will disclose to nobody should be treated by implementers as an unaccountable oracle with extra steps.
Because the commitment key is H(domainId, version), an auditor verifying a historical decision needs the ruleset that was live at that version, not the current one. The Specification requires Registrars to write each version to a distinct key and never overwrite a historical statement. Overwriting destroys the audit trail while leaving every proof still verifying.
actionCommitment binds block.chainid, so a verdict for one chain cannot be replayed on another. It binds domainId, so a verdict minted under one policy domain cannot be replayed as authorization for the identical action under another domain sharing the same Guard. It binds actionNonce, so two identical actions do not collide. Omitting any of these fields reintroduces replay across chains, across domains, or across repeats, which is why the Specification requires all of them.
If the nullifier is supplied rather than derived, a domain can mint many nullifiers for one action, defeating single use. The Specification requires the program to compute it from (domainId, agentId, actionCommitment, actionNonce), reducing the 256-bit actionCommitment into field-sized limbs first.
DomainProgramUpdated allows a domain to fix a bug in its interpreter. It also allows a domain to silently swap the semantics of every future verdict. Implementers are advised to monitor DomainProgramUpdated and to treat an unannounced rotation the same as a revocation.
An agent cannot act if the domain's policy engine is offline. This standard makes the policy engine a hard dependency in the execution path. Domains benefit from issuing verdicts with expiration times long enough to survive short outages, at the cost that a long expiry widens the window in which a since-revoked permission remains usable. There is no configuration that avoids both.
This ERC requires ERC-7812 and ERC-8004, both recent and pre-Final at the time of writing. A Standards Track ERC can sit in Draft or Review atop pre-Final dependencies, but it cannot advance to Final until they do. Implementers are advised to pin the exact versions of the dependencies they rely on.
Copyright and related rights waived via CC0.