Pufferfinance Consensus Reward Claims And Base Payouts
Pufferfinance node operators claim consensus layer rewards as pufETH on Base after weekly accounting and a mandatory waiting period. Only rewards successfully withdrawn from validators enter this payout process. Claiming requires a Base-compatible wallet and ETH on Base for transaction gas, with additional setup for smart-contract registrations.
In this guide
Node operators registered through smart contracts need a configured Base rewards recipient before collecting their consensus reward payouts in pufETH.
Where Are Pufferfinance Consensus Rewards Claimed?
Consensus reward claims take place on Base through the Puffer Dashboard after the mandatory waiting period ends for a batch that remains available. The payout arrives as pufETH, Puffer's reward-bearing token representing an interest in its staking vault. Ethereum remains the network where the validator earns consensus rewards.
From Validator Withdrawals to Reward Allocations
Successfully withdrawn consensus rewards supply the amounts Guardians use when preparing allocations for node operators. Accrued validator earnings alone do not establish the amount available for a Base claim. Consensus rewards pass through EigenLayer contracts, which can introduce a delay before the accounting process handles them. That delay concerns withdrawing the underlying rewards from the validator and precedes their inclusion in the Base payout.
Guardians calculate rewards for the accounting interval, incorporate prior reward totals and publish a Merkle tree of allocations before minting pufETH and transferring the reward tokens to Base through the distribution infrastructure. LayerZero's pufETH bridge transfers new reward tokens to Base. The former Connext/Everclear route is deprecated. The allocation tree and the transferred tokens serve different purposes: the tree records calculated amounts for claimants, while the tokens provide the asset available for distribution.
L2RewardManager handles the Base claims after the security wait; publishing an allocation does not make the claim immediately available.
When Do Consensus Rewards Become Claimable on Base?
A reward batch becomes claimable after it reaches Base and its mandatory security waiting period ends, unless it has been frozen or reverted. Accounting runs weekly on Monday, and the period can change. That schedule describes when the system prepares allocations. It does not promise an immediately spendable balance every Monday. Rewards must first have left the validator through the relevant withdrawal process. Their inclusion then depends on the accounting cutoff and the subsequent security wait.
Current Rewards Epoch identifies the cutoff through which rewards have been calculated and posted to Base. Use that cutoff when comparing withdrawals with the allocation. An operator can have an allocation posted to Base while the mandatory waiting period continues, so the Current Rewards Epoch alone does not establish when a claim transaction can succeed.
Matching ETH Rewards to the pufETH Allocation
Current Rewards Epoch identifies the latest posted cutoff. For each unclaimed accounting interval, total the successfully withdrawn consensus rewards from all associated validators within that interval's epoch range. Convert each interval's ETH total using its recorded payout conversion rate. L2RewardManager stores this rate as pufETH per ETH, so multiplying the ETH total by the rate gives the corresponding token amount. Substituting a later rate can change the converted amount. Comparing quantities in matching units prevents an exchange-rate difference from appearing to be a missing payment.
Base Claimer Authorization
Node operators who registered validators through a smart contract must configure a rewards claimer address on Base.
A multisig or other contract account registered on Ethereum Mainnet does not automatically provide a usable claim account at the same address on Base. The address must belong to an account the operator controls on Base. L1RewardManager accepts the recipient-setting call on Ethereum Mainnet through
setL2RewardClaimer
, which identifies the account designated to receive the operator's consensus rewards.
The Mainnet contract used for registration must make this call and attach ETH for the cross-chain relayer fee. For a Safe registration, use that Safe's Transaction Builder with the L1RewardManager proxy's implementation ABI. Cross-chain delivery carries the recipient setting to Base. That delivery is separate from the eventual reward claim, and the Base recipient setting takes effect once the update is processed there. A Mainnet transaction therefore does not establish that the setting has already taken effect on Base.
Base Claim Readiness
The Base claim is ready only when the reward allocation is available and the submitting account can fund the transaction. A recorded reward amount and a wallet capable of collecting it are separate requirements. A batch can be accounted for while the wait continues, and a contract-registered operator can have rewards assigned before completing Base recipient configuration.
- Confirm the relevant allocation has been calculated and posted to Base.
- Confirm the batch's mandatory waiting period has ended.
- Identify the account designated to receive the operator's rewards on Base.
- Ensure the wallet can connect to Base.
- Keep ETH on Base available for the claim transaction's gas.
The dashboard flow begins with Claim, followed by switching the wallet network to Base. Choose Claim again, review the transaction details, then sign and submit the transaction on Base. Signing authorizes the claim transaction, which must then confirm on Base.
The confirmed claim delivers pufETH to the operator's designated recipient account on Base.
Base Gas and Onward Asset Choices
Claiming on Base requires ETH on Base for gas, regardless of the reward payout's pufETH denomination. An Ethereum Mainnet ETH balance does not itself pay a Base claim fee. After claiming, the operator can retain and use the rewards on Base. Bridging them to Ethereum L1 requires a route supporting the exact token received. Bridging pufETH moves the token between networks. It does not by itself convert the token into ETH or WETH. An onward bridge introduces separate transaction requirements beyond the original claim.
Consensus Claims Within the Validator Reward System
Execution layer rewards follow the validator's configured
fee_recipient
address and remain separate from the Base consensus reward allocation. The validator earns both streams through Ethereum validation, but each stream has its own delivery mechanism. Identify the reward stream before comparing a wallet transfer with a consensus allocation.
The validator ticket model gives node operators their validators' proof of stake (PoS) rewards for the operating period those tickets cover. Native restaking adds another reward category through Puffer modules and actively validated services. The module's distribution terms determine restaking operator fees and node operator commissions, with the remainder supporting the protocol's pufETH backing.
What to know about Pufferfinance
Do EOA Registrations Need a Separately Configured Base Claimer?
EOA registrations default to the same node operator address on Base without a separate claimer-setting step. An externally owned account, or EOA, is an account controlled by a signing key. The exception applies to EOA registrations; multisig and other smart-contract registrations require a separately configured Base rewards claimer.
Are Consensus Rewards Calculated Separately for Every Validator an Operator Runs?
Weekly accounting calculates each node operator's allocation by summing rewards across associated validators. A withdrawal total for one validator covers only that validator's contribution to the operator's allocation. All associated validators belong in the reconciliation, and only successfully withdrawn consensus rewards qualify for the Base distribution.
Which Reward Period Did the First Base Distribution Cover?
The first distribution included rewards accumulated since Puffer's mainnet launch. Later distributions follow weekly accounting intervals. Only successfully withdrawn validator rewards enter the pufETH payout calculation.
Which Cutoff Does Next Rewards Epoch Represent?
Next Rewards Epoch identifies the cutoff through which rewards will be calculated in the upcoming accounting event. It differs from Current Rewards Epoch, which covers rewards already calculated and posted to Base. The next epoch is an accounting target rather than confirmation of an available claim. The mandatory waiting period still controls when a posted batch can be claimed.
Why Must a Published Reward Batch Wait Before Claims Open?
The mandatory waiting period leaves time to revert the distribution if a security vulnerability arises. L2RewardManager claims follow only after that wait ends. This interval concerns the prepared reward distribution; it is separate from the delay consensus rewards can experience before leaving a validator through EigenLayer.
Is Excess ETH Refunded When a Multisig Pays for a Base Claimer Update?
Excess ETH attached for the recipient-update relayer fee is refunded to the caller. The ETH value accompanies the L1RewardManager call changing the Base claimer and pays for cross-chain delivery. This payment is separate from the ETH needed on Base when claiming rewards.
Does Claiming Consensus Rewards Return the Validator Bond?
A consensus reward claim does not return the validator bond. The node operator receives the full bond if the validator exits unslashed with at least 32 ETH. An unslashed exit below 32 ETH reduces the bond by the shortfall; slashing forfeits the whole bond. These exit conditions govern collateral repayment separately from the Base consensus payout.
Updated on