7Block Labs
Blockchain Development

ByAUJay

Onchain Billing for Staking APIs: Lessons from 2025’s Developer Platforms

Short Summary

Fast forward to 2025, and we finally saw staking APIs take the leap to on-chain billing. This post condenses everything that actually launched (and functioned smoothly) across platforms like Coinbase, Figment, Kiln, and the EigenLayer ecosystem. You'll also find real-world integration patterns, code snippets, and a handy production checklist to help you set up your own on-chain billing that's transparent, easy to audit, and budget-friendly.

Why this matters now

Two big shifts in 2025 made onchain billing for staking go from being just a “nice idea” to something everyone needs to have:

  • Platforms have made things a lot smoother with fee-split contracts, where validators are the recipients of the fees. This means no more manual invoicing, and revenue sharing is streamlined into predictable on-chain flows. A great example of this is Coinbase’s “Enhanced Onchain Billing” for Dedicated ETH staking. With it, integrators just attach a Plan ID, and a reward-split contract automatically springs into action, distributing execution-layer rewards based on set percentages. Check it out here.
  • The Ethereum Pectra upgrade, along with some nifty paymaster tools and quicker USDC settlement with CCTP v2, has really reduced operational friction. It’s all about better control and compounding thanks to EIP‑7002/7251, using ERC‑4337 paymasters for gas sponsorship, and enjoying near-instant USDC treasury settlements across different chains. You can dive deeper into it here.

Here’s a handy guide to the patterns, potential pitfalls, and top-notch practices we've observed from actual launches happening in 2025.


What “onchain billing” means for staking APIs in 2025

  • Let’s break it down: the protocol only splits what it pays to the fee recipient, which includes execution-layer (EL) tips and MEV. Rewards from the consensus-layer (CL) follow the established protocol rules; they stack up on the beacon chain and, depending on your credentials, they’ll eventually make their way to the withdrawal address. On the flip side, the EL pays out right away to the designated fee recipient. That's why most on-chain billing focuses on EL flows. (coinbase.com)
  • Fee-split contracts are treated as the validator's fee recipient. These split contracts are stateless (or “zero-balance”) between distributions; they pass along rewards and manage the agreed-upon split. This has pretty much become the norm across various providers. (docs.cdp.coinbase.com)
  • You can tweak how often rewards get distributed. For instance, Coinbase sets up monthly distributions, but they also allow integrators to kick off on-chain distributions whenever they want. (docs.cdp.coinbase.com)

What changed in 2025 that made this viable

  • Pectra officially launched on May 7, 2025, bringing some exciting updates:

    • EIP‑7002: This one allows validator exits triggered by the execution layer through the withdrawal credential, which adds an extra layer of safety for delegated and enterprise flows.
    • EIP‑7251: We now have a higher effective balance that lets validators compound up to 2,048 ETH. That means fewer validators to keep track of and easier accounting overall.
    • EIP‑6110: Deposit processing time has dropped to about 13 minutes, compared to a hefty 9 hours before Pectra--a much quicker path to go live! (blog.ethereum.org)
  • The ERC‑4337 paymasters have really come into their own, with vendors and first-party solutions like Coinbase Paymaster and Alchemy Gas Manager making gasless transactions a breeze, thanks to clearer billing models. (docs.cdp.coinbase.com)
  • Circle’s CCTP v2 has made cross-chain USDC settlements super fast, cutting them down to just seconds. This upgrade is now the go-to version, which is a game-changer when you're dealing with fee-split contracts that pay to L2 addresses or when you need to move revenue back to your treasury chain. (circle.com)
  • Restaking platforms have really tightened up the economics. EigenLayer has rolled out slashing and introduced a feature called “Redistribution.” Plus, they added rewards upgrades and multi-chain verification, allowing operators and integrators to lean on programmable incentives and non-L1 deployments. (coindesk.com)
  • We got some clarity on regulations: On May 29, 2025, the SEC’s Division of Corporation Finance made a statement that clarified some protocol staking activities don't involve an offer or sale of securities. This strengthens the case for non-custodial, on-chain, programmatic flows. (sec.gov)

