Pull Transfer

Unlike a push transaction where the sender initiates and authorizes payment, a pull transfer requires the recipient to initiate the transfer. The payer must first grant authorization (e.g., via an allowance in ERC-20) to a specific recipient or smart contract. This decouples the payment trigger from the payer's direct action, enabling subscriptions, batch payments, and gasless transactions for users.

Authorization is not a one-time signature but a persistent, on-chain state change. For ERC-20 tokens, this is typically an allowance stored in the token contract's internal mapping (mapping(address => mapping(address => uint256))). This record defines the maximum amount a spender can withdraw from the owner's balance, creating a verifiable and auditable permission layer.

The defining action: the authorized recipient (or their smart contract) calls the function to execute the transfer. In the ERC-20 standard, this is the transferFrom(from, to, value) function. This shifts gas fee responsibility and transaction timing to the recipient, a key enabler for meta-transactions and relayer networks where users don't need native crypto to pay fees.

Pull transfers provide granular security by limiting exposure. Users approve specific amounts for specific contracts, rather than granting blanket access to their wallet. This contains risk if a spender contract is compromised. Best practices include:

• Using minimal, time-bound allowances.
• Revoking unused approvals.
• Interacting only with audited, well-known protocols.

By separating initiation from authorization, pull transfers allow smart contracts to implement sophisticated payment logic. Examples include:

• DEX Swaps: A user approves a router to pull tokens, which are then swapped.
• Loan Repayments: A lending contract pulls owed tokens upon liquidation.
• Streaming Payments: A streaming contract pulls tokens per second from a grant. This makes them foundational for DeFi and Web3 applications.

Pull transfers enable significant gas efficiency. A single on-chain authorization can support countless future transfers without further payer interaction. Furthermore, recipients can batch many pull operations into a single transaction, amortizing gas costs. This is critical for scalability in applications like airdrops, payroll, and protocol revenue distribution, where servicing many users is cost-prohibitive with push models.

Protocols use pull transfers to collect fees or rewards owed by users on-demand, optimizing gas efficiency. Instead of pushing fees for every transaction, the protocol aggregates obligations and lets users or keepers settle them in a single batch pull.

• Example: A DEX pulls accumulated swap fees from a liquidity provider's position only when they add/remove liquidity or claim rewards, reducing overall transaction costs.

Allows a third-party relayer to pay the transaction gas fees on behalf of a user. The user signs a message permitting an action, and the relayer submits it, later pulling reimbursement for the gas costs from the user's account in the native token or ERC-20.

• Example: A dApp pays the gas for a new user's first transaction, creating a seamless onboarding experience, and later pulls the equivalent amount of ETH from the user's wallet.

In escrow services, funds are held by a smart contract. The release to the seller is a pull transfer initiated by the seller upon the buyer's confirmation of delivery. If disputed, an arbitrator can initiate the pull to either party.

• Example: In a P2P NFT trade, the buyer locks funds in escrow. Only after confirming receipt of the NFT can the seller execute the pull function to withdraw the funds.

Aggregates multiple obligations into a single transaction to save gas. A contract accumulates state changes (like rewards or fees) off-chain, and a final settlement transaction pulls the net amount due.

• Key Mechanism: Uses signed approvals (like EIP-2612 permits) to authorize the pull without separate on-chain approval transactions, significantly reducing gas overhead for users.

The core risk is granting excessive or infinite approval to a spender contract. Attackers can exploit this to drain funds. Key vulnerabilities include:

• Infinite approvals: Granting type(uint256).max is convenient but dangerous if the spender is compromised.
• Approval front-running: A malicious actor can intercept and modify an approval transaction before it's mined.
• Replay attacks: Using old, signed approvals after a contract upgrade or state change.

Pull transfers often rely on off-chain signatures (EIP-712, EIP-2612). Security depends entirely on the user verifying the signed message. Risks include:

