Agoric announced its first mainnet phase after the chain began on November 1, 2021. That phase established the staking network and validator participation; it was not a declaration that every proposed JavaScript application could already be deployed without permission. The phased approach matters when reading old promotional material. A working consensus layer, a production contract framework and an open developer platform are different milestones, even when they share the same mainnet name and token.

Mainnet 1 followed in October 2022, adding the composable contract framework and an initial Inter Protocol service. Agoric's account connected the project to a broader philosophy of cooperation through enforceable agreements. BLD supplied the staking and governance role in that architecture. The engineering ambition was unusually specific: bring the familiarity of JavaScript to blockchain programming while changing the execution environment enough to manage financial rights safely. Familiar syntax alone was never the proposed security mechanism.

Agoric's programming guide describes an object capability model: code receives references granting particular powers instead of automatically inheriting access to everything around it. Hardened objects resist later mutation, and compartments restrict the global environment. A contract does not gain a network connection or a system clock merely because ordinary web JavaScript might have one. The practical discipline is to grant a component only the authority its task needs.

This reduces opportunities for accidental privilege sharing, although it does not prove that the task itself is correctly designed.

Zoe handles another boundary. Participants submit offers and escrow assets through the service, while a contract directs permitted reallocations. Its offer safety promise concerns receiving the requested allocation or recovering the offered assets under the offer's conditions. That is narrower than a guarantee of profitable trading, a stable token price or uninterrupted chain operation. For a reader evaluating an application, the important questions are what the offer actually requests, when it can exit and which conditions the contract is allowed to satisfy.

The orchestration framework treats waiting as part of the program. A contract can manage a remote account, request an action, suspend and resume after the response arrives, rather than requiring a person to manually coordinate every intermediate step. Timers and asynchronous messages make multistep workflows possible across more than one block. That does not make every external network automatically reachable. An application still depends on supported connections and the behavior of the remote systems it asks to operate.

Fast USDC illustrated the distinction between a fast user experience and final settlement. Agoric's March 2025 announcement described liquidity providers advancing funds while Circle's crosschain transfer completed in the background. The recipient could therefore receive usable liquidity before the underlying process finished. Someone else supplied the capital and accepted the intervening exposure. The announcement is evidence of the product's launch and design, not an independent benchmark or a promise that every route remains available today.

The current CoreEval guide still describes governance authorized deployment on mainnet. A proposal can execute a privileged script and supply capabilities required to install services. This is materially different from assuming that any developer can upload an arbitrary production contract whenever they wish. Agoric's language tooling can be open and broadly usable while the production deployment path remains controlled. Readers should check the deployment procedure for the particular service, rather than treating the future Mainnet 3 label as proof that permissionless deployment has arrived.

Upgrade authority is also explicit in Zoe's documentation. A contract's administrative facet can permit replacement of its implementation, and important contracts may have that authority held through the bootstrap environment and governance. Durable state can survive upgrades, but ordinary in-memory state is not automatically preserved. Discarding an upgrade reference changes one layer of control; it does not place the entire virtual machine beyond future chain governance. An application audit therefore needs both the business logic and the people or processes capable of changing it.

Inter Protocol once supplied IST and was central to Agoric's economic design. In April 2025 the Decentralized Cooperation Foundation proposed winding it down. A later update by Albena reported that all vaults had closed or been liquidated by July 1 and that the protocol was no longer operational. The same discussion described a temporary route for remaining conversions. These are separate stages of an exit process. The announced deadline should not be mistaken for evidence that an old interface is still usable now.

The change in gas denomination was debated separately. Antman's May 2025 proposal sought to replace IST with BLD for fees. O_D argued that additional use mattered more than changing the denomination, while Futurist questioned the continuing limits on open deployment. Their disagreement exposed two different definitions of progress: connecting fees directly to the token, and enabling enough independent activity to produce meaningful fees. A governance proposal could change the first without automatically delivering the second.

The public mainnet parameter response read for this edition denominated the fee unit price in ubld. This is direct evidence of the queried fee configuration, not a deduction from a marketing roadmap. It also returned the network's beans accounting parameters. Those values describe how computation and other resource use are measured and charged in that configuration. They do not establish the future burn policy advocated in community threads, and they should not be converted into an investment return estimate.

In May 2025 Agoric described a shift toward building and scaling a focused product rather than waiting for a broad external application ecosystem to emerge. The plan emphasized automated crosschain asset management and a closer connection between activity and BLD. It also set future delivery goals. Those goals belong to the history of the strategy, not to a list of completed milestones. The change helps explain why later governance discussions concentrated on one orchestration product and its economics.

