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 or borrowing from lending protocols, liquidating positions, or other operations) and executes the transfer to a specified destination.
The interface supports:
This enables use cases such as recurring payments, subscriptions, automated settlements, guardian-managed limits, and credit-card-like spending controls in DeFi and payment applications, while improving security and yield optimization.
Current token approval standards (ERC-20 approve/transferFrom, ERC-2612 permits) require owners to hold liquid balances and often involve multiple transactions or direct balance pulls. This creates friction and risks:
The Token Puller Interface addresses these by introducing an intermediary Puller contract that:
The core motivation behind this ERC is to cleanly decouple spending logic from asset management strategies. By introducing a Puller contract (or, in the smart-account case, the account itself), the act of sourcing tokens — whether from a lending position, a vault, a swap, or simply an internal balance — becomes an implementation detail hidden from the spender. The spender only requests a pull for a certain amount and token; it never needs to know or interact with how those tokens are actually obtained. This atomic sourcing + transfer pattern reduces complexity on the payment or spending side while letting users keep their funds invested until the moment they are needed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
The following terms are used with these specific meanings in this specification:
Puller — The smart contract that implements the IPuller interface. It acts as the intermediary responsible for:
Token — An ERC-20 compliant fungible token contract whose tokens can be pulled through this interface. The Puller MUST be able to ultimately transfer such tokens to the destination address after sourcing them.
Owner — The address (EOA or smart contract account) that:
approvePull or permitPull),pullFrom or pullFromWithPermit call.Spender — An address (EOA, smart contract, or relayer) that has been granted a pull allowance by an owner (via on-chain approval or signed permit) and is authorized to call pullFrom, pullFromWithPermit, or transferPullAllowance to initiate token movements or delegate portions of its allowance.
Additional terms that appear frequently and benefit from clear definition:
Pull Allowance (or simply Allowance) — The maximum cumulative amount of a specific token that a given spender is permitted to pull from a given owner via the Puller, as tracked by pullAllowance(token, owner, spender). This value can be finite or infinite (type(uint256).max).
Sourcing Logic — The implementation-specific mechanism executed by the Puller during a successful pullFrom or pullFromWithPermit call to make tokens available for transfer. Examples include withdrawing from lending protocols, redeeming vault shares, unwrapping tokens, or performing swaps. The exact logic is outside the scope of this ERC and is defined by each Puller implementation.
Permit — An off-chain EIP-712 signed message (following the PullPermit struct) that authorizes setting or updating a pull allowance without requiring an on-chain approvePull transaction from the owner.
approvePullSets or updates the pull allowance of spender for token from msg.sender (the owner).
limit to 0 revokes the spender's permission to pull that token.(token, owner, spender) with the new limit.PullApproval event.pullFromPulls amount of token from owner and transfers it to to, after executing the Puller's implementation-specific sourcing logic.
msg.sender has sufficient allowance: pullAllowance(token, owner, msg.sender) >= amount.msg.sender == owner, the Puller MAY ignore the allowance check. In that case, the Puller just abstracts away the sourcing logic.type(uint256).max, MUST decrease the allowance by amount.type(uint256).max (infinite approval).amount of token to to.TokensPulled event on success.transferPullAllowanceTransfers amount of pull allowance from msg.sender (the current spender) to toSpender for the (token, owner) pair.
pullAllowance(token, owner, msg.sender) >= amount.amount == type(uint256).max and current allowance == type(uint256).max:
msg.sender's allowance to 0toSpender's allowance to type(uint256).maxmsg.sender's allowance by amount (unless infinite)toSpender's allowance by amount (unless toSpender == address(0))toSpender == address(0) as a mechanism to renounce allowance (decrease only, no increase).toSpender == msg.sender (self-transfer is a no-op and should be prevented).TransferPullAllowance event on success.pullAllowanceReturns the units of token that spender is allowed to pull from owner.
maxPullableReturns the max amount that can be pulled of a given token from a given owner. The upTo parameter allows early
termination if that amount is reached.
upTo.owner by a given spender can be computed with maxPullable(token, owner, pullAllowance(token, owner, spender)).permitPullApproves or updates a pull allowance using an off-chain EIP-712 signature.
PullPermit struct:
token, owner, spender, limit, nonce = nonces(owner), deadlinePullPermit typehash:
DOMAIN_SEPARATOR is defined according to EIP-712. The DOMAIN_SEPARATOR should be unique to the contract and chain to prevent replay attacks from other domains,
and satisfy the requirements of EIP-712, but is otherwise unconstrained.ecrecover, ERC-1271 contracts, pre-deploy via magic suffix).block.timestamp > deadline, signature is invalid, or nonce does not match.nonces(owner)pullAllowance(token, owner, spender) to limit (overwriting previous value)PullApproval(token, owner, spender, limit)pullFromWithPermitAtomically applies a permit (with limit == amount) and executes a pull in a single transaction.
PullPermit where limit == amount and spender == msg.sender.permitPull(token, owner, msg.sender, amount, deadline, signature), but it SHOULD NOT revert if
this call fails, to avoid a front-run DoS attack.amountpullFrom(token, owner, to, amount)PullApproval followed by TokensPulled; otherwise MUST emit only TokensPulledImplementations SHOULD expose the domain via ERC-5267.
Implementations MUST expose nonces(owner) as described in ERC-2612.
PullApprovalEmitted when an owner approves or updates a spender's pull allowance for a given token.
approvePull is successfully called.permitPull successfully sets or overwrites an allowance.transferPullAllowance.TokensPulledEmitted when tokens are successfully pulled from an owner and transferred to the destination.
pullFrom or pullFromWithPermit call.amount parameter MUST reflect the exact amount transferred to to.TransferPullAllowanceEmitted when a spender transfers part or all of their pull allowance to another spender (or renounces it by transferring to address(0)).
transferPullAllowance call.toSpender == address(0)), the event MUST still be emitted with toSpender = address(0).Gasless approvals via signed permits and the ability to transfer allowances between spenders were added specifically to support credit-card-like experiences and delegated spending flows. For example, a user might grant a large or infinite allowance to a trusted "guardian" service that enforces daily/monthly limits and automatically refills sub-allowances for individual spenders (e.g., a payment app or merchant processor). These features make recurring or delegated payments more practical without requiring the owner to sign every transaction or maintain liquid balances.
The interface deliberately mirrors familiar ERC-20 patterns (approve / allowance / transferFrom) and builds on established extensions like ERC-2612 (Permit) to minimize the learning curve and avoid unnecessary naming collisions. Where possible, function names, event structures, and parameter ordering stay close to precedents so developers and tools can adopt the standard quickly.
The maxPullable function provides a standardized way to query available pull capacity (similar to balanceOf for direct holdings or maxWithdraw in ERC-4626), independent of spender allowances. The upTo parameter allows efficient checks in cascaded sourcing implementations without forcing full strategy evaluation every time.
Finally, the design is intentionally compatible with both EOAs and smart accounts, while leaning into the current direction of account abstraction (ERC-4337 and others). A particularly powerful pattern is for a smart account to implement the IPuller interface directly on itself. In that case owner == address(this), the account already controls its own funds (and any pre-approved external positions), and there is no need to grant approvals or trust an external Puller contract. This reduces deployment overhead, eliminates an extra approval step, and allows the pull logic to participate in batched user operations — a natural fit for modular wallets that already expose custom execution and spending-limit interfaces.
A reference implementation is provided, with a commented interface and an educational example implementation of a Puller that pulls funds by withdrawing them from a vault.
This example has not been audited and should not be used in production environments.
See contracts
External calls during sourcing (e.g. withdrawals, redemptions, swaps) can open reentrancy vectors. Implementations must follow checks-effects-interactions and protect against recursive calls.
Allowance transfer enables refill patterns (guardian refilling sub-allowances), but a compromised spender can redirect its allowance to arbitrary addresses. The same trade-offs between infinite and finite allowances that apply to ERC-20 also apply here: infinite approvals improve user experience but increase damage potential if the spender is compromised.
Custom sourcing logic can depend on external protocols that are subject to oracle manipulation, failed withdrawals, slippage, or protocol-specific exploits. Implementations should apply appropriate output guards where the logic allows it.
Permit signatures depend on correct validation of EIP-712 digests, nonces, deadlines, and ERC-6492 rules (EOA recovery, ERC-1271 contracts, pre-deploy detection). Errors in any of these steps can lead to unauthorized approvals.
Fee-on-transfer and rebasing tokens may behave unexpectedly during sourcing and transfer. Implementations should test with such tokens and consider before/after balance checks when necessary.
When the Puller interface is implemented directly on a smart account (owner == address(this)), any bug in the Puller code affects the entire account. Modular designs that isolate the logic are preferable.
Production implementations should be audited with special attention to the sourcing paths, signature validation, and allowance transfer logic.
Copyright and related rights waived via CC0.