Push Mechanism

In a push mechanism, the transaction flow originates from the sender's wallet. The sender must actively sign and broadcast the transaction to the network, paying the associated gas fee. This is the default model for standard token transfers (e.g., sending ETH) and most smart contract interactions.

• Example: Alice sends 1 ETH to Bob. She signs the transaction, pays the gas, and pushes it to the mempool.

The entity initiating the push transaction is responsible for the gas costs. This creates a clear cost structure but can be a barrier for user onboarding, as users must hold the native token (e.g., ETH, MATIC) to pay for transactions. This is a key differentiator from meta-transactions or gasless transactions, which use relayers or sponsors.

Push transactions are executed synchronously and deterministically. Once broadcast and included in a block, the state change is immediate and final (barring a chain reorganization). This provides certainty for the sender but requires them to be online and active at the time of the transaction.

Push is often contrasted with pull mechanisms, where the recipient or a third party initiates the final settlement. Key differences:

• Push: 'I send you funds.' Sender pays gas, controls timing.
• Pull: 'You claim the funds I allocated.' Claimant pays gas, controls timing. Pull patterns are common in vesting schedules, airdrops, and commit-reveal schemes.

Push is the dominant model for direct user interactions.

• Simple Transfers: Sending native tokens or ERC-20 tokens.
• Smart Contract Interactions: Calling a function on a DeFi protocol like Uniswap to swap tokens.
• NFT Minting: A user submits a transaction to mint an NFT from a collection.
• Governance Voting: Submitting an on-chain vote by signing and pushing a transaction.

Pure push mechanisms have limitations, leading to hybrid models:

• User Onboarding: Requiring gas upfront hinders new users.
• Batch Operations: Inefficient for paying many recipients.

Solutions include gas relayers (ERC-2771), sponsored transactions, and account abstraction (ERC-4337), which decouple the fee payer from the transaction signer, blending push intent with pull-like execution.

Cross-chain bridges and messaging layers (e.g., LayerZero, Axelar) rely on push mechanisms. A relayer or validator set on the source chain detects an event, then pushes a message and proof to a destination chain's messaging contract, initiating the execution of a cross-chain transaction or state update.

Wallets and portfolio trackers use push APIs to monitor addresses. Services subscribe to blockchain events and push updates to the user interface for:

• Incoming/outgoing transaction confirmations.
• NFT transfers and approvals.
• Token balance changes. This creates a seamless user experience without manual refreshing.

It is defined by its opposition to pull mechanisms (client-initiated requests). Key differences:

• Push: Server/emitter initiates (e.g., block propagation, oracle update). Lower latency for subscribers.
• Pull: Client/requester initiates (e.g., querying an RPC for balance). Higher control and simplicity for infrequent data. Most robust systems use a hybrid model, combining push for real-time updates with pull for state verification.

A push mechanism can be exploited to overwhelm a subscriber's endpoint. Malicious or misconfigured data sources can send a high volume of updates, exhausting the subscriber's computational resources, bandwidth, or rate-limited API quotas. This differs from a pull model, where the subscriber controls the request rate.

• Example: A price oracle pushing thousands of updates per second to a smart contract, causing it to exceed gas limits and fail.

Subscribers must cryptographically verify the authenticity and integrity of pushed data. Without proper signatures, a man-in-the-middle attacker could intercept and alter the payload. Reliance on a single, unverified push source creates a central point of failure.

• Critical for: Oracle networks, cross-chain messaging protocols, and any system where data triggers on-chain state changes.

Network conditions can cause out-of-order delivery or message duplication. A subscriber must have logic to handle these cases, such as using sequence numbers or idempotent operations, to prevent state corruption.

• Reliability Impact: A duplicated 'transfer' message could cause double-spending if not properly deduplicated by the receiving application.

The subscriber's endpoint must be continuously online and operational to receive pushes. If it goes offline, critical updates are missed without a retry mechanism or persistent queue. This contrasts with pull systems, where data can be fetched upon coming back online.

• Mitigation: Implementing acknowledgment receipts and dead-letter queues for failed deliveries.

Many push systems rely on a centralized relayer or message bus to route data. This introduces a trust assumption and a single point of failure. If the relayer is compromised or goes offline, the entire data delivery network halts.

• Decentralized Alternatives: Protocols like The Graph (indexing) or peer-to-peer pub/sub networks aim to mitigate this risk.

Pushing data to a smart contract requires the pusher to pay gas fees. This creates economic constraints and potential censorship if the pusher refuses to submit data. It also requires the pusher to hold the chain's native token, adding operational complexity.

• Example: A keeper bot must hold ETH to push a liquidation transaction to Ethereum, creating a capital requirement and execution risk.

The standard blockchain interaction model where a user must initiate and pay for a transaction to retrieve data or claim assets. This is the opposite of a push.

• Examples: Manually claiming staking rewards, withdrawing funds from a pool, or calling a smart contract function.
• Gas Burden: The user (the "puller") bears the transaction cost and must be active.

A method that allows a third party (a relayer) to pay the gas fees for a user's transaction. It enables push-like functionality by abstracting gas costs.

• Key Component: Uses a signed message from the user, which the relayer submits on-chain.
• Use Case: Allows dApps to sponsor user onboarding or specific actions, pushing the gas cost burden away from the end-user.

A user experience where the end-user does not pay network gas fees directly. This is often achieved via meta-transactions or account abstraction.

• Implementation: Can be powered by relay networks or paymasters that batch and sponsor transactions.
• Relation to Push: A core enabler for true push mechanisms, as it removes the requirement for the recipient to hold native tokens for gas.

A standard allowing smart contract wallets to define custom logic for transaction validation and fee payment. It fundamentally enables push mechanics.

• Paymasters: Contracts that can sponsor gas fees for users, allowing dApps to push transactions.
• UserOps: Bundled user operations that can be relayed, enabling complex, gas-abstracted flows initiated by any party.

A service that pushes external, real-world data onto the blockchain for smart contracts to consume. This is a canonical example of a data push mechanism.

• Function: Listens to off-chain events and submits verified data (e.g., price feeds) in an on-chain transaction.
• Push vs. Pull: Oracles push data at intervals or upon triggers, whereas contracts could theoretically pull data, which is less efficient and reliable.

Protocols that push messages or state information from one blockchain to another. This is a push mechanism operating across sovereign networks.

• Examples: LayerZero's Ultra Light Node or Chainlink's CCIP deliver messages from source to destination chain.
• Mechanism: A relayer or oracle network observes an event on Chain A and initiates a transaction to prove it on Chain B.