• Malicious dApp interfaces: A fake UI can trick users into signing a transfer for a different amount or recipient.
• Signature replay: A signature intended for one network (e.g., testnet) could be replayed on mainnet if domain separation (EIP-712 domain) is incorrect.
• Malleable signatures: Poor signature verification logic can allow altered but still valid signatures.

The security of the spender contract (the pull recipient) is critical. If compromised, all approved funds are at risk. Considerations:

• Upgradable contracts: A malicious upgrade can turn a trusted spender into a drainer.
• Logic bugs: Flaws in the spender's transferFrom logic can lead to unauthorized pulls.
• Centralization risk: Spender contracts with admin keys pose a single point of failure. Always audit the spender.

The pull mechanism changes transaction gas dynamics and can enable reentrancy.

• Gas griefing: A malicious spender could perform expensive operations in its transferFrom callback, causing the pull to fail for the user but still costing gas.
• Reentrancy attacks: If the spender contract calls back into the token contract during transferFrom, it can exploit state inconsistencies (like the classic DAO attack). Use the Checks-Effects-Interactions pattern.

Users must adopt specific security habits for pull-based systems:

• Principle of Least Privilege: Grant approvals for the exact amount needed, for a limited time. Avoid infinite approvals.
• Verify Signatures: Use wallet explorers to inspect the full details of any EIP-712 signature before signing.
• Regularly Revoke: Use tools like Etherscan's Token Approval checker to find and revoke unused approvals.
• Contract Trust: Only approve well-audited, non-upgradable (or timelocked) spender contracts.

Developers implementing pull transfers must build secure patterns:

• Implement increaseAllowance/decreaseAllowance: Safer than approve to prevent front-running.
• Use EIP-712 with Domain Separators: Prevent cross-chain and cross-contract signature replay.
• Include deadline parameters: Make signed approvals expire.
• Event Emission: Emit detailed approval and transfer events for off-chain monitoring.
• SafeERC20: Use OpenZeppelin's library for safe interactions with non-compliant tokens.

The traditional payment model where the sender initiates and pushes funds to a recipient, requiring them to have the full amount and gas fees at the time of transaction. This contrasts with a pull transfer, where the recipient initiates the withdrawal.

• Example: Sending ETH via a standard wallet transfer.
• Key Difference: Push is sender-driven; pull is receiver-driven.

Token standards that form the foundation for pull mechanics. ERC-20's transferFrom function is the original primitive enabling delegated transfers, which pull systems abstract.

ERC-777 introduced explicit operator permissions and send/receive hooks, providing a more sophisticated framework for pull-based interactions and reducing the risk of front-running seen in ERC-20's dual-approve/transferFrom pattern.

A standard for gasless token approvals via off-chain signatures. It allows a user to sign a permission (a permit) for a spender to pull tokens, which is then submitted by a third party.

• Core Function: permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s)
• Use Case: Essential for improving UX in DeFi by batching the approval and transfer steps into one transaction, often used with pull systems.

A standard enabling smart contract wallets. It fundamentally changes transaction flow by introducing UserOperations and a bundler network.

• Relevance to Pull: Enables sophisticated pull logic (e.g., recurring subscriptions, batch withdrawals) to be managed at the wallet level. The wallet itself can act as a secure, programmable endpoint for pull requests, validating complex conditions before execution.

A continuous flow of value over time (e.g., salaries, subscriptions). While often implemented via recurring push transactions, the pull model is more efficient.

• Pull-Based Streaming: The recipient's wallet periodically pulls accrued funds from a shared contract (e.g., Sablier, Superfluid).
• Advantage: Reduces gas costs and transaction count compared to scheduled pushes, as funds are only moved when needed.

A security pattern where a user grants a time-bound or capacity-limited permission for another address to pull funds, which can be revoked at any time.

• Implementation: Often uses an allowance model (like ERC-20) or a signed authorization with an expiry.
• Critical For: Subscription services, payroll systems, and any pull transfer scenario where maintaining user control over exposure is paramount.