Baseline (B)

Baseline B: An Ecosystem Token Built Around Token-Owned Liquidity

Baseline is an asset-issuance protocol that gives each supported token its own market-making rules, reserve system, and holder utilities. B is the protocol’s ecosystem token, but its value depends on activity, fee routing, contract design, and adoption across Baseline markets.

What Baseline is designed to do

Baseline Markets is built around token-owned liquidity: instead of relying entirely on external liquidity providers or market makers, a supported token launches with protocol-managed liquidity and an onchain market-making system. The project describes this as an end-to-end issuance protocol for creating, trading, staking, borrowing against, and leveraging tokens. Its intended users are token creators seeking a standardized launch system, traders seeking automated markets, and holders who want staking or credit features attached to the token itself.

The core architecture is called Mercury. Baseline says Mercury uses a shared Relay contract deployed at the same address across Ethereum, Base, HyperEVM, and Robinhood Chain, with pools and protocol functions managed through that contract. The documentation also provides a software development kit and command-line interface for launching tokens, reading contract state, and integrating swaps, staking, borrowing, and leverage into applications.

How the market maker and floor mechanism work

Baseline’s named market maker is designed to account for circulating supply rather than treating every reserve unit as immediately available for trading. The documentation describes two reserve areas: a backing pool intended to support the Baseline Value, or BLV, and a buffer pool used for price discovery. As the relationship between reserves and circulating supply changes, the system is intended to move between discovery and floor-protection modes.

The project presents BLV as an onchain redemption floor backed by reserves and says that fees are directed back into the token’s balance sheet. These are protocol design claims rather than a guarantee that a holder can exit at a desired market price: the practical result depends on the relevant contract, reserve asset, circulating-supply accounting, and the continued operation of the deployed pool. Baseline also states that Mercury does not use an external price oracle; prices are derived from reserve state inside the protocol.

What B does inside the ecosystem

B is Baseline’s ecosystem token rather than a generic governance asset described in the reviewed documentation. The project says B itself is a Baseline token and therefore uses the same token-owned-liquidity framework. It also says that protocol fees may support staking, future airdrops, and buybacks, while some projects may pair their own tokens with B. The wording is prospective for some of these mechanisms: fee use and pairing demand should not be treated as guaranteed cash flow or established adoption.

The published tokenomics page lists a total supply of 21,000,000 B, with 12,577,625 described as circulating and 8,422,375 assigned to token-owned liquidity. It lists zero team allocation and zero investor allocation. Those figures are project-published tokenomics, so users should reconcile them with the live token contract and the relevant network deployment before relying on them.

Staking, borrowing, and leverage

BToken holders can stake their tokens to receive a pro-rata share of reserve-denominated protocol fees. Baseline’s staking documentation says rewards depend on the amount staked, the total amount staked, the time a position remains active, and trading volume. The contract reference describes an accumulator-based system that tracks earned rewards rather than promising a fixed yield. This makes realized rewards dependent on actual fee generation and the distribution rules in the deployed contracts.

Mercury also supports borrowing and leverage against bTokens. Baseline describes these positions as having no interest and no liquidation, while charging a one-time origination fee for opening credit exposure. These features add utility but also add smart-contract, reserve, and market-structure dependencies. Borrowing against a token does not remove downside risk: leverage can magnify losses, and the value or liquidity of the collateral can still change materially.

Migration history and control points

Baseline’s migration documentation records a Mercury upgrade on April 20, 2026. It says that YES was migrated from Base to Ethereum Mainnet and rebranded as B on a one-to-one balance basis. The same documentation says Mercury uses new token and pool deployments, meaning contract addresses changed during the migration. This history matters for wallets, integrations, explorers, and dashboards that may still reference legacy addresses.

The reviewed contract overview identifies a protocol treasury and an operations multisig, but it does not establish a broad, token-holder voting system or a fully decentralized upgrade process. The documentation lists the operations multisig as 0x8044f710c58B6eA6a178CC540f9F1Cd758F7d1B2. Users should therefore treat administrative control, deployment changes, pause procedures, and future upgrades as material governance questions until the project publishes clearer authority and change-control details.

Security, dependencies, and open questions

Baseline publishes a security section linking to a Guardian audit of its BToken code. The audit itself states that an assessment is not a warranty that the code is bug-free and does not establish the project’s legal compliance, business model, or economic value. Baseline’s FAQ also says there is no formal insurance fund. The protocol’s safety therefore remains dependent on contract correctness, deployment configuration, reserve handling, administrative controls, and the ability of users to identify the correct current addresses.

The largest unresolved adoption question is whether enough creators, traders, and integrators use Baseline markets to generate meaningful and durable fee activity for B. The project provides APIs and integration tools, but the reviewed material does not independently establish broad usage, sustained liquidity, or a decentralized governance structure. B should therefore be understood as exposure to the Baseline protocol’s execution and adoption, not as a standalone claim on guaranteed revenue.

Key takeaways

• Baseline provides token launches, liquidity management, trading, staking, borrowing, and leverage through its Mercury protocol.
• Its market maker separates reserve backing from price-discovery liquidity and uses circulating supply in its stated pricing design.
• B is the ecosystem token; the project lists a 21,000,000 total supply and describes staking, protocol-fee exposure, and token-owned liquidity as its main roles.
• B’s published value-accrual model depends on activity across Baseline markets, future fee routing, and possible token pairings.
• The April 20, 2026 migration changed token and pool deployments, so legacy and current contract addresses must be distinguished.
• The reviewed materials identify an operations multisig but do not establish broad token-holder governance.

Risks and open questions

• The advertised BLV floor is a contract-level design claim, not protection against all losses, poor execution, reserve problems, or incorrect contract identification.
• B’s fee and value-accrual thesis depends on actual trading volume, adoption, staking participation, and the protocol’s future allocation decisions.
• Mercury uses shared infrastructure and an operations multisig, creating administrative and upgrade-control dependencies.
• Borrowing and leverage can amplify losses even when the protocol advertises no liquidation or interest.
• The front end is closed source according to the project FAQ, increasing the importance of verifying contract calls and addresses independently.
• The published audit does not guarantee bug-free contracts, economic safety, legal compliance, or the absence of future implementation risk.