Ribbita is a Virtuals agent token, not a protocol token

TIBBIR is best understood as an issued asset inside Virtuals, not a claim on Virtuals’ platform revenue. The underlying platform is described in Virtuals’ LaunchPad documentation, where individual AI agents or agent-led businesses can be tokenized and traded, typically against $VIRTUAL as the base pair.

On Base, Ribbita by Virtuals trades as an ERC-20 at contract 0xA4A2E2ca3fBfE21aed83471D28b6f65A233C6e00.

That distinction matters for tokenomics. In TradFi terms, you are not buying the exchange. You are buying one listing on the exchange. So the economic question is narrow: what, if anything, does the TIBBIR instrument capture from activity around the Ribbita “agent,” and what can change after you buy it?

Supply, distribution, and the “graduation” mint

The clean headline from Virtuals’ LaunchPad docs is “fixed supply,” with agent tokens designed around a 1,000,000,000 unit total.

Ribbita’s onchain history shows a single genesis mint of 1,000,000,000 TIBBIR on January 12, 2025, during a “graduate / liquidity pool creation” flow routed through a Virtuals “Bonding Proxy” contract.

That same graduation flow shows how the initial supply was split between (1) tokens earmarked for the post-graduation liquidity pool and (2) tokens held in a bonding / vault-style address that appears to represent pre-pool distribution.

Two practical observations flow from that split.

First, the “fair launch, no insiders” framing in Virtuals docs is about the platform’s standardization and the absence of a classic team pre-mine in the token contract itself. It does not mean “no concentrated ownership.” The bonding / vault bucket can still be highly concentrated depending on who bought early. Virtuals’ own creator guide explicitly contemplates a deployer wallet purchasing up to a large fraction of supply pre-bonding, with an example table going up to 87.5% of supply.

Second, today’s onchain total supply is lower than the 1,000,000,000 genesis mint. BaseScan’s token tracker page shows a current total (“Max Total Supply” as displayed) of 999,904,783.797367999458008098 TIBBIR.

Mechanically, this is consistent with the token contract exposing burn functions, which can reduce total supply over time.

Fees and fiscal flows: the platform takes a cut, but TIBBIR does not default to “cashflow”

Virtuals’ LaunchPad documentation claims a simple economic loop: trades incur a 1% tax, designed to fund ongoing agent costs like inference and compute while maintaining the platform’s “fair launch” posture.

Virtuals also differentiates between phases. In the “Prototype” phase (pre-graduation), the 1% tax is allocated to the protocol treasury. After graduation (“Sentient”), the same 1% fee is split 70% to the agent creator and 30% to ACP incentives under the documented phase fee splits.

That is a fee model. It is not, by itself, a tokenholder return model.

For a contrast case, see how cashflow capture tends to be framed in more explicitly fee-sharing DeFi designs.

If you are looking for the equivalent of dividends or buybacks accruing to all holders, you need an explicit mechanism that routes fees to holders, retires supply, or buys/locks value in a way that is hard to reverse. The Virtuals docs emphasize funding the agent and creator incentives. They do not describe any default “fee share to TIBBIR holders” at the agent-token level.

The onchain implementation used by TIBBIR supports a configurable tax system. The AgentToken contract has parameters for buy and sell tax rates (basis points), a swap threshold, and a “projectTaxRecipient.” Taxes are accumulated in-token, and then swapped to the pair token via a Uniswap router path, with proceeds sent to the recipient per the tax configuration code.

Two TradFi-realist takeaways:

1) Fee monetization is real, but “who gets paid” is the whole game. A 1% trading tax can be a meaningful revenue stream in high-churn markets. Yet, in this design, the economic beneficiary is a recipient address (creator wallet, protocol module, or other destination), not tokenholders by default. If you are underwriting TIBBIR as an instrument, you should treat that tax as potentially strengthening the agent ecosystem, not as a direct claim you own.

