What is a BOA?
A BOA is a Bound Object Asset. It is the current name for the older bPeg/BPeg and UniPeg-style class of balance-bound objects.
The short version:
source-token balance -> supported BOA slots
claim -> specific object IDs
object transfer -> object ID + source-token interval move together
If a wallet holds 10 tokens and a project sets interval = 1 token, the wallet can support 10 BOA objects. If the wallet later drops to 7 tokens, sync applies the BOA lost-support policy to the excess objects.
The core invariant
Every BOA protects this invariant:
valid objects owned by wallet <= floor(sourceToken.balanceOf(wallet) / interval)
Unlike a token-gated NFT mint, BOA ownership stays coupled to live balance. The object and the balance that backs it are intentionally strict.
BOA versus LOA
LOA is the recommended v1.2 path for most projects: unsupported objects become Dormant and can reactivate when support returns.
BOA is harsher: unsupported objects can unbind, burn, or attempt auto-follow depending on launch settings. That can be useful for high-stakes access, diehard-holder mechanics, and historical provenance where loss is part of the design.
Lineage
BOA is the class that contains older Mirage bPeg/BPeg behavior, UniPeg-style objects, and other classic xPeg designs. Those names are historical; new public Mirage launches should use LOA/BOA/soToken language.
Seed modules
Uniswap v4 hooks are one useful seed source, not the whole protocol.
Creators can use seed modules for:
- default transaction-derived seed
- Uniswap v4 swap context
- GameFi actions
- quests or social campaigns
- custom developer modules
Seed modules may influence birth seed, birthPath, provenance, and renderer context. They must not bypass balance capacity, sync, ownership, max object count, or object-plus-interval transfer semantics.
On-chain art policy
Mirage soToken art and renderer output should stay on-chain. Weighted layered rendering is supported through media storage and renderer contracts.