Add ERC: Purpose-Bound Third-Party Data Consent

[duribebe]

Add ERC-8356: Purpose-Bound Third-Party Data Consent

Adds a new Standards Track ERC proposing a consent grant in which the party who consents is
not the party who benefits.

Discussion: https://ethereum-magicians.org/t/erc-8356-purpose-bound-third-party-data-consent/29217

What this proposes

Every delegation standard currently on the Standards Track is two-party: the principal who
signs is the principal who benefits, and the asset at risk is the principal's own. This
proposal standardizes the three-principal case, which is the shape of consent to use data
about a person:

1. a subject, whose data the grant concerns and whose assent it records
2. a grantee, authorized to exercise the grant
3. an agent, an optional principal exercising it on the grantee's behalf

Three properties follow, none of which I was able to express with existing standards:

• A non-party subject's withdrawal is operative for a relying party at access time, not
  merely recorded. ERC-8328 models a subject but states it "does not define compliance
  policy", and its OUTCOME_REVOKED is an assertion nothing consults.
• The agent leg is revocable independently of the human grant, which is what an incident
  response needs when a session key or tool provider is compromised.
• Purpose is bound through a versioned code registry, with an unset registry failing closed.

Why not a profile of ERC-8226

ERC-8226 is the nearest neighbour. Its Mandate is keyed (agent, principal) with no seat
for a third person, it checks compliance at grant time only, and its metadata field is
expressly non-normative ("MUST NOT rely on it for enforcement decisions"). The two compose
rather than subsume: an agent may hold an 8226 mandate over a payment asset and a grant under
this proposal over a data asset.

Reference implementation

Deployed across three chains at 16,892 bytes runtime (open-item revision, 2026-08-01).
Runtime is not byte-identical across chains because each embedding includes its own
address(this) for the EIP-712 / self checks; all three share the same compiler
artifact, selectors, and constants (MAX_DEPTH=4, purpose registry = zero / fail-closed).

chain	address
Avalanche mainnet (43114)	0x360ac376e20B4d930da810f7CeA935F52693a84C
Avalanche Fuji (43113)	0xc92f9f1D68A445189Ad3ad28524186A11Be30DcA
Sequentia (15132025, permissioned)	0xD526E4d6e449A091D18900DC9ACb183e9556F714

48 tests, mostly negative. The load-bearing assertions are that a sub-grant cannot exceed its
parent on scope, ops, expiry, purpose or uses; that a claimed-but-unproven agent identity
never satisfies an agent constraint; that revoking the agent leg leaves the human grant alive;
that suspension is the only non-terminal return to ACTIVE; and that revocation cost does not
grow with the number of delegated children.

Prior deployments remain live and are listed under superseded in deployed-addresses.json.
They lack suspend / resume / terminateByIssuer and ancestor leaf inheritance.

Review history

I ran the spec and implementation through an adversarial review before opening this. Seven
findings classed as publication blockers were fixed before the first push. The privacy
contradiction (rule 1 vs rule 7) was resolved in a follow-up: address subject became
bytes32 subjectCommit, rule 1 narrowed to identifiers with meaning outside the protocol,
and subjectOf() was published so the zero-subject profile is buildable.

Editors assigned ERC-8356 (branch name still says 8355 so the open PR is not detached).

Open items closed in this revision

All previously deferred items are now normative in the draft:

1. usesMax honesty. Stated as a contractual ceiling the constrained party self-reports
   through commitUsage, not a cryptographic bound.
2. Usage hash chain. H = keccak256, h_0 = 0, record schema fixed; "completeness"
   claim removed.
3. Merkle construction. Double-hashed leaf, sorted-pair interiors; withdrawn leaves
   inherit across ancestors.
4. Status transitions. Full transition table; suspend / resume / terminateByIssuer
   added; resume of SUSPENDED is the only non-terminal return to ACTIVE.
5. checkAccess and eth_call. Explicit that an off-chain eth_call with client-chosen
   from authenticates nothing; combine isGrantActive with independent agent auth.
6. termsRef vs VC instance. MUST hash the versioned template from termsOfUse, never
   the per-subject credential.
7. Purpose profile ordering. Array MUST be sorted by term before RFC 8785
   canonicalization.
8. Subject commitment opening. Normative
   subjectCommit = keccak256(abi.encode(subjectSalt, subjectKey)).

Checklist

• File named ERCS/erc-8356.md, number assigned by editor (@abcoathup)
• Preamble fields present and in the order preamble-order requires
• Title 38 characters, description 139 characters, both within limits
• All five required sections present, in markdown-order-section order
• Proposals referenced as [ERC-N](./eip-N.md), matching repository convention
• requires: 165, 712, 1271, each linked at first mention
• discussions-to set to the Ethereum Magicians thread for ERC-8356

[eip-review-bot]

File ERCS/erc-8356.md

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

[abcoathup]

Suggested change

	eip: 8355
	eip: 8356

@duribebe
Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.

Please also update the filename.

[abcoathup]

Suggested change

	discussions-to: https://ethereum-magicians.org/t/purpose-bound-third-party-data-consent-a-grant-where-the-consenting-party-is-not-the-beneficiary/29217
	discussions-to: https://ethereum-magicians.org/t/erc-8356-purpose-bound-third-party-data-consent/29217

Updated Eth Magicians title with assigned number & title

[github-actions]

The commit ab86323 (as a parent of 3a26502) contains errors.
Please inspect the Run Summary for details.