ERC-8187: Token Puller Interface

gnarvaja · March 4, 2026, 12:54pm

Hey everyone,

Guillo Narvaja here (@gnarvaja on X), co-founder & CTO at Ensuro. This is my first ERC proposal — excited (and a little nervous) to share it and learn from the community.

I’ve drafted a standard called the Token Puller Interface whose main goal is to let payments, subscriptions, and other spending flows happen directly from invested or yield-generating positions — without forcing the spender to know or care how/where the tokens are actually coming from.

The core idea is simple:

An owner pre-approves a Puller (a contract or even the smart account itself) to source tokens on-demand (withdraw from Aave, redeem vault shares, borrow against collateral, cascade to another puller, etc.)
A spender (payment app, merchant processor, guardian service, etc.) just requests a pull of a certain amount and token
The Puller handles the sourcing atomically and transfers the tokens — the spender never sees the complexity

The spending approval can be given on-chain by calling approvePull (very similar to ERC-20 approve) or off-chain via a gasless EIP-712 signed permit (in the same spirit as ERC-2612).

This decouples spending logic (simple, fast, payment-focused) from asset management (yield optimization, risk strategies, liquidity management). Users don’t need to keep large liquid balances sitting idle, and spenders don’t need custom integration for every yield protocol.

Key features:

On-chain approvals + gasless EIP-712 permits (ERC-6492 compatible)
Allowance delegation (e.g. guardian refills sub-allowances for daily/merchant limits)
Atomic permit + pull for one-off payments
maxPullable(token, owner, upTo) view to safely query available capacity (with short-circuit optimization for cascaded sourcing)

Full draft here:

github.com/gnarvaja/ERCs

ERCS/erc-xxxx.md

master

---
eip: TBD
title: Token Puller Interface
description: Standardized interface for permissioned, on-demand token pulls with custom sourcing logic, permit support, and allowance delegation
author: Guillermo Narvaja (@gnarvaja)
discussions-to: https://ethereum-magicians.org/t/draft-erc-token-puller-interface-spending-without-liquid-balances/27896
status: Draft
type: Standards Track
category: ERC
created: 2026-02-27
requires: 20, 2612, 6492, 712, 5267
---

## Abstract

This ERC proposes a standardized interface for "Puller" contracts that enable approved spenders to initiate token transfers from an owner's account without requiring the owner to maintain liquid balances. The Puller handles custom logic for sourcing tokens (e.g., withdrawing from lending protocols like Aave, liquidating positions, or other operations) and executes the transfer to a specified destination.

The interface supports:

-   On-chain approvals with limits

This file has been truncated. show original

Specific questions I’d love early thoughts on:

Does the decoupled sourcing + spending angle feel novel/useful enough, or is there too much overlap with existing permit/pull patterns?
Is the allowance transfer feature (transferPullAllowance) valuable for guardian/refill patterns, or does it introduce unnecessary risk/complexity?
maxPullable with the upTo param — helpful for efficiency, or should it be simpler (no upTo)?
Smart-account native implementation (owner == address(this)) — realistic for modular wallets? Any guidance needed?
Naming, events, parameter ordering — anything that feels off or inconsistent?

Thanks so much for any time / feedback you can spare.
Really appreciate the chance to contribute to Ethereum standards.

Best,
Guillo Narvaja
@gnarvaja

Amxx · March 4, 2026, 1:49pm

Quick comment, I think the DOMAIN_SEPARATOR function is a mistake. It is part of ERC-2612, but since then, way better options have been designed.

IMO, it should be dropped in favor of ERC-5267.

Also note that if ERC-2612 is a dependency of this, then all the ERC-2612 functions are already included by default, and documented in ERC-2612. This means this ERC should NOT document nonces and DOMAIN_SEPARATOR.

gnarvaja · March 4, 2026, 2:41pm

Thanks for the feedback. I will remove documentation of nonces and DOMAIN_SEPARATOR functions, add 5267 as a dependency, and I would mention the interface MUST follow ERC-5267 with respect to the EIP-712 domain.

gnarvaja · March 4, 2026, 3:19pm

Quick follow-up with a concrete use-case example:

Imagine Uber (or any ride-hailing / delivery app) wants to accept crypto payments natively — no Visa/Mastercard rails, no custodial “crypto wallet” they have to build or manage.

User flow:

In the Uber app → “Add Payment Method”
User selects chain + their address + the Puller contract address (e.g. AAVEPuller on Ethereum)
User pastes their usual hardware wallet address (or Safe, or any smart account), e.g. guillo.eth
On their hardware wallet / signer, the user calls:
AAVEPuller.approvePull(USDC, spender.uber.eth, 200 USDC)

Done.

Now every time the user takes a ride:

Uber (spender.uber.eth) calls AAVEPuller.pullFrom(USDC, guillo.eth, treasury.uber.eth, rideAmount)
The Puller automatically withdraws the needed USDC from Aave (assuming the user has pre-approved the Puller on Aave)
Funds go straight to Uber’s treasury

No liquid USDC sitting in the user’s wallet, no manual withdrawals, no repeated signatures per ride.

Bonus: the ERC also supports allowance delegation/transfer, so a guardian service could automatically refill that 200 USDC daily/weekly limit for the Uber spender address (e.g. transferPullAllowance from a larger “budget” allowance). This gives credit-card-like daily caps without the user having to micromanage.

Of course the standard is generic — it could work for subscriptions (Netflix-style), recurring SaaS payments, DAO expense reimbursements, or any flow where you want to spend from invested positions without exposing the yield strategy to the receiver.

I tried to keep the ERC as minimal and familiar as possible while still enabling these kinds of flows. Would love to hear if this kind of example resonates or if there are even better real-world cases I should highlight.

Thanks again for any thoughts!

Amxx · March 4, 2026, 5:17pm

Very quick thing (I may be missing context): Is there any reason to have a dedicated pull allowance versus using the existing ERC20 allowance.

You can already “approve” and “transferFrom”. Maybe you should “just add” a transferAllowance function.

gnarvaja · March 4, 2026, 6:46pm

The problem is ERC20 only works when funds are liquid. And we are trying to give a spending experience that doesn’t require to have the funds liquid, but instead pulling them on-demand.

Or you mean using ERC20 allowance, but with a custom sourcing logic? In that case, the puller will check token.allowance(owner, spender) before executing the sourcing logic. Then pull the funds and leave them liquid on owner’s account, hoping that in a subsequent call, the spender will call token.transferFrom(owner, to, amount) .

This design would have several problems:

It would require, anyway, that the spender knows the existence of the puller contract.
You won’t be able to allow a particular allowance to a particular pulling strategy, or even differentiate normal ERC20 allowances from pulling allowances.
You can’t spend the allowance, and you can’t control whether the spender calls or not token.transferFrom

gnarvaja · March 10, 2026, 11:41am

PR created: Add ERC: Token Puller by gnarvaja · Pull Request #1587 · ethereum/ERCs · GitHub