# [Draft ERC / RIP-001] Permissioned Pull Standard: Consented Flow Layer for Digital Value

ERCs
1

(Note: “RIP-001” here refers to the Recur Improvement Proposal draft; not yet part of the official Rollup RIP process.)

Sharing this draft based on recent discussion with Ethereum Foundation contributors around formalizing the permissioned-pull primitive as an ERC-level standard.
Feedback on structure, naming, and security model is warmly welcome before moving toward ERC-A / ERC-B drafts.

Abstract

The current financial architecture of Ethereum remains push-based; transfers occur only after imbalance or failure, resulting in reactive liquidity and fragmented settlement.

The Permissioned-Pull Standard (RIP-001) introduces a consent-driven flow layer that allows value to move before failure through revocable pull permissions.

This standard aims to make digital value continuous instead of event-based, unlocking on-chain subscriptions, streaming payments, and dynamic credit flows built natively into Ethereum’s account abstraction model.

Motivation

While ERC-20 standardized fungibility and ERC-2612 enabled delegated approvals, neither define a generalized, safe mechanism for permissioned value retrieval.

A universal pull primitive would allow protocols, wallets, and dApps to coordinate recurring, metered, or conditional transfers without requiring custodial trust.

The intent is to evolve “payments” into “flows”; a foundation for continuous commerce, automated obligations, and on-chain financial continuity.

Specification Outline

This will mature through discussion, but the split that James proposed gives perfect clarity:

ERC-A: Permission State (Grant / Revoke)

  • Defines a minimal interface for granting, viewing, and revoking pull permissions.
  • Can be implemented by any token or account.

ERC-B: Pull Execution (Request / Fulfil)

  • Defines how an authorized pull request executes against a permissioned account.
  • Includes safety, expiry, and nonce patterns to prevent abuse.

Together, these two ERCs form the basis for consented flow of value across Ethereum networks.

Reference Implementation

A working prototype and SDK structure are live at:

github.com/recurmj/recur-standard

Maintained by Recur Labs, the repository demonstrates the canonical Solidity implementation, developer tooling, and security guidelines.

Next Steps

  1. Community feedback and naming refinement via Ethereum Magicians.
  2. Alignment with Account Abstraction and Safe Modules for native integration.
  3. Drafting ERC-A / ERC-B proposals for formal review and EIP number assignment.

Authors

Recur Labs (GitHub: @recurmj)

Advisory contributor (discussion): James (Ethereum Foundation)

(additional contributors to be added as discussion evolves)

2

Following up on the initial draft above (RIP-001), sharing a quick progress report and next steps before preparing the ERC-A / ERC-B formal drafts.

Since the original post 18 days ago, we successfully executed the first cross-network permissioned pull — proving that a signed consent (EIP-712 Authorization) can be observed and verified across chains without transferring custody.

This validates the core idea of Recur’s permissioned-pull primitive as a portable consent layer rather than a chain-bound payment mechanism.

—-

What’s been proven

  • A single EIP-712 Authorization struct signed by the grantor was executed on Ethereum Sepolia and then mirrored on Base Sepolia via observeAndVerify().
  • The same structHash + domainSeparator verified correctly on both networks.
  • This demonstrates that consent continuity (not custody) is sufficient to authorize value flow across chains; establishing a “flow layer” on top of existing liquidity rails.

—-

What’s next

Following guidance from EF contributors (James & Jason), I’m now preparing the split into two ERCs:

Draft Scope Analogy
ERC-A: Permissioned Authorization (PPO) Defines the EIP-712 struct, fields (grantor, grantee, token, maxPerPull, validAfter, validBefore, nonce), and replay protection rules. ERC-2612 (Permit)
ERC-B: Pull Execution Interface Defines how compliant contracts (PullSafe, SettlementMesh, etc.) interpret and execute PPOs. ERC-20 transferFrom()

—-

The goal is to make permissioned-pull a native capability inside the account abstraction stack, not an external payment app; aligning with ERC-4337, ERC-6900, and ERC-7579 so wallets can treat “consented flow” as a first-class operation.

Implementation references

  • Contract: RecurPullSafeV2.sol
  • Registry: RecurConsentRegistry.sol
  • Cross-Network Mirror: PullMirrorV3.observeAndVerify()
  • Demo: Successful on Sepolia + Base Sepolia, Oct 31 – Nov 1 2025
    • Core insight: “Consent, not custody, is the root primitive for cross-network value. Liquidity becomes statelessly attachable.”

—-

Feedback welcome

Before formalizing ERC-A and ERC-B, I’d love peer review on:

  1. Struct field layout and naming consistency with existing ERCs (esp. 2612, 4337).
  2. Recommended security model for cross-network attestation (Merkle proof vs. signature-only).
  3. Any prior art or overlaps worth referencing in the ERC drafts.
3

Follow-up verification note

The cross-network demo used an internal prototype of PullMirrorV3.observeAndVerify() that verifies the same EIP-712 digest on the destination chain.

The contract hasn’t been published yet; I’ll release a minimized version once the ERC-A / ERC-B drafts are finalized so reviewers can reproduce the flow.

For anyone wanting to verify the hashes from the demo:

chainId (Sepolia): 11155111
chainId (Base Sepolia): 84532
AUTH_TYPEHASH  = 0x93c66a08da40a7ae602ecf25c64e31553efb281773a258d11616988f8619b956
structHash     = 0x0197dfa646216beddb9b3d2c6a2f6151bc7424a8ece75c853b48ea9f0095b396
authHash       = 0x3ed08d1d3735db3e432c83497f29537bdd04dc83373675d0f826036fa4817ccf
domainSeparator= 0x43a35c311d91ebc05929a3d8d3d64ce5ab5100f03890766dd93e4726a39dee761

Demo window: Oct 31 – Nov 1 2025 (Sepolia ↔ Base Sepolia).

4

Update:

ERC-A and ERC-B reference implementations are now live on GitHub.

The repository includes specs, contracts, and Foundry tests verifying dual-path revocation (local cancel + registry).

Frozen draft release: https://github.com/recurmj/permissioned-pull-standard/releases/tag/v1-draft

Feedback welcome before formal ERC submission.