Concrete platform patterns to copy (or avoid)

1) Coinbase Staking API: Plan‑ID driven fee‑split contracts

  • How it works
    • First, you set up a Reward Distribution Plan that outlines the percentages and payout addresses.
    • When you're ready to stake your Dedicated ETH, just include the fee_recipient_address and reward_splitter_plan_id. Coinbase takes care of deploying the fee-split contract as your validator’s EL fee recipient. The cool part? Rewards get split automatically, and the CL flows right to your withdrawal address. Check out more details here!

Minimal Example (TypeScript)

Here's a simple example to get you started with TypeScript. It’s a straightforward way to understand the basics.

// This is a simple function that adds two numbers
function add(a: number, b: number): number {
    return a + b;
}

// Let's use the add function
const sum = add(5, 10);
console.log(`The sum is: ${sum}`);

In this snippet, we defined a function called add that takes two numbers and returns their sum. Then we called this function with 5 and 10, and printed the result to the console. Easy peasy!

import { Coinbase, ExternalAddress, StakeOptionsMode } from "@coinbase/coinbase-sdk";

const addr = new ExternalAddress(Coinbase.networks.EthereumHoodi, "WALLET_ADDRESS");
const planId = "PLAN_ID";
const feeRecipient = "END_USER_ADDRESS";

const op = await addr.buildStakeOperation(
  32,
  Coinbase.assets.Eth,
  StakeOptionsMode.NATIVE,
  { fee_recipient_address: feeRecipient, reward_splitter_plan_id: planId }
);
await op.wait();

Behind the scenes, this sets up the validator and designates the split contract as the recipient for EL fees--meaning the billing happens right on the blockchain. (docs.cdp.coinbase.com)

  • When to use
    • Perfect for wallets, exchanges, or enterprise portals looking for non-custodial staking. This approach offers a predictable revenue share and keeps things simple with minimal new contract surface area.

2) Figment On‑Chain Billing: zero‑balance pass‑through splitters + reporting APIs

  • So, Figment’s got these audited fee-splitter contracts that set up the validator’s EL fee recipient to a pass-through contract, splitting it among N parties. Each withdrawal address gets its own little splitter. They also have APIs that break down Net vs. Gross Rewards, which is super handy for accounting and forecasting. You can check it out here: (docs.figment.io)
  • Useful APIs

    • Net Rewards API: This one shows you just the amounts that have actually been distributed--basically, what’s hit your wallet.
    • Gross Rewards API: Here, you get the total amounts accrued, including things that are still pending--perfect for digging into performance analysis.
    • Add Address API: This lets you register your staking wallets along with the effective fee split. Don’t forget to check it out: (docs.figment.io)
  • When to use

    • If you need to do some validator-level reconciliation and want an external “proof of payout” that finance teams can link back to invoices or general ledger accounts, this is the way to go.

3) Kiln “Integration Contract” and Fee‑Splitter Factory: highly configurable monetization

  • Kiln gives partners the ability to own an integration contract that sets up:

    • end-user fees and commissions,
    • how commissions are split among stakeholders,
    • weighting across different operator pools,
    • both EL and CL fee-recipient pathways using deterministic CREATE2 receivers. (docs.kiln.fi)
  • They've got your back with native ETH staking that includes on-chain fee-splitting and some cool Pectra features (like partial withdrawals and compounding) - all detailed in their 2025 documentation. (docs.kiln.fi)
  • When should you use this?

    • For platform distributors looking for programmatic revenue routing, multi-operator hedging, or white-label control.

4) StakeWise V3 Vaults: fee splitters as first‑class objects

If you're diving into vault-based staking, you'll be happy to know that StakeWise offers reward splitters you can easily query and manage through their SDK. This turns fee recipients into flexible building blocks for your projects. Check it out here: (docs.stakewise.io)


Integration patterns we recommend (with 2025‑ready details)

