Can Several Validators Share One Node Operator's Deposited VT Balance?

PufferProtocol records one deposited VT balance for each node operator. Validators registered by that operator use the shared balance for ticket accounting. Each validator registration must add at least the configured ticket minimum. Coverage must reflect the validators' aggregate operating time. Wallet-held VTs remain separate until someone deposits them for that operator.

Why Can Validator Registration Revert Despite a Sufficient Ticket Balance?

Registration must satisfy module capacity and validator-key checks as well as the ticket minimum. PufferProtocol rejects invalid public-key data or incorrect Guardian key-share counts. Funding and authorization must also match the chosen payment method. Sufficient VTs alone do not make an invalid payload acceptable or reserve capacity in a full module.

When Does a Rejected Validator Registration Incur a Ticket Penalty?

Skipping an already-pending registration can incur the protocol's configurable VT penalty. Guardians can skip invalid registrations during provisioning, returning the operator's pufETH bond and deducting tickets. This differs from a registration transaction reverting before it creates a pending record. The initialized penalty is 10 VTs, and governance can change it.

Who Can Withdraw VTs Deposited for Another Node Operator?

The deposited VTs belong to the specified node operator's protocol balance for withdrawal purposes. The depositor supplies tokens, while the withdrawal function deducts tokens from its caller's operator balance. Depositing for another operator therefore does not give the depositor withdrawal control over those tokens. The operator's active and pending validator restrictions still apply.

Do Ticket-Funded Validators Require Operators to Run AVS Software?

Puffer's delegated module arrangement separates Ethereum validation from actively validated service (AVS) duties. Node operators run Ethereum validators, while chosen restaking operators perform the module's AVS duties. A node operator may also take a restaking-operator role, but ticket-funded validation alone does not require taking that additional role. Module participation can provide restaking reward commissions.

Are Puffer Validator Tickets Interchangeable With Ethereum Execution Tickets?

Puffer Validator Tickets are application-level ERC20 tokens granting operating time for Puffer-funded validators. The Execution Tickets name refers to a separate Ethereum research proposal. The concepts share research history, while a Puffer VT balance records ownership of Puffer's operating-time tokens. Buying VTs does not implement the separate Ethereum proposal.

Does Paying With pufETH Use a Fixed One-to-One VT Exchange Rate?

A pufETH-funded ticket purchase converts the ETH value of the selected VTs into vault shares. The required pufETH quantity follows both the ticket price and PufferVault's share conversion. The purchase calculation rounds the required input upward. Paying in pufETH therefore does not establish a fixed exchange of one pufETH for one VT.

Which Identifier Links the Registration Record to the Beacon Chain Validator?

The validator public key links its Puffer registration record to its beacon chain identity. Puffer's internal module index and the beacon chain validator index are separate identifiers. Match the public key when comparing those records; a pending registration still precedes provisioning and beacon chain activation.

Pufferfinance validator tickets grant operating time for staker-funded Ethereum validators

Pufferfinance validator tickets are ERC20 tokens representing the right to run a staker-funded Ethereum validator for one day. Node operators deposit tickets alongside a bond, then earn rewards from the validators they operate. The protocol initializes its registration minimum at 28 VTs, with the ordinary route using a 2 ETH bond held as pufETH. Buying tickets alone creates token ownership; registration, provisioning and beacon chain activation determine when validator operation begins.

On this page

The short version: Validator ticket payments buy operating time, while bond refunds depend on the validator's exit balance and slashing status.

Does Buying a Validator Ticket Start Earning Validator Rewards?

Buying a VT establishes token ownership; validator rewards come from operating an activated validator backed by the required bond and deposited tickets. Operators keep 100% of the consensus and execution rewards their validators produce during covered operation. Ticket payments remain an expense, so gross rewards differ from profit.

Execution rewards reach the configured fee_recipient address, while consensus rewards follow a separate accounting and payout process, including claims on Base. pufETH holders participate in the staking pool through liquid restaking, while ticket-funded operators perform Ethereum validation.

The Upfront Payment Behind Each Validator Day

When the burst threshold is not exceeded, ticket minting compensates pufETH holders for financing Puffer's validators before operators earn validation rewards. One VT represents one validator-day of operating time. Ticket prices reflect expected daily consensus and execution rewards, adjusted by the protocol discount. Actual validator earnings depend on performance and reward conditions, including maximal extractable value (MEV).

