Decentralised News · Editorial by Heath Muchena · Evidence reviewed 11 November 2026. Original DN analysis and local instrument; field testing is claimed only where expressly reported.
What Matters
An agent can earn revenue while its token holders have no direct claim to that cash. A transferable token, a buyback policy and a redeemable vault share describe different mechanisms. DN’s payout-rights instrument begins with the documented holder mechanism, then reconciles a single distribution pool to an eligible snapshot and recipient receipt. It does not turn protocol revenue into a token valuation.
DN Evidence Block
- Last verified
- 11 November 2026.
- Primary technical sources
- ERC-20, ERC-4626 and OpenZeppelin’s vault documentation.
- Established distinction
- A transfer interface does not define a universal revenue-share right. Vault shares have specific asset-conversion and redemption interfaces that should not be assumed for unrelated tokens.
- DN original instrument
- DN Agent Token Payout Rights Reconciliation v1.0.
- Evidence boundary
- No named agent token is valued or rated. Worked amounts are hypothetical; rights references and receipts supplied by readers are not authenticated.
Revenue needs a path to the holder
“The agent makes money” is the first question in an economic analysis. “Who is entitled to that money?” is a different question. The agent’s operator may need to pay for compute, data, execution, maintenance or capital. A treasury may retain the balance. A token may provide access or voting power without distributing cash at all.
Even when a payment mechanism exists, the eligible holder may not be every owner of the advertised token. Participation can depend on a snapshot, staking state, separate receipt token or a specified distribution period. A general market-cap-to-revenue ratio does not identify those conditions.
DN thesis: before valuing an agent-linked cash flow, identify the instrument carrying the claim and reconcile an actual payment path. The immediate useful output is an evidence-backed allocation record, not a price target derived from an unexamined revenue headline.
DN’s Compute-Backing Ratio article examines network-revenue denominators. This article asks the subsequent, separate question: what connects a particular holder to a particular distribution? Strong revenue evidence cannot answer that question by itself.
A token standard is not a universal economic contract
ERC-20 specifies a common token interface, including balances, transfers, approvals and supply. Those methods help applications interact with a token. The standard does not prescribe a general obligation to distribute the revenue of an associated agent or company. The economic mechanism must be found in the relevant implementation and terms. [1]
ERC-4626 addresses a different structure: vault shares representing a fraction of underlying holdings, with standardized deposit, conversion, withdrawal and redemption interfaces. That makes it a useful example of an explicitly defined asset relationship. It does not mean every agent token is a vault share or that a marketing description creates those methods. [2]
Separate technical behavior from legal effect. A contract may contain a distribution function, but the function’s access controls, funding, eligibility and upgrade conditions still matter. A legal document may describe rights that require enforcement outside the code. This article records the evidence to review; it does not settle either layer’s enforceability.
Four mechanisms that cannot share one payout formula
| Mechanism | What to inspect | Why revenue alone is insufficient |
|---|---|---|
| Direct distribution | Allocation rule, eligible snapshot, funded pool and recipient receipt. | The business may earn revenue without allocating it to this holder class. |
| Buyback | Authorized policy, executed purchases, funding and treatment of acquired tokens. | A market purchase is not a direct pro-rata payment to every holder. |
| Governance or access | Voting or service entitlements and their conditions. | Use or voting rights do not automatically create a cash distribution. |
| Vault redemption | Underlying asset, share conversion, fees, limits and actual redemption path. | A redeemable asset claim needs its own model, not a dividend assumption. |
Hybrid arrangements can contain several mechanisms. Keep each path separate. For example, a project could fund a buyback and a distribution in the same month. Adding them together as “holder income” would conceal who actually received value and how it was delivered.
From gross receipts to an allocated pool
A careful source file distinguishes external-customer receipts, protocol-level fees, operator costs, retained funds and the amount assigned to a holder distribution. A public dashboard may report only one of those quantities. Determine which before using it in an allocation calculation.
Do not automatically subtract guessed costs from revenue to create a distributable pool. If the relevant agreement allocates a share of gross receipts, a modeled net-profit figure may be the wrong base. If it allocates net income, the allowable deductions need evidence. The correct calculation follows the documented arrangement.
The DN instrument therefore asks for the allocated distribution pool directly. It does not infer that pool from a network revenue number. The reference should identify the period, accounting unit, funding source and rule that connects the pool to the eligible holders.
A funded pool also needs provenance. Current operating receipts, a treasury subsidy and newly issued incentive tokens may all fund transfers, but they describe different economic sources. Record that distinction in the supporting evidence rather than interpreting every receipt as recurring agent profit.
The denominator is the eligible snapshot
For a simple pro-rata distribution, the denominator is the number of eligible units under the allocation rule. It may differ from total token supply or circulating supply. Using the wrong denominator can create a precise-looking allocation that no participant is actually entitled to claim.
Record the snapshot time or block, contract version, eligibility condition and unit scaling. The holder numerator must come from the same snapshot and use the same unit. Mixing today’s balance with last month’s eligible supply silently changes the entitlement model.
Some arrangements use time-weighted balances, lock multipliers, tiers or minimum thresholds. The current calculator does not implement those structures. A reader should not compress them into a simple holder balance without a documented conversion to eligible weighted units and a clear explanation of that conversion.
Changing eligibility rules also requires versioning. A distribution based on yesterday’s rule should remain reproducible after a governance decision changes tomorrow’s rule. An automatic article update should not overwrite the historical denominator or make the new rule appear to have applied earlier.
Use the DN Agent Token Payout Rights Reconciliation
Select the holder mechanism before entering the numbers. The local calculator performs a pro-rata allocation only when “Direct distribution” is selected. For buybacks, governance, unknown mechanisms or vault redemption, it reports that the direct-payout model is not applicable and leaves the allocation empty.
DN Agent Token Payout Rights Reconciliation v1.0
Use non-sensitive aliases and your own evidence. Inputs remain in this page; this instrument makes no external requests and saves nothing to browser storage. Downloaded files contain your entries. Example numbers are scenarios.
No record prepared. Example inputs are illustrative.
For a direct distribution, enter the allocated pool, eligible token units, the holder’s eligible units and the recipient receipt, all with consistent units. Add non-sensitive reference aliases for the rights and eligibility terms, snapshot, pool and receipt.
The output distinguishes missing references from recorded references. Neither state is legal clearance. An alias could point to outdated terms, an incorrect contract or an unverified claim. The reader must inspect the source material and actual implementation separately.
A worked example of allocation versus payment
Suppose a hypothetical pool contains 1,000,000 payout accounting units. There are 1,000,000 eligible token units and the holder owns 1,000 of those units at the relevant snapshot. The holder’s fraction is 0.001, or 0.1%. A simple pro-rata allocation is 1,000 payout accounting units.
If the accounting unit is a US cent, the pool is $10,000 and the calculated holder allocation is $10. If the entered receipt is 800 cents, the arithmetic difference is 200 cents. The tool does not call those $2 a legally overdue debt. Timing, fees, corrections, a partial payment or an incorrect input may explain the difference.
Now change the mechanism to buyback only. The tool stops computing that $10 allocation. A buyback can have economic effects, but a holder’s share of a buyback budget is not automatically a cash amount payable to that holder. The model must not fabricate a dividend because a budget and supply denominator are available.
Similarly, selecting vault redemption leaves the allocation empty. A vault model requires the underlying asset, conversion behavior, available liquidity and applicable conditions. Reusing a distribution formula would answer a different question from the one a redeeming holder needs answered.
Redemption quotes need their own evidence
ERC-4626 distinguishes preview functions from maximum-withdrawal or maximum-redemption limits. A preview can describe a conversion while limits still constrain whether the operation is currently available. An integration should not treat an attractive preview as a guarantee that the holder can complete the redemption. [2]
OpenZeppelin’s vault documentation also discusses rounding and implementation-specific behavior. That is a reminder to inspect the deployed implementation and version rather than assuming that a familiar interface removes all economic or technical risk. This article does not run a vault audit or reproduce those security tests. [3]
The corresponding editorial rule is straightforward: name the observation. “The preview returned this amount at this block” is narrower than “the holder can withdraw this amount now.” An actual receipt is stronger evidence of completed settlement, but it still describes one transaction and its conditions.
Decision table for an agent-token claim
| Evidence available | What can be recorded | What remains unestablished |
|---|---|---|
| Agent revenue dashboard | The issuer’s reported revenue measure and definition. | Holder entitlement and paid distributions. |
| Distribution policy with no funded pool | A documented policy or proposed allocation. | The amount available for the particular period. |
| Funded pool with no eligible snapshot | The recorded pool amount. | Each holder’s fraction. |
| Terms, pool, snapshot and receipt references | A record ready for substantive reconciliation. | Legal validity, authenticity and future repetition. |
What automatic updates should preserve
Each distribution period needs its own record. New revenue does not retroactively fund an earlier pool, and a new token contract does not silently replace the old eligibility terms. Preserve the original references and add explicit superseding records when corrections occur.
Publish changes to the mechanism before publishing a new payout estimate. If a project moves from discretionary buybacks to a direct distribution, that is a structural change requiring fresh terms and implementation evidence. A percentage copied from a presentation is insufficient to populate the new model as fact.
The export schema, dn.agent-token-payout.v1, includes the mechanism, units, evidence aliases, inputs and results. It explicitly records that no legal entitlement or investment value has been determined. Consumers of the JSON should carry those limitations forward rather than extracting the allocation alone.
Methodology and limits
For a direct distribution, allocation equals the pool multiplied by holder units and divided by eligible units, rounded down to the whole payout accounting unit. The implementation uses integer arithmetic for that multiplication and division. The eligible supply must be positive, and holder units cannot exceed it.
The rounding convention is part of this model, not a claim about every distribution contract. If an agreement uses another rule, the current worksheet is unsuitable without modification. The arithmetic difference subtracts the entered receipt from the allocation and can be negative when the receipt exceeds it.
No token price, discount rate, growth assumption, APY or expected return enters the calculation. The record does not assess whether a token is an investment security, whether an agreement is enforceable or whether the operator can sustain future payments. It is a one-period evidence and arithmetic instrument.
Frequently asked questions
Does an ERC-20 token receive agent revenue automatically?
No universal revenue-share rule comes from ERC-20. Examine the actual rights, implementation and distribution records.
Does a buyback count as my cash payout?
It is a different mechanism. The calculator does not assign a pro-rata cash receipt to holders from a buyback budget.
Can a vault preview prove immediate redeemability?
No. Review applicable limits, implementation behavior and the actual operation. A quote and a completed redemption are different observations.
Can I use the result to value the token?
The output is a narrow allocation scenario or reconciliation record. It does not estimate investment value or the persistence of future cash flows.
Primary sources
- ERC-20: Token Standard.
- ERC-4626: Tokenized Vaults.
- OpenZeppelin Contracts 4.x: ERC-4626 documentation, cited for implementation and rounding context, not a live product recommendation.
Corrections and change log
11 November 2026 — v1.0: introduced mechanism-specific handling, a snapshot-based direct-distribution calculation and explicit exclusion of valuation outputs. Send a documented calculation or source correction to press@decentralised.news. No token issuer paid for inclusion, and this edition makes no investment recommendation.
