The original Agoric tokenomic design involved a two-token system: BLD and the stable token IST. Since that original design, two major changes have happened to the Agoric ecosystem.
-
First, the development of orchestration radically changes the ability of the Agoric platform to serve the needs of the broader blockchain ecosystem.
-
Second, changes in demand for stable tokens meant that IST was sunset in July 2025.
In this document we are proposing a new tokenomics that ensures chain security and economic efficiency by aligning incentives in the market for BLD as the orchestration economy grows, especially across chains, and drives value to the BLD token and token holders.
We present here for the community, a proposed revision of the Agoric tokenomics. We invite comment and discussion on the proposed changes, which will be considered in revision of the final litepaper. We will leave the discussion open for 10 days. Please comment and share. TIA
[Proposed Litepaper follows]
================================[BEGIN]===============================
Agoric tokenomics litepaper
(version 10 Dec 2025)
The cryptoeconomy has entered its next phase: a multichain economy where value, liquidity, and applications naturally span multiple networks. No single blockchain is the center of gravity anymore.
Agoric’s orchestration allows work to be automated across chains, over time, without forcing users to juggle gas tokens or complex workflows.
Agoric’s orchestration-first model uniquely supports multi-block, multi-chain, asynchronous applications — software that can coordinate actions over time and across ecosystems, all powered by one token.
In this document, we describe the economic characteristics of orchestration, and propose a revamp of BLD tokenomics so that the BLD token and fee model can support long-lived cross-chain contracts and to ensure that BLD directly captures value from orchestration. It provides:
-
Value capture for BLD holders: Orchestration activity and contract operations drive direct demand for BLD, linking token value to network use.
-
Simplicity for users: Instead of unpredictable execution costs, users just pay a clear, predictable postage fee.
-
Developers empowerment: Orchestration enables new applications and flexible business models, whether they come from Web2 or Web3. Agoric’s orchestration-first design enables use cases not possible on other chains.
-
Network sustainability: Contract stakes, gas purses, and the Purser system ensure operations are funded and accountable.
By positioning BLD as the center of the ecosystem and firmly linking it to Orchestration, Agoric is laying the foundation for a more scalable, flexible, and user-friendly network that can drive the growth of the multichain digital economy.
The cryptoeconomics of orchestration
The Agoric L1 supports multi-block, asynchronous programs through a combination of distributed object-capability security, asynchronous message passing, and durable contract execution within the JavaScript runtime. Each smart contract runs in an isolated vat—a deterministic event loop that processes messages and event responses sequentially.
Multi-block behavior emerges naturally because messages between vats are durable and replayable; a contract can send a message to another vat or chain and later receive its response in a future block without halting execution or requiring a new transaction from the user.
Moreover, the implications of this architecture extend beyond the boundaries of the Agoric L1, allowing for interactions across chains and the ability to exercise control over, and interact with remote accounts. This makes the Agoric L1 an enabler of cross-chain economies by reducing frictions while also promoting on-chain secure computing.
Cross-chain orchestration extends this model beyond the local chain. Outbound actions are encoded as IBC packets or routed through bridge adapters (e.g., Axelar, CCTP). The orchestrator manages these remote calls as asynchronous promises; it queues the operation, tracks confirmation or failure, and resumes local logic when results return.
The architecture of the Agoric L1 allows programs to behave like distributed workflows — reacting to events, performing remote operations, and maintaining consistency across chains while remaining fully verifiable and deterministic. The result is a generalized framework for on-chain automation and cross-chain state continuity, built directly into the Agoric platform.
A new fee structure for orchestration
On most blockchains, users pay directly to run contracts. This made sense when contracts and exchanges were limited to just one blockchain at a time. But in a multichain world of increasing institutional adoption, the user-pays model creates serious problems. For example, users must hold gas tokens for every chain and service they touch, just to interact with an app. This shifts all the costs (time, effort, and money) directly on to users, even though contracts and developers are the ones consuming resources and have the specialised capabilities to deal with these costs efficiently. These issues make blockchain apps hard to use and limit their potential scale.
Orchestration introduces an asynchronous fee model that reflects real-world business needs, where users pay postage and contracts pay execution and orchestration fees. This model aligns incentives with Agoric’s orchestration-first architecture — where long-lived, cross-chain contracts power real applications at scale.
The new fee structure is designed to put funding responsibility where it belongs: on the services that consume the resources.
-
Users pay a small “postage” fee to deliver a message, which helps prevent spam
-
Contracts cover the costs of execution and orchestration
Contract fees and purses
The orchestration services used by contracts include:
-
Agoric execution costs such as gas and storage fees
-
Creation of remote accounts to be controlled by the contract
-
Cross-chain transfers such as via CCTP, Axelar, etc.
-
Swaps between tokens, typically executed on remote DEXs
-
Invocation of remote operations, such as invoking an Aave supply operation on a remote account
Contracts pay for these services through a fee account: each contract must pre-fund its fee account for orchestration and gas. Anyone (including DAOs or community funds) can top the fee account up. If that account runs dry, synchronous operations like local execution will continue for a brief (governance determined) period while async operations like remote messages pause.
In addition to the fee account, contracts must also maintain a stake balance (which functions as a performance bond). Synchronous operations executed after the fee account is exhausted temporarily accrue a debt. The debt must be repaid or governance can enforce penalties or slashing against the contract stake. This simplifies resource management and error handling within contracts. Additionally, the system may deploy the funds under stewardship for (low-risk) returns. Yields from contract stakes are treated as additional orchestration fees.
Each remote operation typically requires fees to be paid at the destination (e.g., gas fees on Arbitrum, relayer fees for Axelar). The contract pays those in BLD, and orchestration or intermediate services convert that to the appropriate gas token (see, “Coordination and governance”, below).
The orchestration services charge commission on those remote operation fees. This is an important new source of revenue. For example, as of this writing (2025), an Orchestration transaction to request an Aave supply operation costs less than a penny to execute on Agoric, whereas the remote operation it invokes costs approximately $0.18. Given that many transactions are likely to incur multiple remote operations, a 10% commission on the total fees accrued will be an order of magnitude higher than Agoric chain fees. As a result, the BLD economy taps into the economic value of those other chains.
Figure 1: Sample Transaction
Coordination and governance
This tokenomics design also introduces two critical functions to support the fee account and contract stake and coordinate and facilitate exchanges: stewards and the purser.
· Contract Stewards: Each app has an infrastructure agent, its Steward, which manages its gas fee account and ensures orchestration actions are funded with the right tokens. The contract prepays for services in any allowed token to the Steward, and the Steward converts it to BLD (using local or remote on-chain markets).
· Purser: The Purser is a chain-level infrastructure service for orchestration. It manages fee routing/burning, governance enforcement, and yield on contract stakes. This structure allows iterative upgrades and more sophisticated financial operations.
Governance determines how the fee surplus is disbursed. For example, BLD holders might choose to direct the surplus to a community pool, to burn BLD, to deploy it into defi contracts to earn interest, or to otherwise return reward to BLD stakers. The Purser holds contract stakes, aggregates fees, and implements how network revenues are handled.
Orchestration pricing can be denominated in USD or BLD equivalents. The system dynamically adjusts the BLD amount to maintain stable real-world costs. Over time, as data accumulates, fees are likely to evolve toward market-driven pricing rather than governance-set rates. Governance may also reprice orchestration and gas fees monthly or as needed based on volatility.
Enhanced value capture for BLD
As apps use orchestration, they will require BLD to pay for it, naturally contributing to buy pressure on the BLD token. This creates opportunities for BLD tokenomics to capture further value for BLD, subject to community governance:
-
Steward-managed buybacks or internal swaps may be introduced
-
Fee burns could be used to offset emissions, achieving effective deflation once burn volume exceeds issuance
By directly linking network usage and orchestration activity to staking yield, the tokenomic structure tightly couples BLD demand to the success of applications and captures value through multiple fee flows (see Figure 2 below):
-
Postage fees (paid by users)
-
Execution & storage cost (paid by apps)
-
Orchestration fees (paid by apps, including gas fees for remote and cross-chain operations)
Figure 2: Fee Sources & Routing
This refreshed tokenomics model – including the infrastructure components of Stewards and the Purser – is designed to make Agoric simpler for users, more rewarding for stakers, and more powerful for developers and the network as a whole.
===============================END==================================
fixed supply (800M BLD)