Below the protocol's burst threshold, ETH minting payments cover Guardian and treasury fees. The remainder enters PufferVault for pufETH holders. If the oracle reports the threshold exceeded, the entire ETH payment goes to the treasury. A transfer of already-minted VTs changes ownership without making another minting payment.

pufETH-funded purchases handle the payment differently. Below the threshold, fees go to the treasury and Operations Multisig, with the remaining pufETH burned to reduce vault shares without removing their backing. Above the threshold, the entire pufETH payment goes to the treasury.

The Upfront Payment Behind Each Validator Day (Pufferfinance validator tickets) - illustration — The Upfront Payment Behind Each Validator Day

Open full-size image

Bond, Ticket Minimum and Validator Preparation

Registration requires a validator payload, a selected Puffer module and funded bond and ticket inputs. The ticket minimum is configurable; 28 VTs is its initialized value and the amount specified in the standard registration instructions.

Bond Funding

The ordinary registration route uses a 2 ETH bond held as pufETH. Its share quantity follows the vault conversion rate, so 2 ETH worth of collateral need not equal two pufETH tokens. PufferProtocol also defines a 1 ETH bond branch for enclave-evidence registrations. That branch requires its own registration data; it does not change the ordinary route's requirement.

Validator Preparation

Validator operation requires execution, consensus and validator software. Coral-CLI prepares the validator keys and registration payload. Its encrypted keystore uses ERC-2335; retain the encrypted file and protect its password. The payload identifies the selected module and its withdrawal credentials. Puffer modules connect validator stakes to EigenPods for native restaking. Accepted registration creates a pending validator record. Provisioning requires available staking liquidity and Guardian validation before Puffer allocates 32 ETH. Beacon chain activation remains a later event, so a successful registration transaction does not start the ticket clock.

Purchase and Registration Funding Options

Ticket acquisition and validator registration support distinct funding patterns. The table compares contract-supported options; the transaction submitted by an interface determines which pattern applies. Wallet-held tickets and deposited tickets have different withdrawal conditions.

Open full-size image

Operation	Payment Assets	Ticket Location	Access Condition
Separate ETH mint	ETH	Recipient wallet	No validator commitment
Separate pufETH mint	Authorized pufETH	Recipient wallet	No validator commitment
Acquire existing VTs	Assets specified by the trade	Acquiring wallet	Transfer does not register a validator
Register with ETH funding both components	ETH for bond and ticket minting	Operator's protocol balance	Withdrawal blocked by active or pending validators
Register with a pufETH bond and ETH ticket payment	pufETH and ETH	Operator's protocol balance	Withdrawal blocked by active or pending validators
Register with an ETH bond and existing VTs	ETH and authorized VTs	Operator's protocol balance	Withdrawal blocked by active or pending validators
Register with a pufETH bond and existing VTs	Authorized pufETH and VTs	Operator's protocol balance	Withdrawal blocked by active or pending validators

A First Purchase Before Registration

A separate VT purchase can finish with tickets in the wallet before any validator registration. This provides a stopping point before committing a bond and depositing tickets for validator operation.

Purchase Inputs

Buy VT in the Puffer Dashboard opens controls for selecting an available currency and ticket quantity. An ETH purchase on Ethereum Mainnet requires funds for both the payment and transaction gas. Review those transaction details before confirming; this separate purchase does not require a validator registration payload.

The native ETH minting function calculates ticket quantity from the ETH payment and oracle price at execution. A quoted quantity can change if that price changes before execution. The function itself has no separate minimum-ticket-output parameter.

Confirmation and Stop Point

A wallet signature authorizes the purchase transaction; a successful receipt confirms execution. The increase in the recipient's VT balance records the minted ticket quantity, which you can compare with the submitted payment and execution price. A token balance does not indicate an activated validator.

Stopping after the purchase leaves the tickets outside the validator commitment. They remain transferable tokens, although selling them depends on market liquidity and trade terms. Registration requires a further decision to provide the bond, validator data and deposited tickets.

Ticket Coverage During Operation

Ticket coverage begins when the validator activates on the beacon chain, after registration and provisioning. Additional deposits extend the operating commitment. The protocol reconciles consumed tickets when handling validator exits, so its stored balance can include operating time not yet settled. Monitor validator activity alongside deposited ticket coverage and client health. Purchasing more wallet-held VTs without depositing them does not extend the protocol commitment. Exhausted coverage triggers validator ejection, with bond settlement following the applicable exit conditions.

