Biconomy (BICO)

Biconomy BICO: Infrastructure for Gas Abstraction and Cross-Chain Execution

Biconomy provides developer infrastructure for smart accounts, sponsored transactions, composable batching, and multi-chain workflows. BICO was introduced as a work and governance token for the protocol, but the current product documentation primarily describes fees and execution in application-level tokens such as USDC, USDT, and other ERC-20 assets.

What Biconomy is building

Biconomy is an infrastructure platform for applications that want blockchain interactions to feel closer to conventional software. Its documentation describes a stack for executing complex workflows across chains, reducing the need for users to manage native gas, and supporting delegated permissions for automated actions. The intended customers are developers and applications rather than end users buying a standalone consumer product. Biconomy offers both a REST-based Supertransaction API and a TypeScript-oriented AbstractJS SDK, allowing teams to choose between a higher-level integration and more direct control over smart-account execution.

The platform’s current architecture is centered on Nexus, an ERC-7579-compliant smart account, and the Biconomy Modular Execution Environment, or MEE. Nexus supplies the account layer, while MEE coordinates execution across chains and manages functions such as gas abstraction, batching, and ordering. Biconomy’s documentation presents these components as a way to combine account abstraction with cross-chain orchestration, rather than treating each blockchain transaction as an isolated user action.

How the execution model works

A typical Supertransaction follows four steps: an application defines a flow, requests a quote, asks the user to sign a payload, and submits the signed request for execution. The flow can contain swaps, bridges, deposits, withdrawals, or arbitrary contract calls. For a smart account, the user can pay fees through a supported token or use a sponsorship arrangement. The API also supports externally owned accounts and EIP-7702 account modes, although those modes have different funding and execution requirements.

Biconomy’s composability work goes beyond simply bundling calls together. Its ERC-8211 documentation describes runtime values, on-chain constraints, and pre- and post-conditions. For example, a batch can resolve a token balance at execution time, use that result in a later transfer, and revert if a minimum balance or recipient condition is not met. This is designed to address a weakness of fixed calldata: a transaction signed earlier may become invalid when balances, prices, bridge delivery, or other state changes before execution.

The role of BICO

BICO is an ERC-20 token launched for Biconomy’s earlier multi-chain relayer model. In the project’s token materials, it was described as a work and governance token intended to support network participants, protocol governance, and the decentralization of relayer infrastructure. Historical staking documentation also described BICO staking as part of a safety module designed to provide coverage against specified shortfall events, including smart-contract, validator-network, and chain-reorganization risks. That material stated that staked balances could be subject to slashing in a qualifying event.

The practical distinction for newcomers is that BICO is not presented in the current developer documentation as the mandatory fee asset for every user transaction. Current guides emphasize payment in USDC, USDT, or another ERC-20 token, or payment through application sponsorship. This suggests that BICO’s role should be assessed separately from the usability features of Biconomy’s infrastructure: the platform can provide gas abstraction without requiring every end user to hold BICO. The economic link between usage of the current stack and demand for BICO therefore requires more evidence than the existence of the infrastructure itself.

Governance and upgrade control

Biconomy’s 2021 governance proposal described a progressive decentralization process. It outlined forum discussion, community calls, formal proposals, Snapshot voting, and subsequent execution by the core team. The same document described token-holder participation in decisions such as supported chains, tokens, product improvements, and growth initiatives. This is evidence of the project’s stated governance design at that time, not proof that every current product or contract upgrade is controlled by token holders.

For users and integrators, upgrade authority matters because the system relies on smart-account contracts, execution modules, APIs, sponsorship accounts, routing services, and supported-chain deployments. The documentation includes migration guidance for account versions, while the API model requires Biconomy endpoints for quotes and execution. These dependencies create practical control points outside the BICO token itself and should be reviewed when evaluating operational resilience or custody assumptions.

Who may use it

Biconomy is aimed at wallet providers, DeFi applications, games, consumer apps, and other teams that want fewer onboarding and transaction-friction points. The documented use cases include sponsored gas, token-based fee payment, batched actions, cross-chain swaps, automated execution, and delegated permissions for agents or bots. Smart Sessions allow an application or agent to receive constrained permissions, such as access to selected contracts, functions, chains, or spending limits, after a user’s approval.

The project documentation reports more than 70 million transactions processed and millions of smart accounts deployed, but these are first-party figures and should be treated as reported platform metrics rather than independent adoption measurements. The documentation also lists integrations and audit claims, yet the scope, dates, versions, and continuing applicability of those claims should be checked against the relevant audit reports and deployed contracts before relying on them for a production system.

Material limitations

Biconomy’s abstraction layer can simplify user experience, but it adds dependencies. A failed quote service, unavailable relayer, unsupported chain, bridge delay, incorrect routing result, sponsor-account problem, or module upgrade can affect execution even when the underlying blockchains remain available. Cross-chain operations also inherit risks from bridges, messaging systems, destination-chain conditions, and differences between account implementations.

The token thesis has a separate unresolved question: how strongly current product usage translates into BICO demand. Historical materials assign BICO roles in governance, staking, incentives, and network fees, while current product guides foreground stablecoins, other ERC-20 fee assets, and sponsorship. Readers should therefore distinguish documented functionality from token value capture and verify the current governance, staking, issuance, contract-administration, and fee arrangements before drawing conclusions about the asset.

Key takeaways

• Biconomy is primarily developer infrastructure for smart accounts, gas abstraction, batching, and cross-chain execution.
• Nexus provides the smart-account layer, while MEE coordinates more complex multi-chain and composable workflows.
• Users may pay fees in stablecoins or other ERC-20 tokens, or have gas sponsored, so BICO is not necessarily required for each transaction.
• BICO was introduced for governance, incentives, staking, and the earlier relayer-network model.
• Current product usage and BICO demand should be analyzed separately because the latest guides do not make BICO the default fee asset.
• Applications remain dependent on Biconomy’s APIs, execution infrastructure, smart contracts, modules, supported chains, and cross-chain services.

Risks and open questions

• The relationship between present-day Biconomy usage and direct BICO demand is not clearly established by the current developer documentation.
• Governance materials reviewed describe a progressive decentralization model in 2021; current voting power, execution authority, and upgrade controls require separate verification.
• Cross-chain execution introduces bridge, messaging, settlement, reorganization, and destination-chain risks.
• API availability, quote accuracy, sponsorship balances, routing, and execution services are operational dependencies for integrations using the higher-level stack.
• Smart-account and execution-module upgrades may create migration, compatibility, or contract-administration risks.
• Historical staking documentation describes possible slashing for qualifying shortfall events; current staking availability and terms should be confirmed before use.