Pattern A -- EL‑only split, CL flows to withdrawal address

  • Make sure to set the validator’s fee recipient to your split contract.
  • Leave CL as is to keep the protocol-native compounding or periodic sweeps intact (Pectra’s EIP-7251/6110 really enhances both operations and timing).
  • Take a look through a Net vs. Gross perspective to match up those monthly statements with chain data. (coinbase.com)

Why this works: You take advantage of the protocol's quick EL payouts and steer clear of messing with CL logic. This keeps things straightforward during audits and reduces the risk tied to the contract.

Pattern B -- Dual‑path receivers (EL + CL) via CREATE2

  • If you’re looking for CL-level programmability, like setting up institutional policies for partial exits and automated treasury actions, make sure to compute deterministic recipients for both EL and CL. Then, send them into an upgrade-controlled dispatcher, which is the approach that Kiln takes.
  • It's a good idea to use predictable addresses before you deploy. This way, validators can be set up in advance. You can check out more on this here.

Cautions

  • Make sure to keep dispatcher upgrade rights limited, like using a timelock combined with multisig.
  • Log your distribution as events for an immutable audit trail.
  • It’s best not to hold any balances on the dispatcher when you're not in distribution windows.

Pattern C -- Restaking revenue multiplexing (EigenLayer Rewards v2)

  • AVSs let you set up reward time ranges, weights for each strategy, and the payout token. Just a heads up--your operator or integrator needs to map these according to individual customer entitlements. It’s not a good idea to hardcode a single token path since EigenLayer rewards are now multi-token and time-restricted. Check out more details here.
  • When it comes to slashing and “Redistribution,” be prepared for some non-proportional clawbacks or reimbursements. You should treat those as separate journal entries and make sure they're visible in customer statements. For more insights, you can read this article.

Pattern D -- Cross‑chain settlement to treasury with CCTP v2

  • So, if your split contract is all about payouts on Ethereum but you’re funneling revenue into an L2 treasury (like Base) or any exchange-connected chain, you’re in luck! CCTP v2 lets you quickly bridge USDC in just seconds. It even comes with hooks that can auto-swap or route flows for you. This is perfect to use after you batch or aggregate those micro-rewards. Check it out here: (circle.com)

Pattern E -- Gasless distributions via ERC‑4337 paymasters

  • To make the user experience smoother, let users trigger “distribute()” or “claim()” without needing any ETH. Coinbase’s Paymaster has a straightforward billing method: it calculates costs using actualGasUsed × ethPriceUsd × 1.07, and presents it in USD. Alchemy does something similar but on a larger scale. Be sure to set limitations per operation, create allowlists, and keep an eye on the sponsored operations. You can check out more details here.

A tale of two builds (end‑to‑end examples)

Example 1 -- A wallet adds Dedicated ETH staking with onchain splits (2‑week sprint)

  • Goal: We're aiming for an 80/20 split where 80% of EL rewards go straight to the end user, 15% goes to the wallet, and 5% to the staking provider. Plus, all CL rewards will get swept to the user’s withdrawal address.
  • Implementation:

    1. Start by defining a Reward Distribution Plan in the provider portal and grab that Plan ID.
    2. When it's stake time, pass the planId along with the endUserAddress; make sure the split contract is set as the fee recipient.
    3. Display a “Pending first distribution” banner, and show a “Trigger distribution” button that calls the splitter (this will be sponsored through your paymaster).
    4. On a monthly basis, reconcile the Net Rewards (EL) with the chain logs; remember, CL is separate and can be seen in your “staking balance” component. (docs.cdp.coinbase.com)
  • Notes:

    • Keep in mind that MEV/priority tips can vary, so the revenue might fluctuate depending on network conditions--make sure to set clear expectations in your product copy. (ethereum.org)
    • For the gasless distribution cost model, estimate your sponsorship based on the past actualGasUsed for distribute() and apply your business rules (like a per-user daily cap). (docs.cdp.coinbase.com)