2) The docs and the contract are not the same thing. The docs describe a 1% tax and specific splits by phase. The contract supports taxes, but the exact live settings for TIBBIR (current tax bps, recipient, and swap threshold) are not presented directly in the sources above. When the parameterization is not easily auditable from public-facing documentation, your confidence interval on “expected fiscal flows” widens.

“Graduation,” liquidity formation, and what’s actually locked

Virtuals’ platform narrative is built around a bonding curve phase that “graduates” into a DEX pool paired with $VIRTUAL. In the LaunchPad overview, the bonding curve is paired with $VIRTUAL, and once a limit is reached, a liquidity pool is created and then locked for ten years.

Virtuals’ “Modes” page gives a concrete graduation threshold for standard launches: 42,000 VIRTUAL in the bonding curve.

Separately, the “Launching an AI Agent Token” guide also ties “red-pilling / graduation” to 42,000 VIRTUAL bought into the curve, and it frames 12.5% as the portion available on Uniswap post-bonding.

There is a documentation inconsistency to flag. A LaunchPad page references a “bonding curve limit” of 200k VIRTUAL, while the “Modes” and “Launching guide” pages reference 42k VIRTUAL.

For TIBBIR specifically, the graduation transaction is unambiguous that a pool was created and initially funded. In that single transaction, the agent token emitted LiquidityPoolCreated for pool address 0x0c3b466104545efa096b8f944c1e524E1d0D4888, and it emitted InitialLiquidityAdded reflecting deposits of 124,129,984 TIBBIR and 42,336.427639208233007826 VIRTUAL in the graduation event logs.

The same transaction shows that LP tokens were minted (in the same numeric amount reported in the InitialLiquidityAdded event) and transferred into another contract, alongside the minting of a “staked” representation token (sTIBBIR) in equal quantity.

That looks consistent with Virtuals’ “liquidity lock / staking wrapper” story. Still, the exact lock terms for TIBBIR LP (duration, withdrawal authority, emergency controls) require reading the lock or staking contract code and permissions. Those details are not established by the sources cited here, so you should treat “locked for ten years” as a platform-level stated policy rather than a verified property of this specific pool instance.

Governance and control: the AgentToken has admin keys, and the constraints are soft

TIBBIR’s contract is built on Virtuals’ AgentToken standard, which is an ownable contract with a privileged “factory” role. The modifier used for sensitive actions is onlyOwnerOrFactory, meaning either the owner or the factory can make changes.

From a token-as-instrument perspective, the key levers are straightforward:

Fee parameters can be changed. The contract allows updating the tax recipient and changing buy/sell tax rates via admin calls.

“Only ever decreasing” is documented, not enforced. The tax rate setter is commented as “subject to only ever decreasing,” but the implementation shown sets the new rates directly without a hard check that they are lower than prior values. That makes “tax cannot be raised” a social promise unless enforced upstream by factory policy or by a governance process external to the token contract.

Liquidity-pool detection is mutable. The contract can add or remove addresses considered “liquidity pools,” which matters because tax application is based on whether a transfer is a buy or sell versus a pool.

There are emergency withdrawal paths. The contract includes withdraw functions for ETH and arbitrary ERC-20 tokens (excluding itself), callable by owner or factory, framed as safety valves in edge cases.

Net: TIBBIR is not “governance minimal.” It is admin-controlled infrastructure, designed to be operated as part of a broader platform. That is not automatically bad. It does change how you price risk. In equity terms, you have governance risk without governance rights.

Valuation lens: what you’re underwriting when you buy TIBBIR

If you strip out the memes and the AI-agent narrative, the economic core of TIBBIR is simple.

It is a fixed-supply ERC-20 that sits on top of Virtuals’ distribution rails and is likely to be economically coupled to platform rules like the 1% trading tax and the $VIRTUAL pairing convention.

That coupling cuts both ways:

Pros: Virtuals has standardization. Graduation creates a real pool. The pool creation and initial funding for Ribbita are visible onchain, not a marketing slide.

