Paymaster
How gas sponsorship and protocol fee collection work in LazorKit — the Paymaster service, fee_payer economics, and on-chain FeeRecord tracking.
Paymaster
The Paymaster is the entity that sponsors gas for LazorKit transactions. It acts as the transaction's fee_payer on Solana — signs the transaction, pays the SOL required for gas, and submits it on-chain.
In practice, the developer is the Paymaster
Most LazorKit integrations do not use a third-party Paymaster service. The developer (integrator) is the fee_payer — they fund their users' wallet creation and execution directly.
The developer recoups the cost through app-level monetization — on-ramp markups, subscription fees, product fees, in-app purchases, or direct token collection. LazorKit doesn't prescribe this layer; it only cares about the fee_payer pubkey on-chain.
The developer's fee_payer pubkey is tracked in FeeRecord — that's the basis for early contributor rewards at token launch. If you sponsor your users' fees, you earn.
Economic Flow
- User pays — the developer, through app-level monetization. The mechanism is the dev's choice.
- Developer pays (as
fee_payer) — SOL for gas + LazorKit's protocol fee. Recouped from the user via the app. - LazorKit earns — the protocol fee, recorded against the developer's
fee_payerpubkey.
The end user never needs to hold SOL. The developer acts as the economic bridge: takes value from the user in whatever form their app supports (USDC, fiat on-ramp, subscription, product fees), and pays protocol costs in SOL.
Protocol Fee Collection
LazorKit captures a protocol fee on sponsored transactions. The fee is deducted from the transaction's fee_payer — which is the Paymaster, not the end user.
Fee collection applies to every transaction whenever ProtocolConfig is enabled — no opt-in required. What is opt-in is reward tracking: the integrator's cumulative contribution only accumulates in a FeeRecord PDA if one has been registered for that fee_payer. Unregistered payers still pay the fee, they just don't accrue towards early-contributor rewards.
Register your FeeRecord to earn
The protocol fee is charged either way. Registering a FeeRecord for your fee_payer
pubkey is what turns those fees into a reward claim at token launch. No registration →
no on-chain accumulation → no share.
Flow per transaction:
- SDK always appends 4 accounts (
ProtocolConfig,FeeRecordPDA derived from the payer,TreasuryShard,SystemProgram) when the protocol is enabled. - Entrypoint detects them and transfers SOL from the
fee_payerto a randomly-selected treasury shard. - If
FeeRecordis a valid program-owned account, bumptotal_fees_paid,tx_count,wallet_count. Otherwise skip the counter update. - The 4 protocol accounts are stripped before passing to the processor — processor is unchanged.
Fee collection applies to: CreateWallet, Execute, and ExecuteDeferred.
Architecture
Sharded Treasury
Fees route to one of N shards (e.g. 16), selected randomly per transaction. This eliminates write contention — parallel transactions hit different shards without blocking each other.
Admin calls WithdrawTreasury once per shard to sweep accumulated SOL to the treasury address.
On-Chain Accounts
ProtocolConfig — ["protocol_config"]
Global configuration. Set once via InitializeProtocol.
| Field | Description |
|---|---|
admin | Protocol admin pubkey |
treasury | Withdrawal destination |
creation_fee | Lamports per CreateWallet |
execution_fee | Lamports per Execute / ExecuteDeferred |
enabled | 0 = disabled, 1 = enabled |
num_shards | Number of treasury shards |
FeeRecord — ["fee_record", fee_payer_pubkey]
Created by admin via RegisterPayer. One per fee_payer — typically one per Paymaster operator.
| Field | Description |
|---|---|
total_fees_paid | Cumulative lamports paid — basis for early contributor rewards |
tx_count | Fee-eligible transaction count |
wallet_count | Wallets created via this fee_payer |
registered_at | Registration slot |
FeeRecord currently tracks the fee_payer — the developer (or Paymaster service) that sponsored the transaction. This data is the basis for rewarding early contributors: developers that funded protocol activity before the token launched.
Future: a parallel tracking mechanism may be added for end users, so that users can also be recognized for their protocol usage.
TreasuryShard — ["treasury_shard", shard_id]
8-byte account. SOL accumulates as lamport balance. Created once per shard via InitializeTreasuryShard.
Fee Amounts
Fees are configurable. Current values are set by the protocol admin.
| Instruction | Typical Fee |
|---|---|
| CreateWallet | ~5,000 lamports |
| Execute | ~2,000 lamports |
| ExecuteDeferred | ~2,000 lamports |
Per fee-eligible transaction overhead: ~3,000 additional CU and +128 bytes (4 extra accounts).
Early Contributor Rewards
FeeRecord.total_fees_paid tracks cumulative fees per fee_payer proportional to the volume of activity they sponsored. When the protocol token launches, early contributor rewards are distributed based on this data:
- Snapshot all
FeeRecordaccounts viagetProgramAccounts(filter by discriminator6) - Calculate share:
contributor_share = total_fees_paid / sum_all_fees - Distribute via merkle airdrop or direct transfer
The intent — for developers: if you build on LazorKit and pay for your users' wallet creation and transactions, your fee_payer pubkey accumulates SOL paid into FeeRecord. That's your reward claim. The more user activity you sponsor in the early phase, the larger your share of the token launch.
This is a direct growth incentive: LazorKit does not take a cut from your app-level revenue, and it rewards you in protocol tokens for the protocol fees you funded on behalf of your users. User-level tracking may be added later so end users can share in this as well.
Current Status
- Protocol fee system is live on Solana mainnet
- Fee collection operates in native SOL
- Protocol token for governance and fee settlement is not yet deployed
- Future: open Paymaster competition where multiple providers compete on sponsorship terms (rates, supported tokens, SLAs)