Example 2 -- An exchange rolls out white‑label native staking with Kiln + Pectra features (quarter‑long rollout)

  • Goal: We want to provide native validators that offer compounding (0x02), allow for partial withdrawals, and enable partner monetization:

    • We’ll take an 8% cut of the EL rewards as a service fee, sharing it 60/40 with our partners.
    • 70% of the EL rewards will go straight to the user, with CL compounding active up to the new effective balance.
  • Implementation:

    1. Launch an Integration Contract through Kiln’s factory; set the fee, designate recipients, and establish multi-operator weights (like 70% for OperatorA and 30% for OperatorB).
    2. Make sure to use deterministic CREATE2 recipients so that EL/CL fee endpoints are known before activation.
    3. When EL payouts hit a certain threshold, add USDC treasury settlement to Base via CCTP v2; we’ll handle settlements on a weekly basis. (docs.kiln.fi)
  • Notes:

    • We’ll roll out a “Compounding enabled” badge and display a reduced validator count after consolidation--this is a cool perk from the Pectra era that your customers can really notice. (blog.ethereum.org)

Observability and reconciliation: the data you must capture

Payout Traceability

  • Keep track of fee recipient addresses for each validator.
  • Make sure to split contract addresses for each withdrawal address or entity.
  • Record distribution transaction hashes and event logs, detailing the amounts per recipient and token.
  • Don’t forget to note the source block and builder/relay metadata for extra context on EL rewards (like MEV tips versus priority fees). Check out this link for more info.

Accrual vs. Cash Basis

  • Use the provider’s “Gross” APIs if you want to look at accrual views, and switch to “Net” APIs for settled cash. Make sure to reconcile everything with Etherscan logs for each split contract. For more details, head over to docs.figment.io.

Gas Sponsorship Logs

  • Store those UserOperation hashes, simulate the outcomes, and tie them to USD billing (the formula is actualGasUsed × ethPriceUsd × 1.07). Keep an eye out for any outliers! You can find more insights in this guide.

Security, risk, and governance in 2025

  • Slashing and Restaking

    • Now that EigenLayer’s slashing feature is up and running--plus with “Redistribution” making clawbacks a breeze--it's a good idea to treat your AVS earnings and penalties as two separate ledgers. This way, you'll have better visibility for customers and clear windows for disputes. It’s also smart to develop some internal tools to help you predict how changes in operator settings might affect things. (coindesk.com)
  • Contract Surface

    • Whenever possible, go for zero-balance pass-through splitters and use immutable or role-limited logic. If you feel like you absolutely need upgradeability, stick to timelocks and make sure you have well-documented runbooks ready for any emergency patches. Recent happenings in the industry have really highlighted how crucial it is to have orderly exits and clear control. (docs.figment.io)
  • Compliance Posture

    • The SEC’s statement from May 29, 2025, is a pretty encouraging sign for protocol staking at the non-custodial level. Make sure to keep your legal team in the loop about revenue recognition for EL/CL flows and any AVS-related tokens you distribute. (sec.gov)

Cost controls and UX: what actually works

  • Batch and sponsor wisely

    • Only sponsor gas for user-triggered distributions when payouts are above a certain threshold. If not, try batching them monthly. Keep an eye on how much gas the average distribute() call uses, and update the UX copy to include estimated time of arrival (ETA) and rules for cost coverage. (docs.cdp.coinbase.com)
  • Use CCTP v2 hooks

    • Once a distribution is finalized, automatically swap a set portion of the platform’s share to USDC and bridge it to the treasury. Start with small amounts as a test run and set up alerts for any transfer latencies over 30 seconds. (circle.com)
  • Educate on EL variability

    • Help manage user expectations by linking them to MEV/tips conditions--more activity on the chain usually results in better EL rewards. Consider showing a rolling 7-day EL/CL split chart within the app to keep users informed. (coinbase.com)

