A programmable paying agent is the onchain distribution layer of tokenized finance. It receives a budget, applies a set of rules encoded in smart contracts, and pays recipients directly to their wallets, on a public blockchain. It performs the same economic function as a traditional paying agent, the bank or trust company that handles dividend payments, bond coupons, and M&A proceeds, but operates entirely on a public blockchain rather than through banking rails and central depositories.
In tokenized finance, this role becomes essential. Protocols and tokenized funds need to distribute value to thousands of wallets based on rules that no traditional paying agent was built to handle: rewards tied to user activity, multi-chain distributions, real-time accruals, and waterfalls too complex to apply by hand.
This article explains what paying agents have always done in traditional finance, why those rails break when assets move onchain, and what a paying agent looks like when the calendar is the block and the recipient is a wallet.
What a paying agent does in traditional finance
Behind every dividend payment, every bond coupon, and every M&A closing payout sits a paying agent. You don't see them, but they're doing most of the work.
When Apple pays a quarterly dividend, Apple doesn't send checks to its 30 million shareholders. It wires the total amount to its paying agent (Computershare in their case), which then calculates each shareholder's entitlement, applies the relevant withholding tax, and pushes the payment through to brokers and custodians around the world. Same logic for a corporate bond: the issuer sends the full coupon amount to the paying agent on each interest date, and the agent distributes it across hundreds of bondholders sitting in different jurisdictions, currencies, and tax regimes.
The paying agent role exists because issuing securities at scale creates a logistics problem that issuers don't want to solve themselves.
The function bundles together several specific tasks:
-
The arithmetic. Calculating who gets what when there are multiple share classes, liquidation preferences, partial accrual periods, or fractional positions.
-
Tax withholding. Applying different rates depending on each holder's tax residence and applicable treaty status, then remitting the withheld amounts to the right authorities.
-
Currency conversion. Paying USD-denominated coupons to euro-based holders, GBP holders, JPY holders, with FX execution and reporting.
-
Fiduciary segregation. Holding the funds in an account separate from the issuer's balance sheet, so holders still get paid if the issuer goes bankrupt between the declaration date and the payment date.
-
Edge cases. Lost certificates, deceased holders, unclaimed amounts, addresses gone stale, holders who never reply.
In M&A, the paying agent's role gets more intricate. When a company gets acquired, the buyer wires the full purchase price to the paying agent ahead of closing. The agent then distributes proceeds to potentially thousands of shareholders according to the merger agreement's payment waterfall: senior preferred first, then junior preferred, then common stock, then vested options, with carve-outs for management bonuses, escrow holdbacks, and indemnification reserves.
That waterfall is where the complexity really shows up. A typical VC-backed exit can have five or six classes of equity, each with different liquidation preferences, participation caps, and conversion mechanics. The paying agent's job is to translate the legal waterfall written in the merger agreement into actual wire transfers, with the right amount going to the right person, on the right day, after the right deductions.
Hold that picture in mind: a third party receives a total budget, applies a complex rulebook, and pushes the right amount to the right recipient. That's a paying agent.
Why traditional paying agents can't serve onchain finance
Finance is moving onchain, and not as a slogan. BlackRock's BUIDL has put institutional treasuries on Ethereum. Robinhood, Kraken, and several brokers now offer tokenized US equities that trade 24/7 on public chains. Stablecoin supply now sits in the hundreds of billions of dollars, with PayPal, Visa, Stripe, and Mastercard all building product flows on top of stablecoin rails. The GENIUS Act, passed in the US in 2025, gave stablecoin issuance its first federal framework, a signal that even the regulatory layer is catching up to where capital has already moved.
That shift creates a new infrastructure problem. The assets are onchain. The holders are onchain. The accruals happen onchain. But the entities responsible for actually distributing dividends, coupons, yields, and rewards were built around financial plumbing that doesn't reach into a wallet on Base or Arbitrum.
The first limit is composability
In traditional finance, a shareholder holds shares. That's it. Onchain, a user might hold LP tokens that are staked in a yield protocol that uses them as collateral on a lending market, which itself wraps the position into a yield-bearing receipt token. The same wallet can be lending, providing liquidity, and farming yield all at once, with positions nested three or four layers deep. To figure out who actually deserves what, the distribution layer needs to see through every layer in real time. No traditional paying agent was built to do that.
The second limit is the rails
Distributing onchain isn't moving money through SWIFT or settling through a CSD like DTCC or Euroclear. It's writing transactions to a public ledger, in stablecoins, often across multiple chains in parallel. That requires a fundamentally different stack: the ability to read each chain block by block, parse the right contracts, and translate onchain state into accurate entitlements. The upside is transparency and instant settlement, both of which traditional finance has been chasing for years. The downside is that almost no traditional paying agent has the engineering to operate at that level.
The third limit is the clock
Tokenized finance doesn't have a closing bell. Yield accrues on a Sunday at 3am the same way it accrues on a Tuesday afternoon. Liquidity moves between pools at every block. Borrowers open and close positions on weekends. A distribution system that depends on humans clicking through a process during business hours can't keep up. Whatever replaces traditional paying agents in tokenized finance has to be programmatic by default and run onchain by design.
What an onchain paying agent does
A programmable paying agent is the onchain distribution layer of tokenized finance. It performs the same function as a traditional paying agent (receive a budget, apply a rulebook, distribute to recipients), but the budget moves in tokens, the rules live in smart contracts, and the recipients are wallets rather than registered holders. The distinction matters. A traditional paying agent that automates its workflows is still moving fiat between bank accounts, still depending on SWIFT, ACH, or central securities depositories, still settling on T+2. A programmable paying agent skips that infrastructure entirely. Tokens move directly from one wallet to another, on a public blockchain, in seconds.
The "programmable" part is the whole point. The rulebook isn't written in legal prose for an analyst to interpret. It's written in code that runs automatically when conditions are met.
That unlocks three properties traditional paying agents can't deliver:
Rule complexity becomes free
Distribution rules can be arbitrarily intricate without adding operational cost. A budget can be split across thousands of wallets based on holder seniority, position size, holding duration, multi-chain activity, and per-wallet caps, all without anyone manually computing the result. The marginal cost of one more rule is essentially zero.
Distribution becomes continuous, and the recipient controls the timing
Recipients accrue value in real time and can claim it whenever they want. This is a structural shift from traditional paying agents, where the agent decides when the money lands in your account and you have no say. Onchain, the entitlement is yours the moment it accrues, but it stays parked in the contract until you trigger the claim. That gives the recipient real optionality. Claim now to redeploy the capital. Claim in December to push the income into next year's tax cycle. Claim only when gas is cheap. Claim into a different wallet than the one that earned it. None of this is possible when a paying agent at BNY Mellon wires funds to your custodian on a fixed date, the same day, for everyone, with no flexibility. The artificial calendar of quarterly dividends or semi-annual coupons is a constraint of the old model, not a feature anyone actually wanted.
Auditability is the default
Every recipient can verify how their amount was calculated. Every dollar that goes in can be traced to the dollar that comes out. Disputes over "did I get paid the right amount" become rare because the calculation is public and reproducible.
Where the model still needs traditional paying agents
There are tradeoffs. Onchain programmable paying agents can't handle tax withholding the way regulated agents do, since enforcing residency-based withholding requires interfacing with tax authorities and verifying identities outside the chain. They don't have the fiduciary licenses that some institutional investors require for certain regulated products. They don't yet replace a Computershare or a BNY Mellon for a publicly listed company's quarterly dividend.
That's why, in regulated tokenized products, programmable paying agents typically operate alongside traditional trust companies. Securitize runs the smart contracts that distribute yields for BlackRock's BUIDL fund, while BNY Mellon handles the off-chain custody and reporting. Ondo Finance distributes USDY yields onchain through smart contracts, while Ankura Trust acts as the verification and security agent for the underlying collateral.
But for distributions that live entirely onchain, where the assets, the recipients, and the rules are all in code, the programmable paying agent is the entire stack. There is no off-chain leg. There doesn't need to be one.
How Merkl works as a programmable paying agent
Merkl is built specifically for this role. The flow is straightforward: an issuer sends a budget to Merkl, defines the distribution rules, and Merkl handles the rest.
One engine, any distribution rule
The rules can target any onchain pattern. Tokens held over time, eligibility based on a snapshot, position size weighted by duration, activity across multiple chains, exclusions by address. Whether the budget is a yield distribution on a tokenized fund, a coupon on a tokenized bond, a dividend on tokenized shares, or a reward tied to onchain activity, the engine applies the rule the same way. The same composability that makes onchain finance hard for traditional paying agents (tokens deposited, wrapped, staked, or lent across protocols) is precisely what Merkl is built to read through.
Under the hood, Merkl's engine reads onchain data block by block, calculates each holder's entitlement based on the rules, and updates claimable amounts. Recipients claim when they want, paying gas only when they decide to. Issuers see exactly where their budget goes, who receives it, and on what basis.
Reward forwarders: paying the real owner, not the contract
The waterfall logic that traditional paying agents apply manually is just code in Merkl. In tokenized finance, the wallet that holds an asset is rarely the user that owns it. A user can deposit tokens into a vault that issues a receipt token, stake that receipt token in another protocol that wraps it again, and end up several layers deep. To a naive paying agent, the apparent holder is whatever smart contract sits at the top of that stack. To Merkl, the engine traces ownership through every layer of nesting and routes the distribution to the actual end user, not the intermediary contract holding their position. We call these reward forwarders. This solves a problem that simply doesn't exist in TradFi but defines onchain finance: tokens are constantly moving across protocols, and the registered holder onchain is almost never the economic owner.
The result is that an issuer running a distribution through Merkl doesn't have to know in advance where the holders' tokens have been deposited. The engine figures it out. Rules get written once, and Merkl handles the routing through whatever composability the recipients have built around their position.
Stacking rules, caps, and exclusions in one configuration
On top of that, a distribution can stack multiple rules, apply caps, set minimums, exclude addresses, weight by position type or token, all in the same configuration. Distribution complexity that would take a traditional paying agent weeks to set up takes minutes onchain.
Trusted at scale across the industry
More than 250 companies have run onchain distributions through Merkl, including PayPal, Circle, Coinbase, SG-Forge (Société Générale's digital assets subsidiary), Kraken, and Morpho, with distributions running across 60+ chains.
What matters is that the function being performed maps directly onto what paying agents have done in traditional finance for decades, rebuilt for an environment where the calendar is the block, the recipient is a wallet, and the rules are written in code.
FAQs
Is Merkl a paying agent in the regulatory sense?
No. Merkl is not a registered paying agent under SEC, MiFID, or any other financial regulation. The terms "onchain paying agent" and "programmable paying agent" describe the economic function Merkl performs, not its regulatory status. Merkl operates as onchain distribution infrastructure, not as a licensed fiduciary entity. For regulated tokenized products that require a licensed paying agent (registered bonds, public funds), the onchain distribution layer typically operates alongside a traditional trust company.
What's the difference between a paying agent and a transfer agent?
A transfer agent maintains the registry of who owns what. A paying agent distributes payments to those owners. In traditional finance, these are usually separate functions handled by separate entities, though large institutions like BNY Mellon and Computershare often offer both. In tokenized finance, the registry function is performed by the token contract itself, while the paying agent function is performed by onchain distribution infrastructure like Merkl.
Can an onchain paying agent handle tax withholding?
Not natively. Tax withholding requires identifying each recipient's tax residence, applying the correct treaty rate, reporting to tax authorities, and remitting withheld amounts. Smart contracts can encode logic, but they can't independently verify residence or interface with tax administrations. For tokenized products that require withholding, this layer is typically handled off-chain by a traditional paying agent or fund administrator, while the onchain distribution layer handles the actual transfer of value.
Why don't traditional paying agents do onchain distributions?
Some are starting to. BNY Mellon, Citi, and Computershare have all announced blockchain initiatives, mostly focused on tokenized bonds and money market funds. But their infrastructure was built for periodic, low-frequency, high-fiduciary-burden distributions. Adapting it to high-frequency, composable, multi-chain distributions requires a fundamentally different architecture, which is why purpose-built infrastructure has emerged in parallel rather than from the incumbents.
Is "onchain paying agent" a standard industry term?
Not yet. Different actors use different language: distribution layer, programmable money, onchain payments, tokenized rewards. As tokenized finance matures and traditional asset managers move more flow onchain, "onchain paying agent" maps more cleanly onto a role institutional finance already understands than purely crypto-native terms do.
What kind of distributions can an onchain paying agent handle?
Anything where a budget needs to be allocated across multiple recipients on a blockchain. The architecture supports yield distributions on tokenized funds, coupons on tokenized debt, dividend equivalents on tokenized shares, waterfall payments in structured products, treasury distributions, and rewards tied to onchain activity. For regulated products, additional compliance layers (KYC, withholding, fiduciary custody) typically operate alongside the onchain layer rather than replacing it.