Exit Accounting and Capital Recovery

Exit settlement accounts for chargeable operating time and any bond deductions. Unused tickets remain in the operator's protocol balance until the withdrawal function's conditions allow their release.

Ticket Accounting at Exit

The burn calculation translates active epochs into validator-time, with a minimum ticket charge applying to early exits. If the minimum charge applies and a raised minimum exceeds the operator's remaining balance, settlement consumes that balance. Leaving early therefore need not return a ticket for every unused day.

Visual summary: Pufferfinance validator tickets: Exit Accounting and Capital Recovery — Exit Accounting and Capital Recovery

Open full-size image

An operator can withdraw remaining VTs only when none of their validators is active or pending. Exiting one validator does not unlock that balance if another remains active or pending.

Bond Settlement

An unslashed validator returning at least 32 ETH allows the operator to recover the full bond. For an unslashed withdrawal below 32 ETH, PufferProtocol calculates a pufETH deduction for the deficit. Its published settlement code reverts if that deduction exceeds the bond; a slashed validator forfeits the entire bond. Settlement returns the remaining pufETH collateral; redeeming that token is a separate operation.

Ticket payments cover operating rights, while the bond absorbs specified validator losses. Holding pufETH alone provides staking-pool exposure without managing ticket coverage, validator keys or node availability. Running a ticket-funded validator adds those operating duties while the operator keeps the validator's own rewards.

Key questions about Pufferfinance validator tickets

Can Several Validators Share One Node Operator's Deposited VT Balance?: PufferProtocol records one deposited VT balance for each node operator. Validators registered by that operator use the shared balance for ticket accounting. Each validator registration must add at least the configured ticket minimum. Coverage must reflect the validators' aggregate operating time. Wallet-held VTs remain separate until someone deposits them for that operator.
Why Can Validator Registration Revert Despite a Sufficient Ticket Balance?: Registration must satisfy module capacity and validator-key checks as well as the ticket minimum. PufferProtocol rejects invalid public-key data or incorrect Guardian key-share counts. Funding and authorization must also match the chosen payment method. Sufficient VTs alone do not make an invalid payload acceptable or reserve capacity in a full module.
When Does a Rejected Validator Registration Incur a Ticket Penalty?: Skipping an already-pending registration can incur the protocol's configurable VT penalty. Guardians can skip invalid registrations during provisioning, returning the operator's pufETH bond and deducting tickets. This differs from a registration transaction reverting before it creates a pending record. The initialized penalty is 10 VTs, and governance can change it.
Who Can Withdraw VTs Deposited for Another Node Operator?: The deposited VTs belong to the specified node operator's protocol balance for withdrawal purposes. The depositor supplies tokens, while the withdrawal function deducts tokens from its caller's operator balance. Depositing for another operator therefore does not give the depositor withdrawal control over those tokens. The operator's active and pending validator restrictions still apply.
Do Ticket-Funded Validators Require Operators to Run AVS Software?: Puffer's delegated module arrangement separates Ethereum validation from actively validated service (AVS) duties. Node operators run Ethereum validators, while chosen restaking operators perform the module's AVS duties. A node operator may also take a restaking-operator role, but ticket-funded validation alone does not require taking that additional role. Module participation can provide restaking reward commissions.
Are Puffer Validator Tickets Interchangeable With Ethereum Execution Tickets?: Puffer Validator Tickets are application-level ERC20 tokens granting operating time for Puffer-funded validators. The Execution Tickets name refers to a separate Ethereum research proposal. The concepts share research history, while a Puffer VT balance records ownership of Puffer's operating-time tokens. Buying VTs does not implement the separate Ethereum proposal.
Does Paying With pufETH Use a Fixed One-to-One VT Exchange Rate?: A pufETH-funded ticket purchase converts the ETH value of the selected VTs into vault shares. The required pufETH quantity follows both the ticket price and PufferVault's share conversion. The purchase calculation rounds the required input upward. Paying in pufETH therefore does not establish a fixed exchange of one pufETH for one VT.
Which Identifier Links the Registration Record to the Beacon Chain Validator?: The validator public key links its Puffer registration record to its beacon chain identity. Puffer's internal module index and the beacon chain validator index are separate identifiers. Match the public key when comparing those records; a pending registration still precedes provisioning and beacon chain activation.

Updated on 13-Oct-2026