Emerging best practices (2025)

  • Product

    • Make it super clear for users where their CL and EL rewards are going. Let them trigger gasless distributions right within policy limits. Check it out here.
  • Engineering

    • Let's use Plan-ID style abstractions so that business splits can change without needing to create new contracts. Also, it would be great to have a “dry-run” endpoint so users can calculate the next distribution amounts before sending a transaction. More info can be found here.
  • Finance/ops

    • Make sure to reconcile monthly by using settled Net Rewards and share any pending Gross amounts. Don’t forget to attach transaction hashes to downloadable statements. You can learn more about it here.
  • Treasury

    • It’s important to set specific sweep thresholds for each chain. Aim to settle to your base chain with CCTP v2 on a weekly basis, and then convert to fiat if necessary. Here’s the full scoop here.
  • Risk

    • For restaking, make sure to version your AVS reward policies, keep track of operator sets, and publish an easy-to-understand note for customers explaining how redistribution and slashing work. You can see the details here.

7Block Labs’ implementation blueprint

Discovery (1-2 weeks)

  • Kick things off by mapping out your current validator setup and fee recipient configuration. You’ll want to figure out which staking API(s) you’re planning to use (like Coinbase, Figment, or Kiln) and check if restaking fits into your plans. (coinbase.com)

Design (2 weeks)

  • Time to choose between Pattern A or B for EL/CL. Establish payout thresholds and determine the paymaster policies. Plus, you’ll want to decide on your treasury chain and how the CCTP flow will look. (docs.cdp.coinbase.com)

Build (3-6 weeks)

  • This phase involves wiring up the Plan ID/Integration contract, deploying the splitters, and adding in that all-important Net/Gross reconciliation along with statements. Don’t forget to integrate a gasless “distribute()” user experience and add some observability features. (docs.cdp.coinbase.com)

Harden (ongoing)

  • Keep things rolling by running integration tests focused on Pectra behaviors (think partial exits and compounding), stress-testing the paymaster caps, and simulating those AVS reward/redistribution scenarios. (blog.ethereum.org)

Final take

Onchain billing for staking has officially shifted from just being a concept to an actual product in 2025. By embracing the strategies mentioned earlier--like EL-first splits, Plan-ID configuration, a paymaster-guarded user experience, and CCTP-backed treasury rails--you can simplify operations, enhance financial clarity, and create a user experience that's intuitive right from the get-go. Plus, with tools like Pectra, ERC-4337, and the solid incentives from EigenLayer, the underlying infrastructure is finally ready to shine. Check out more details in the Coinbase docs.


References and further reading

  • Coinbase Staking API: They've just rolled out an awesome update for Onchain Billing, plus some dedicated ETH docs covering Plan IDs and split contracts. Check it out here!
  • Figment On‑Chain Billing: Dive into the new docs that explain zero‑balance splitters and how Net vs. Gross APIs work. Take a look here!
  • Kiln: You can now integrate with their fee‑splitter factory along with some cool native staking features using Pectra. All the details are here!
  • EL vs. CL rewards: Get the scoop on rewards and fee recipient mechanics from both ethereum.org and stakefish. Learn more here!
  • ERC‑4337 Paymasters: Coinbase has introduced Paymaster billing and Alchemy's Gas Manager; you can find everything you need to know here!
  • Circle CCTP v2: Check out their latest press release about the next evolution of CCTP, which is set to speed up cross-chain settlements for crypto capital markets. Details are here!
  • Ethereum Pectra: The Ethereum Foundation has put out a blog post on EIP‑7002 and Pectra. Read all about it here!
  • EigenLayer: They’ve added some key features like slashing, redistribution, rewards v2, and multi‑chain verification. Get the full story here!
  • SEC statement: On May 29, 2025, the SEC shared their thoughts on protocol staking activities. You can read the official statement here!

7Block Labs is here to help product leaders get their projects off the ground. We offer platform-agnostic architecture, tried-and-true contracts, and the essential support that keeps finance, legal, and engineering on the same page. If you're looking for the complete implementation spec or a detailed breakdown of your current workflow, just reach out!

Like what you're reading? Let's build together.

Get a free 30-minute consultation with our engineering team.

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2026 7BlockLabs. All rights reserved.