An October proposal sought approval for a limited Ymax portfolio contract beta. It described an invite phase, specific administrative control and integrations for moving USDC into selected strategies. Those permissions and restrictions are important parts of the proposal, not incidental details behind a yield interface. The record supports a dated account of what the team asked governance to authorize. It does not, by itself, prove that every proposed integration was deployed, that the invitation phase ended or that a portfolio could never lose value.

The January 2026 tokenomics paper set out a model in which applications fund operations through accounts and bonding arrangements, with services coordinating gas needed elsewhere. Its economic question is how useful orchestration creates demand for BLD. Buying a token for one step and selling assets to pay another network are flows that must be considered together. Gross purchases alone cannot establish lasting scarcity. The destination of fees, any burning and the issuance policy all affect the final relationship between service use and holders.

The publication thread supplied an important deployment boundary. BCMO said that implementation required chain upgrades. In May, Dean Tribble clarified that the SDK maintenance upgrade then under discussion did not directly implement the proposed Purser and Steward components. This prevents a common reading error: a published economic model and a software maintenance release can coexist without the model becoming active. Current claims about the mechanism need an implementation record and live parameters in addition to the paper.

The draft tokenomics discussion included sustained questioning from Jericho about quantitative assumptions and supply policy. Dean Tribble replied that the team was using information from the product beta, while other participants requested provisional modeling without treating assumptions as binding promises. This was a dispute over the evidence needed to judge the mechanism. It was not a published, independently reproduced forecast. For a reader, the useful distinction is between a model's accounting structure and the measured inputs that would make its outputs persuasive.

Another discussion proposed burning BLD when staking rewards were claimed. BCMO objected that a flat charge would fall more heavily on a small claim than a large one, and Dean Tribble asked how the rule would interact with transactions containing several messages. These objections are concrete rather than ideological: a burn can reduce supply while also changing who finds a routine action affordable. The thread documents a design debate. It does not establish that the proposed charge was enacted.

Michael_FIG's Beans v2 discussion explored making resource charges easier for wallets to estimate and adding configurable burning rules. An August update described a working design process, not a completed mainnet activation. The proposal connects a developer experience problem to token economics: users need understandable costs before signing, while governance may want flexibility over fee destinations. Treating those as one design problem is useful, but neither better presentation nor a burn setting can guarantee that applications will attract demand.

A proposal to increase the deposit needed for governance submissions prompted a different conflict. Ric argued for stronger spam resistance. Omar replied that relying on sponsorship could move the barrier from money to influence, because a newcomer would need to persuade an established participant before reaching a vote. Subsequent discussion explored a compromise. This is evidence of disagreement about access, not proof of a final parameter change. A chain can discourage low quality proposals and still face a serious question about whose ideas reach its formal process.

Exchange access became another visible argument in September 2026. Zook wanted discussion of a major listing, while O_D preferred existing access and emphasis on product development. BCMO raised the cost and difficulty of previous efforts. Their posts describe competing priorities among identifiable participants, not a referendum of all holders. More trading venues might change convenience or liquidity, but a listing discussion cannot settle whether the network is useful or whether its token economics work.

Kryha's original account of developing KREAd described an avatar and item system built through collaboration with Agoric. Its interest was in programmable ownership and a creator experience, rather than simply issuing a token with a familiar image. The guest post belongs to the development history and should not be read as current usage statistics. It nevertheless provides a specific example of why a JavaScript oriented team might engage with this architecture: familiar programming concepts paired with explicit control over digital assets.

Economist Jason Potts offered a broader argument for orchestration in a foundation published essay. He treated waiting, coordination and incomplete processes as economic costs that software could reduce. This is a theory of why the infrastructure might matter, not measured proof that a particular investment strategy earns more. The distinction is useful when interpreting the project's vision. Automating a series of actions can remove labor or delay while leaving the underlying market exposure, protocol dependence and business model unresolved.

Agoric's 2021 account of work with Informal Systems described formal modeling of kernel behavior, including promises and communication between execution units. Such work can test whether an implementation or model satisfies specified properties. It cannot establish that every later contract, integration or economic incentive is safe. The account also recognized the need to keep models aligned with changing software. Formal methods are therefore part of an assurance process, rather than a permanent label attached to the whole network.

The July 2026 upgrade record provides a more recent operational checkpoint. The 23a release addressed upgrade information handling and documented its software dependencies; the accompanying discussion reported that 23a was live. Release instructions and a contributor's deployment report are different evidence types, and neither is a census of every validator. The mainnet status endpoint also returned a recent September 30 block when checked for this edition.

That observation supports ongoing operation at that time, while leaving application availability and validator diversity as separate questions.