Add ERC: Permissioned Pull - #1401
Conversation
Add ERC-A: Permissioned Authorization Object (PPO)
Add ERC-B: Permissioned Pull Execution Interface
|
✅ All reviewers have approved. |
| @@ -0,0 +1,216 @@ | |||
| --- | |||
| eip: <to be assigned> | |||
There was a problem hiding this comment.
| eip: <to be assigned> | |
| eip: 8102 |
Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.
Please also update the filename.
| @@ -0,0 +1,216 @@ | |||
| --- | |||
| eip: <to be assigned> | |||
| title: Permissioned Pull Execution Interface | |||
There was a problem hiding this comment.
| title: Permissioned Pull Execution Interface | |
| title: Permissioned Pull |
Interface seems superfluous in an ERC title. Note: I am not an editor.
Given you used Permissioned Pull in the discussion topic on Eth Magicians, you may want to go with that.
| title: Permissioned Pull Execution Interface | ||
| description: Standard interface for executing pull-based transfers using Permissioned Authorization Objects (PPOs). | ||
| author: Mats Heming Julner (@recurmj) | ||
| discussions-to: https://ethereum-magicians.org/t/draft-erc-rip-001-permissioned-pull-standard-consented-flow-layer-for-digital-value/25931 |
There was a problem hiding this comment.
| discussions-to: https://ethereum-magicians.org/t/draft-erc-rip-001-permissioned-pull-standard-consented-flow-layer-for-digital-value/25931 | |
| discussions-to: https://ethereum-magicians.org/t/erc-8102-permissioned-pull/25931 |
Updated with assigned number and title
| @@ -0,0 +1,217 @@ | |||
| --- | |||
| eip: <to be assigned> | |||
There was a problem hiding this comment.
| eip: <to be assigned> | |
| eip: 8103 |
Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.
Please also update the filename.
| title: Permissioned Authorization Object (PPO) | ||
| description: "A portable, revocable EIP-712 authorization struct for bounded pull-based transfers." | ||
| author: "Mats Heming Julner (@recurmj)" | ||
| discussions-to: "https://ethereum-magicians.org/t/draft-erc-rip-001-permissioned-pull-standard-consented-flow-layer-for-digital-value/25931" |
There was a problem hiding this comment.
Each ERC should have a separate discussions thread
|
Please note, ERCs are not for promotion/marketing purposes. |
|
Suggest splitting each ERC into a separate PR. |
|
Thanks for the guidance. I’ve split the specification into ERC-8102 (execution) and ERC-8103 (authorization), updated filenames, cross-references, titles, and discussions-to links accordingly. Let me know if anything else is needed. |
Removed the word “standard” in description
| @@ -0,0 +1,217 @@ | |||
| --- | |||
| eip: <8103> | |||
There was a problem hiding this comment.
| eip: <8103> | |
| eip: 8103 |
| title: Permissioned Authorization Object (PPO) | ||
| description: "A portable, revocable EIP-712 authorization struct for bounded pull-based transfers." | ||
| author: "Mats Heming Julner (@recurmj)" | ||
| discussions-to: "https://ethereum-magicians.org/t/erc-permissioned-authorization-object/27135" |
There was a problem hiding this comment.
| discussions-to: "https://ethereum-magicians.org/t/erc-permissioned-authorization-object/27135" | |
| discussions-to: https://ethereum-magicians.org/t/erc-8103-permissioned-authorization-object/27135 |
| --- | ||
| eip: <8103> | ||
| title: Permissioned Authorization Object (PPO) | ||
| description: "A portable, revocable EIP-712 authorization struct for bounded pull-based transfers." |
There was a problem hiding this comment.
| description: "A portable, revocable EIP-712 authorization struct for bounded pull-based transfers." | |
| description: A portable, revocable EIP-712 authorization struct for bounded pull-based transfers. |
Fix license link
Fix license link
Fix typo malleability
Added a security consideration line and fixed 8103 link to be consistent
Fixed 8103/8102 reference links for consistency
| --- | ||
| eip: 8102 | ||
| title: Permissioned Pull | ||
| description: Interface for executing pull-based transfers using Permissioned Authorization Objects (PPOs). |
There was a problem hiding this comment.
| description: Interface for executing pull-based transfers using Permissioned Authorization Objects (PPOs). | |
| description: Pull-based transfers using Permissioned Authorization Objects (PPOs). |
If we cut out some obvious bits, you have more room for details. What is a PPO, for example.
| This EIP defines a standard **pull executor interface** for executing token transfers under a Permissioned Authorization Object (PPO) as specified in [ERC-8103](./eip-8103.md). | ||
|
|
||
| It specifies: | ||
|
|
||
| - the `Authorization` struct used at execution time, | ||
| - the `pull` function signature, | ||
| - required view functions for nonce and domain separation, | ||
| - canonical events and errors, | ||
| - normative execution rules (validation, revocation, transfer). |
There was a problem hiding this comment.
This does a good job covering what your proposal is, but doesn't really include the purpose. Doesn't have to be long (that's what the motivation is for), but a sentence or two about why we need this proposal is usually good in the abstract.
|
|
||
| ## Specification | ||
|
|
||
| ### 1. Interface |
There was a problem hiding this comment.
Don't number your sections.
|
|
||
| Compliant contracts MUST implement the following Solidity interface (or an ABI-compatible equivalent): | ||
|
|
||
| ~~~ |
There was a problem hiding this comment.
I have no idea if our renderer will support this syntax. Best to stick with the traditional:
```solidity
// ...
```| - Nonce marking MUST follow checks-effects-interactions; state changes MUST precede external calls. | ||
| - Implementations MUST consider token quirks (fee-on-transfer, non-standard return values) and SHOULD document behavior with such tokens. | ||
| - Time windows reduce exposure of leaked signatures; however, key security is still critical. | ||
| - Malicious grantees cannot exceed `maxPerPull` in a single call, but they MAY call `pull` multiple times if the authorization semantic allows. Systems requiring cumulative caps SHOULD implement them in higher layers or registries. | ||
| - Implementations MUST reject malleable signatures by enforcing [EIP-2](./eip-2.md) rules (low-`s` values and valid `v`), as specified in ERC-8103. |
There was a problem hiding this comment.
Requirements necessary to make a secure implementation should be included in the specification section, but do discuss their implications here.
|
Appreciate the guidance here, thank you. Updates applied; happy to iterate further. |
Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
|
The commit 7867c0f (as a parent of 0583229) contains errors. |
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
This PR proposes two related ERCs that together define a portable, revocable pull-permission primitive:
Permissioned Authorization Object (PPO)
Permissioned Pull Execution Interface
transferFromunder strict rules.pull(), nonce & revocation views, canonical events, and normative execution behavior.Both drafts are aligned with the architectural analysis in RIP-000 / “The One-Shot Authorization Flaw in Digital Value Systems” and the updated RIP-001 thread. Philosophical framing has been removed; these drafts focus purely on:
The intention is for these to serve as the canonical ERC-A / ERC-B split that James and others suggested earlier:
I’m happy to adapt naming, file layout, or minor spec details to fit current ERC process preferences.