Cons: Your “fundamentals” are not agent revenues in the traditional sense. Most of what looks like revenue in these systems is transfer revenue sourced from trading activity. And unless that revenue is contractually committed to buybacks or holder distribution, it is not a valuation anchor. It is a budget line controlled by whoever controls the tax recipient and downstream distribution processes.

If you want a practical checklist for evaluating these mechanics, the tokenomics FAQ covers common investor-facing questions.

Also, because pools are typically against $VIRTUAL, TIBBIR inherits a correlation structure. If $VIRTUAL reprices sharply, agent tokens can suffer even if their micro-narratives are intact. This is the same “single factor” problem you see in equity baskets levered to one macro variable. Virtuals’ docs explicitly position $VIRTUAL as the paired asset for launch and liquidity formation.

Finally, do not confuse liquidity lock with price support. A locked pool prevents LP from being yanked. It does not prevent a slow bleed if demand fades. It does not create a cash yield. It simply removes one category of rug risk. That’s valuable, but it’s not a business model.

Risk register: central control of fiscal flows is the dominant risk

The tokenomics here are “simple” in the way many financial products are simple. The instrument is easy to describe. The hard part is enforceability and who has discretion. Our tokenomics methodology treats that discretion as a first-order risk.

Dominant risk: discretionary fee routing and parameter control without tokenholder claims. TIBBIR’s contract supports buy/sell taxes, swapping taxed tokens into the pair token, and sending proceeds to a tax recipient. Those are strong revenue-capture primitives for someone. Yet tokenholders have no default entitlement to those proceeds.

Virtuals’ own docs frame the 1% trading tax as a sustainability mechanism, with post-graduation flows benefiting the agent creator and ACP incentives. That can be perfectly rational from a product standpoint. From a valuation standpoint, it means the most “fundamental” cashflow generated around the asset is explicitly routed away from passive holders.

Even worse for modelability, the contract comment that tax rates are “only ever decreasing” is not enforced in the function body shown. If you are underwriting “taxes can’t be raised,” you are underwriting governance and reputation, not code.

So the question for a serious buyer is not “is there a fee.” It is “is the fee and its routing a credible, stable policy over my holding period, and do I capture any of it.” With public docs that prioritize platform-level descriptions over token-specific parameter readouts, confidence in parameter stability is structurally lower.

  1. Admin-driven tax or routing changes (Trigger: owner/factory updates tax rates, swap thresholds, pool lists, or tax recipient; Mechanism: discretionary control via onlyOwnerOrFactory functions changes effective take-rate or beneficiary; Who bears it: secondary market holders and LPs via worse execution or weaker narrative credibility; Measurable indicators: onchain calls to setProjectTaxRates/setProjectTaxRecipient, changes in tax-swap behavior, sudden changes in transfers to the contract balance).
  2. Platform-correlation drawdowns (Trigger: $VIRTUAL reprices down materially or Virtuals activity declines; Mechanism: agent tokens are designed to pair with and be distributed via $VIRTUAL-based rails, creating a shared risk factor; Who bears it: all agent-token holders, including TIBBIR; Measurable indicators: $VIRTUAL liquidity/volume trend, agent-token DEX liquidity depth versus $VIRTUAL, and broad ecosystem drawdowns across multiple Virtuals agent tokens).
  3. Documentation ambiguity and parameter drift (Trigger: conflicting or updated graduation thresholds and fee policies across official pages; Mechanism: market expectations anchor to docs, but inconsistent thresholds or evolving rules change launch dynamics and perceived fairness; Who bears it: new buyers (mispricing) and existing holders (repricing on policy clarification); Measurable indicators: changes across official whitepaper pages, divergence between stated and observed fee behavior, and governance/FAQ updates that re-define “prototype vs sentient” economics).

If you are building around agent-token launches or trying to harden these flows for investors, this is where design services work pays off. Tighten the constraints, publish live parameter readouts, and make fee routing legible enough that people can underwrite it. That is the difference between “utility framing” and financial substance.



This article is part of our Tokenomics Deep Dive series.