# Action Logs Source: https://docs.binibit.com/agent-hive/action-logs Every agent action logged on-chain for transparency and audit. ## What it is The `HiveActionLog` contract receives a record of **every action** taken by Workers, Scouts, and Queens. Logs are append-only and public. This is the **transparency mechanism** for the Hive — without it, "agent-managed" would be a black box. With it, every decision is independently verifiable. ## What gets logged | Action | Source agent | Target | | -------------------------------- | ------------ | --------------------------- | | Worker config update | Worker | Self / Pool | | Worker observation | Worker | Pool data | | Scout risk score change | Scout | Agent Token | | Scout flag (rug, wash, sandwich) | Scout | Agent Token | | Scout override on Worker | Scout | Worker (specific Worker ID) | | Queen strategy directive | Queen | All Scouts / All Workers | | Queen suspension | Queen | Worker or Scout | | Queen budget allocation | Queen | Specific pool / sink | | Inter-agent signal | Any | Any | Every entry includes: * Source agent ID (which Queen/Scout/Worker) * Target (which Agent Token, Pool, Worker) * Action type * Action payload (params, scores, etc.) * Reason code * Block number + timestamp * Transaction hash ## Schema ```solidity theme={null} struct ActionLogEntry { uint256 entryId; address sourceAgent; uint8 sourceTier; // 1=Queen, 2=Scout, 3=Worker uint256 targetTokenId; // 0 if not token-specific uint8 actionType; bytes actionPayload; bytes32 reasonCode; uint256 blockNumber; uint256 timestamp; } ``` Indexed by: * entryId (sequential) * sourceAgent * targetTokenId * actionType * block range ## How to read logs Three ways: ### 1. BiniChain explorer [scan.binibit.com](https://scan.binibit.com) — filter `HiveActionLog` contract events by source / target. ### 2. Hive UI The Agent Hive section of docs.binibit.com (or app UI when published) provides a filtered feed: * Per-Agent-Token feed * Per-Worker feed * Global ecosystem feed ### 3. API ``` GET /api/agents/action-logs?tokenId=...&actionType=...&since=... ``` See [API](/agent-hive/api). ## Filterable views Common queries: | Query | Returns | | ------------------------------------- | --------------------------- | | All actions on token X | Per-token activity log | | All overrides in past 24h | Hive-level review | | All Queen actions in past week | Strategic-tier audit | | All Scout flags on token X | Risk history for that token | | All Worker config changes for token X | Per-Worker accountability | Most queries are answered without sustained on-chain calls (cached aggregates), but the underlying source-of-truth is on-chain. ## Why on-chain Off-chain logs would be tamperable. On-chain logs are: * **Immutable** — append-only, cannot be deleted or rewritten * **Verifiable** — anyone can independently query and validate * **Composable** — third-party tools can index and re-surface The cost: gas for every log write. Workers batch their routine observations into periodic summaries to keep gas down. Critical actions (overrides, suspensions) are logged immediately. ## Gas optimization | Log type | Frequency | Gas pattern | | ------------------- | ---------- | ----------------------------------------- | | Worker observations | Continuous | Batched per-block summary (low gas/event) | | Worker actions | On change | One log per change (moderate gas) | | Scout risk score | Periodic | Logged when score crosses threshold | | Scout overrides | Rare | Immediate log (acceptable gas) | | Queen directives | Rare | Immediate log | Total log gas is bounded by Hive policy and is a meaningful but not dominant operating cost. ## Action vs decision Distinguish: * **Decision**: an agent decides to do something * **Action**: that decision becomes an on-chain log entry + (sometimes) a contract call Some decisions don't trigger contract calls (e.g., "I observed nothing unusual"). They are still logged for audit completeness, batched. Agents are required to log decisions even when no action follows — this prevents the "silent withdraw" failure mode. ## Privacy considerations What's NOT in the action log: * User-specific trading patterns (privacy) * Agent's internal model weights / logic versions (operational secrecy until governance approves disclosure) * Off-chain analysis details (only the resulting decision is on-chain) The log records **what was decided + why (reason code)**, not the full causal chain inside the agent. ## Related Where overrides come from Why this matters for users Query the action log Vote based on log evidence # API Source: https://docs.binibit.com/agent-hive/api REST endpoints for the Agent Hive: overview, workers, voting, action logs. ## Endpoints | Method | Path | Description | | ------ | ----------------------------------- | -------------------------------- | | `GET` | `/api/agents/overview` | Hive + Swarm summary | | `GET` | `/api/agents/workers` | List all Workers | | `GET` | `/api/agents/workers/:tokenId` | Worker info for one Agent Token | | `POST` | `/api/agents/workers/:tokenId/vote` | Vote on Worker parameters (L20+) | | `GET` | `/api/agents/action-logs` | Filtered action log query | Base URL: TBD (production), pending mainnet. ## GET /api/agents/overview Hive-level summary including Swarm size. ```json theme={null} { "hive": { "totalTokens": 1523, "totalWorkers": 1523, "totalQueens": 3, "totalScouts": 2 }, "swarm": { "activeWorkers": 284, "lastActivityAt": 1762430000 }, "ecosystem": { "totalAgentTokensSpawned": 1523, "tokensSpawnedLast24h": 12, "tokensSpawnedLast7d": 89, "totalActions24h": 12459, "totalOverrides24h": 17 } } ``` ## GET /api/agents/workers List all Workers with pagination. ### Query parameters | Param | Type | Description | | -------------- | ------- | ------------------------------------------ | | `page` | integer | Page number | | `pageSize` | integer | Max 100 | | `status` | enum | `active` (in Swarm) / `idle` / `suspended` | | `tokenAddress` | address | Filter to one Agent Token | ### Response ```json theme={null} { "items": [ { "workerId": 12345, "agentNftId": 67890, "tokenAddress": "0x...", "tokenSymbol": "PEPEA", "status": "active", "lastActiveAt": 1762429000, "actionCount24h": 27, "config": { "slippageCapBps": 100, "mevProtection": "standard" } } ], "page": 1, "pageSize": 20, "totalItems": 1523 } ``` ## GET /api/agents/workers/:tokenId Detailed Worker info plus recent actions. ```json theme={null} { "worker": { "id": 12345, "agentNftId": 67890, "tokenAddress": "0x...", "deployedAt": 1762344000, "status": "active", "lastActiveAt": 1762429000 }, "config": { "slippageCapBps": 100, "mevProtection": "standard", "signalSubscriptions": ["scout-token-quality", "scout-trading-pattern"] }, "recentActions": [ { "txHash": "0x...", "actionType": "config_update", "params": { "slippageCapBps": 150 }, "reasonCode": "user_vote", "blockNumber": 12345678, "blockTimestamp": 1762429000 } ], "stats": { "totalActions": 27, "lastOverrideAt": 1762400000, "overridingTier": "scout" }, "votes": { "activeProposals": 1, "recentlyClosed": 3 } } ``` ## POST /api/agents/workers/:tokenId/vote Cast a vote on a Worker parameter proposal. **Requires**: * Authenticated user (HMAC signature) * User Level >= 20 * User holds at least 1 of the Agent Token ### Request ```json theme={null} { "proposalId": "abc123", "vote": "yes", "comment": "I think tighter slippage helps" } ``` ### Parameters | Field | Type | Required | Description | | ------------ | ------ | -------- | ------------------------ | | `proposalId` | string | Yes | Active proposal ID | | `vote` | enum | Yes | `yes` / `no` / `abstain` | | `comment` | string | No | Optional public comment | ### Response ```json theme={null} { "voteId": "vote-789", "proposalId": "abc123", "vote": "yes", "weight": 12.5, "txHash": "0x...", "votedAt": 1762430000, "currentTally": { "yesWeight": 145.2, "noWeight": 23.7, "abstainWeight": 8.1, "quorumThreshold": 100, "quorumReached": true, "passingThreshold": 0.6, "currentlyPassing": true } } ``` ### Errors | Code | Message | | ------------------------ | ----------------------------------------- | | 401 UNAUTHORIZED | Bad HMAC | | 403 LEVEL\_TOO\_LOW | User Level \< 20 | | 403 NO\_HOLDINGS | User holds no Agent Token | | 404 PROPOSAL\_NOT\_FOUND | Invalid proposalId | | 409 ALREADY\_VOTED | User already cast a vote on this proposal | | 409 PROPOSAL\_CLOSED | Vote period ended | ## GET /api/agents/action-logs Filtered action log query. ### Query parameters | Param | Type | Description | | ------------ | ------- | -------------------------------------------- | | `tokenId` | integer | Filter to one Agent Token | | `actionType` | enum | `config_update` / `override` / `flag` / etc. | | `sourceTier` | enum | `queen` / `scout` / `worker` | | `since` | integer | Unix timestamp lower bound | | `until` | integer | Unix timestamp upper bound | | `page` | integer | Pagination | | `pageSize` | integer | Max 100 | ### Response ```json theme={null} { "items": [ { "entryId": 12345, "sourceAgentId": "queen-1", "sourceTier": "queen", "targetTokenId": 67890, "actionType": "directive", "actionPayload": { "...": "..." }, "reasonCode": "rug_detected_cluster", "blockNumber": 12345678, "timestamp": 1762429000, "txHash": "0x..." } ], "page": 1, "pageSize": 50, "totalItems": 1234 } ``` ## Rate limits Standard public-API rate limits (60 req/min/IP, see [Rate Limits](/general/rate-limits)). POST endpoints (vote casting) have lower per-user rate limits to prevent vote spam. ## Related What you can vote on Schema deep dive Spawn endpoints HMAC for authenticated routes # Hierarchy Source: https://docs.binibit.com/agent-hive/hierarchy Three-tier override chain: Queen > Scout > Worker. Every override logged on-chain. ## The chain ``` QUEEN (3 instances) ← can override Scouts and Workers │ ▼ SCOUT (2 instances) ← can override Workers │ ▼ WORKER (N instances) ← cannot override anyone ``` ## How decisions flow Two directions: ### Top-down (signals) ``` Queens compute strategy → Signals to Scouts Scouts refine for tokens → Targets to Workers Workers execute → Pool-level actions ``` ### Bottom-up (reports) ``` Workers report status → Aggregate up to Scouts Scouts surface issues → Aggregate up to Queens Queens factor into strategy ``` Both directions run continuously. ## Override mechanics When a higher-tier agent disagrees with a lower-tier action: 1. Lower-tier agent issues a candidate action (e.g., a Worker proposes a pool param update) 2. Higher-tier agent reviews (Scout watches Worker, Queen watches Scout) 3. If override needed, higher-tier emits an `Override` event with reason code 4. The candidate action is replaced (or blocked) by the higher-tier's decision 5. All events logged on-chain via the `HiveActionLog` contract ## Override scope | Tier | Can override | Cannot override | | ------ | --------------- | ------------------------------------- | | Queen | Scouts, Workers | Other Queens (use governance instead) | | Scout | Workers | Queens, other Scouts | | Worker | (Nothing) | Anyone | ## Why hierarchy Three reasons: ### 1. Specialization * Workers know one pool deeply * Scouts compare across many tokens * Queens see the whole ecosystem ### 2. Resilience * A misbehaving Worker can be overridden by a Scout * A misbehaving Scout can be overridden by a Queen * A misbehaving Queen requires Hive-wide governance ### 3. Auditability * Every override is on-chain * Can verify which agent overrode which decision and why * No silent corrections ## Example: hierarchy in action A new Agent Token is spawned with a high-volume sandwich attack pattern within the first hour: ``` 1. Worker observes large sequential trades from suspicious pattern 2. Worker has no intervention authority on its own — flags the pattern 3. Scout running rug-detection picks up the flag + cross-references with similar patterns 4. Scout decides this looks like sandwich farming 5. Scout emits an Override on the Worker's default config — applies tighter MEV protections 6. Queens see the override in their feed; one Queen factors it into ecosystem-level liquidity routing 7. All four actions (Worker flag, Scout decision, Scout override, Queen factoring) logged on-chain ``` The hierarchy acts like a layered defense — no single agent has full authority, but every layer can constrain the layer below. ## Failure modes What happens when an agent fails: | Failure | Recovery | | --------------------- | ------------------------------------------------------------------------------------------------------------- | | Worker crashes | Hive auto-restarts. While down, the Agent Pool runs without Worker management — basic V3 mechanics still work | | Scout crashes | Other Scout takes over. With one Scout, lower analysis depth temporarily | | Queen crashes | Other Queens take over. With two Queens, slightly slower strategic updates | | Multiple agents crash | Worst case: BaiDEX falls back to plain V3 (no agent layer) until restored | ## Worker-only mode (degraded) If both Scouts and all Queens are unavailable, the system runs in **Worker-only mode**: * Workers continue routine actions * No new strategic signals * No cross-pool coordination * Pool params stay at last set values Effectively: BaiDEX becomes Uniswap V3 + still-running Workers. Trading and LP work normally. ## Related Top tier Middle tier Bottom tier Where overrides are recorded # Agent Hive Overview Source: https://docs.binibit.com/agent-hive/overview Hierarchical agent system that runs the BaiDEX agent layer. Queens, Scouts, Workers, Swarm. Tokenomics → Ecosystem Overview shows how the Hive fits into the wider system. ## What the Agent Hive is The Agent Hive is the **registry of all agents and all pools** in the Binibit ecosystem. Three tiers, hive principle: ```mermaid theme={null} flowchart TB Queens["QUEENS (3)

Strategic layer
ecosystem-wide coordination
cross-pool liquidity, risk control,
referral intelligence"] Scouts["SCOUTS (2)

Tactical layer
token analysis, risk scoring,
rug detection, signal generation"] Workers["WORKERS (N)

Execution layer
one per Agent Token
manages Agent Pool, monitors trades,
distributes incentives"] Swarm["SWARM

Active runtime: subset of Workers
currently deployed in the field
Swarm ⊆ Hive"] Queens -- signals --> Scouts Scouts -- targets --> Workers Workers -.- Swarm classDef queen fill:#fce7f3,stroke:#db2777,color:#831843 classDef scout fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef worker fill:#dcfce7,stroke:#16a34a,color:#14532d classDef swarm fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e class Queens queen class Scouts scout class Workers worker class Swarm swarm ``` Override chain: **Queen > Scout > Worker**. Every override is logged on-chain. ## Inside the docs Override chain and decision flow Strategic agents — 3 instances Tactical analysts — 2 instances Per-token executors — N instances Active runtime layer On-chain transparency User governance, Level 20+ gate /api/agents/\* endpoints How agent actions are verifiable ## Lifecycle ``` Spawn Agent Token → Worker created → Worker joins Swarm → Swarm reports to Scouts (eventually) → Scouts report to Queens → Queens coordinate strategy → Strategy flows back as signals → Workers act on signals ``` Continuous loop. No external trigger needed beyond user activity (spawns, swaps, LP). ## Related Where Agent Tokens spawn Where Workers manage liquidity How Hive activity drives sinks Where action logs live # Agent Queens Source: https://docs.binibit.com/agent-hive/queens Strategic-tier agents — 3 instances managing ecosystem-wide coordination. ## Role Agent Queens are the **strategic layer** of the Hive. There are exactly **3 Queens** in the deployed system. Their domain: * **Cross-pool liquidity** — where should capital flow across all pools? * **Risk control** — what's the systemic exposure to one Agent Token's collapse? * **Referral intelligence** — patterns in CRS referral activity, fraud signals * **Strategy coordination** — set the agenda Scouts and Workers follow Queens do **not** monitor individual pools — that's Workers' job. Queens see the **shape of the system** and steer accordingly. ## Why 3 (and not 1, 2, or 5) 3 is the minimum for **majority decision-making with fault tolerance**: ``` 1 Queen: single point of failure, no override on Queen-level decisions 2 Queens: deadlocks possible (1 vs 1) 3 Queens: simple majority resolves disagreements (2 vs 1) 5 Queens: more resilient but more coordination overhead ``` The choice of 3 trades resilience for simplicity. Changing this number requires Hive-wide governance. ## Inputs Queens receive: * Aggregated signals from both Scouts * Worker-level metrics (depth, volume, holder distribution per pool) * BiniChain on-chain data (block times, gas prices, transaction patterns) * BaiDEX TVL trends across pools * Bini App user activity signals (Scouts can pass these up) ## Outputs Queens emit: * **Strategy directives** to Scouts (e.g., "focus this week on detecting wash trading on memecoin pools") * **Override decisions** on Scouts (rare; reserved for clear miscalibration) * **Liquidity rebalancing recommendations** (advisory, not direct execution) * **Suspension proposals** for misbehaving Scouts or Workers All outputs are logged on-chain. ## Decision quorum Some Queen-level actions require a majority (2 of 3) vote: * Suspending a Scout * Suspending a Worker via cross-pool decision * Allocating Hive-wide budget (incentives to LP boostrap, etc.) Other actions are independent (a single Queen can act, with the other Queens watching for over-corrections): * Strategy directives * Routine signal generation ## Strategic horizon Queens think in **multiple time horizons**: | Horizon | What's analyzed | | --------------------------- | ----------------------------------------------------- | | Real-time (seconds-minutes) | Spike events, sudden TVL changes | | Short (hours-days) | Volume trends, new tokens reaching velocity | | Medium (days-weeks) | Liquidity migration patterns, sink/emission ratios | | Long (weeks+) | Holistic ecosystem health, sandbox→mainnet transition | Different Queens may specialize in different horizons (TBD per implementation). ## Visibility Queens are the **most visible** agents in the system because their actions affect everyone: * Action log entries surface in BaiDEX UI as system-level events * Strategic directives are summarized in periodic Hive reports (e.g., weekly digest) * Queens have public profiles in the Hive UI This visibility is by design — concentrated authority needs concentrated transparency. ## Constraint vs latitude What Queens can do: | | Latitude | | ------------------------------------- | ------------------------------------------ | | Strategy directives | Wide — any direction within Hive's purpose | | Override Scouts | Wide | | Suspend Workers | Wide (for cause) | | Allocate emission within Rewards pool | Wide (within monthly budget) | | Modify Hive contracts | None — requires governance | | Custody user funds | None — agents never custody | | Modify Agent Token logic | None — tokens are immutable post-spawn | ## Related Override chain What Queens direct Where Queen actions are recorded How Queen actions are verifiable # Agent Scouts Source: https://docs.binibit.com/agent-hive/scouts Tactical-tier agents — 2 instances handling token analysis and signal generation. ## Role Agent Scouts are the **tactical layer** of the Hive. There are exactly **2 Scouts** in the deployed system. Their domain: * **Token analysis** — assess each Agent Token's risk, liquidity, holder distribution * **Risk scoring** — generate per-token risk scores * **Rug detection** — pattern-match against known rug signatures * **Signal generation** — produce signals that Workers can react to Scouts sit between the strategic Queens and the executional Workers — they specialize in **per-token tactical assessments** at scale (across all spawned Agent Tokens). ## Why 2 (and not 1 or 3) 2 Scouts is the minimum for **redundancy without coordination overhead**: * 1 Scout: single point of failure * 2 Scouts: redundant; can split workload (e.g., one focuses on memecoins, one on utility tokens) * 3+ Scouts: redundancy gain marginal; more inter-agent coordination cost The choice of 2 is calibrated to current expected token volume. Scaling up the number is a Hive governance decision. ## Inputs Scouts receive: * Real-time signals from all Workers (one per Agent Token) * BaiDEX pool depth + volume data * BiniChain transaction patterns (large transfers, contract interactions) * Strategic directives from Queens * Bini App user signals (Scout sees user-level patterns when relevant) ## Outputs Scouts emit: * **Risk scores** per Agent Token (visible to users) * **Tactical signals** to Workers (e.g., "dampen sandwich exposure on USBI/PEPEA pool") * **Override decisions** on Workers (rare; reserved for clear misbehavior) * **Flag reports** to Queens (when patterns require strategic attention) * **Rug warnings** (visible to traders before/at rug events) ## Specialization The two Scouts may specialize: | Specialization (illustrative) | Focus | | ----------------------------- | -------------------------------------------------------------- | | Token-quality Scout | Holder distribution, contract verification, founder reputation | | Trading-pattern Scout | Wash trading, sandwich attacks, spoofing | Both have full coverage as fallback. The split is for analytical depth, not exclusivity. ## Detection patterns Common rug / abuse patterns Scouts watch for: | Pattern | Signal | | ---------------------------------------------- | --------------------------------- | | Single holder >50% supply about to LP-yank | Flag at orange | | Sudden coordinated buys (sybil-like signature) | Flag at yellow | | LP withdrawn without notice (potential rug) | Flag at red — surface immediately | | Wash trades inflating volume | Flag at orange | | New token getting outsized boost spend | Flag for review | These flags surface in: * BaiDEX UI as a "Scout Risk Score" badge on the pool * Trader alerts (if subscribed) * Worker overrides (e.g., tighten slippage protection) * Queen reports (for strategic review) ## Cooldown / re-evaluation A Scout's risk score is **not static**. As more data accumulates: * A red flag can de-escalate to orange or yellow if patterns stabilize * A green status can elevate to orange if new concerning patterns emerge * Re-evaluation runs at least once per hour, more often for high-activity tokens ## Constraint vs latitude What Scouts can do: | | Latitude | | ----------------------- | ------------------------- | | Risk scoring | Full | | Signal generation | Full | | Override Worker actions | Wide (for cause, logged) | | Suspend a Worker | None — that's Queen-level | | Modify pool contracts | None | | Custody user funds | None | ## Visibility Scout outputs are user-visible: * Risk scores shown next to every Agent Pool on BaiDEX * Rug warnings on the AgentT Launchpad explorer * Signal feed for traders who want to follow Scout calls The visibility is partly the value — Scouts work because users factor their assessments into trading decisions. ## Related Override chain Direct Scouts strategically React to Scout signals Where Scout decisions are recorded # Trust Model Source: https://docs.binibit.com/agent-hive/trust-model How agents are accountable: action logs, hierarchy, hard contract limits, user governance. ## What "trustless agents" means here Agents in the Hive are **not custodial**. They cannot: * Withdraw user funds * Move LP positions * Mint or burn tokens beyond the standard sink mechanisms * Pause pools * Modify Agent Token contracts Their authority is **bounded** to specific advisory and governance actions on the agent layer. This bounding is enforced **at the contract level** — the V3 pool contracts don't have privileged roles for agents. Workers, Scouts, Queens have no special permissions on user funds. ## The four trust pillars Trust in the Hive comes from four mechanisms working together: ```mermaid theme={null} flowchart LR Limits["Hard contract limits
(No fund custody,
no token modify)"] Logs["On-chain action logs
(Every decision recorded,
append-only)"] Hierarchy["Hierarchy + override
(Each tier checks below;
visible overrides)"] Governance["User governance
(L20+ votes on params,
Hive multisig for upgrades)"] Limits --> Trust["Trustworthy agents"] Logs --> Trust Hierarchy --> Trust Governance --> Trust classDef pillar fill:#dcfce7,stroke:#16a34a,color:#14532d classDef goal fill:#fce7f3,stroke:#db2777,color:#831843 class Limits,Logs,Hierarchy,Governance pillar class Trust goal ``` ### 1. Hard contract limits Agents cannot do what isn't permitted by the contracts themselves. No off-chain "trust me" — just on-chain enforcement. ### 2. On-chain action logs Every decision is permanently recorded. No "the agent said X but did Y" — the log is canonical. See [Action Logs](/agent-hive/action-logs). ### 3. Hierarchy + override Every action can be overridden by a higher-tier agent (Queen > Scout > Worker), and every override is also logged. No silent corrections. See [Hierarchy](/agent-hive/hierarchy). ### 4. User governance Token holders at L20+ vote on Worker parameters. Hive-level decisions go to multisig + governance. Users have direct influence on agent behavior. See [Voting](/agent-hive/voting). ## What can still go wrong Trust mechanisms reduce risk, but don't eliminate it. Realistic risks: | Risk | Mitigation | Residual | | ------------------------------------ | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Agent code bug causes wrong decision | Action log makes bug visible; Queen override patches behavior; full code audit before mainnet | Possible until exhaustively tested | | Coordinated agent collusion | Multi-tier hierarchy and multisig governance; cross-tier overrides | Low probability, hard to fully eliminate | | Hive infrastructure compromise | Off-chain components could be attacked but cannot custody funds; degraded mode keeps swaps working | Possible; degrades to "no agents" mode | | User vote manipulation (sybil) | L20 gate, NFT + holdings weight | L20+ sybil farming theoretically possible at very high cost | | Queen abuse of override | Multisig for budget actions; override actions logged with reason; Hive governance can suspend Queens | Low — Queens have skin in the game (reputation) | ## Why "agent-managed" not "AI-managed" Choice of language matters: | | "AI-managed" | "Agent-managed" | | --------------------- | --------------------------------------------------- | -------------------------------------------------- | | Implies | Black-box LLM with judgment | Hierarchical, bounded, logged system | | Regulator-comfortable | No (AI advisor on financial decisions = scrutiny) | Yes (clear constraints, accountability mechanisms) | | User-comfortable | Variable — "AI" connotes magic and unaccountability | Higher — "agent" implies bounded role | | Tech-accurate | Inaccurate (the system isn't autonomous LLM) | Accurate (it IS bounded agents in a hierarchy) | For these reasons, public copy uses "agents" / "hive" / "swarm" / "hive principle" — never "AI" or "LLM". The implementation may use ML internally (some Scouts may be LLM-powered, some Workers may use heuristic models), but the externally visible system is a **bounded multi-agent system**, not "AI making decisions". See [Branding rule in plan](https://github.com/Binibit/docs). ## Public audit and disclosure Pre-mainnet: * Smart contracts audited by independent firm (TBD which) * Action log schema published and stable * Hive policy parameters published * Override logic in code, not behind closed doors Post-mainnet: * Action logs continuously inspectable * Quarterly Hive operating reports (governance summary, suspension events, vote outcomes) * Public bug bounty program * Open-source repository (timing TBD) ## Bug bounty A bug bounty program will run pre and post mainnet for: * Smart contract vulnerabilities (highest reward) * Off-chain Hive infrastructure exploits * Action log tampering or omission * User governance bypass Specifics will be published when the program launches. ## Related On-chain transparency Override mechanics User governance Where contract limits are enforced # Voting & Governance Source: https://docs.binibit.com/agent-hive/voting User-driven governance over Worker parameters. Level 20 gate, NFT-weighted votes. ## What you can vote on At **Level 20+**, users can vote to adjust **Worker parameters** for any Agent Token they hold. Examples: | Voting topic | Effect | | ----------------------- | ----------------------------------------------------- | | Slippage cap (advisory) | Tighten or loosen Worker's recommended slippage range | | MEV protection level | Increase / decrease default protection | | Signal subscription set | Which Scouts the Worker listens to | | Boost responsiveness | How aggressively the Worker promotes the token | Votes are **per Agent Token** — your vote on Token A doesn't affect Token B's Worker. ## Level 20 gate The L20 gate exists because: 1. **Engagement signal** — voters have demonstrated commitment via XP 2. **Anti-sybil** — reaching L20 requires meaningful CRS spend, hard to fake at scale 3. **Quality** — L20+ users typically understand the system well enough to vote informedly Below L20, users can read voting outcomes but cannot vote. ## Vote weight Three sources of vote weight (combined): ``` your_weight = level_weight + nft_weight + holdings_weight level_weight = your level value (20-30 maps to 1-10) nft_weight = number of Agent NFTs you own (registry NFTs) holdings_weight = log10(your token holdings) — caps influence of mega-holders ``` The exact formula is set by Hive governance and may evolve. The intent is: * Higher level → more weight (engagement reward) * More agent NFTs → more weight (creator reward) * More holdings → more weight, but log-scaled (no whale dominance) ## Quorum and threshold A vote passes when: * **Quorum reached** — minimum % of eligible vote weight participates * **Threshold reached** — % "yes" of votes cast (typically 60%) If quorum is not reached by deadline, the vote fails (status quo holds). Specific quorum/threshold values are set by governance and may differ for different proposal types. ## How to vote ### From Bini App 1. Open Bini App → Hive section 2. Browse "Active votes" for tokens you hold 3. Tap to read details and reasoning 4. Cast your vote (yes / no / abstain) ### From the BaiDEX UI Each Agent Pool page shows: * Active votes for the Worker managing this pool * Recent votes and outcomes * Vote button (gated by L20 + token holdings) ### Via API `POST /api/agents/workers/:tokenId/vote` — see [API](/agent-hive/api). ## Vote duration Default vote duration: 7 days. Some urgent votes (security-related) can be shortened to 24 hours by Hive emergency governance. ## What you cannot vote on | | Can vote? | | -------------------------------------- | ----------------------------- | | Worker advisory params (slippage, MEV) | **Yes** | | Worker logic / code | No (Hive governance) | | Suspending a Worker | No (Hive governance only) | | Spawning new agents | No (automatic at token spawn) | | Modifying Hive contracts | No (multisig + governance) | | Changing fee structure | No (Hive governance) | User voting is **scoped to per-Worker tunables** — the parameters that affect operations without changing the protocol. ## Override by higher tiers Even if a vote passes, **Queens can override** via the standard hierarchy mechanism (logged on-chain). The override is justified by reason code (e.g., "User vote conflicts with Hive risk policy"). This sounds restrictive but is necessary — without it, holders of a token could vote to disable rug-detection on their own token. In practice, Queen overrides on user votes should be rare and well-motivated. ## Voting history All votes are logged on-chain. The action log shows: * Proposal creation * Each vote cast (anonymized: weight + direction, not user identity unless self-disclosed) * Vote outcome * Any subsequent override You can audit any vote's fairness by reading the log. ## Tokenomics impact Voting itself doesn't burn or sink BINI. It is a **user-engagement mechanism** that increases the value of being engaged in the ecosystem (more participation in agent-level governance). Indirectly, well-tuned Workers improve pool health, which drives volume, which drives BaiDEX swap burns. So voting indirectly contributes to deflationary pressure. ## Related Vote via API Vote history L20 gate context NFT for vote weight # Agent Workers Source: https://docs.binibit.com/agent-hive/workers Execution-tier agents — one per Agent Token, manages the Agent Pool. ## Role Agent Workers are the **execution layer** of the Hive. There is **one Worker per Agent Token** (N total, scaling with Launchpad activity). Each Worker: * Monitors its assigned Agent Pool's depth and trade flow * Receives signals from Scouts and Queens * Executes pool-parameter adjustments within Hive policy * Distributes incentives (LP rewards, etc.) according to per-pool config * Logs all actions on-chain A Worker does **not** custody user funds. LPs and traders interact with V3 contracts directly. ## Lifecycle ``` Spawn Agent Token → Worker created with default config → Worker joins active Swarm → Worker begins monitoring → Worker reacts to Scout/Queen signals → (over time) Worker adjusts pool params → Worker logs all actions on-chain ``` If the Agent Token becomes dormant (no activity for an extended period), the Worker is **retired** to free resources. It can be reactivated when activity resumes. ## What Workers can do Workers have a bounded set of allowed actions: | Action | Scope | | ------------------------------------------------ | -------------------------------- | | Update pool MEV protection params | Within bounds set by Hive policy | | Adjust slippage caps for routed trades | Within Hive bounds | | Subscribe to Scout signal streams | Yes | | Distribute pool-level incentives | Per pool config | | Log observations (depth, volume, trade patterns) | Yes | | Override traders' slippage tolerance | **No** | | Cancel LP positions | **No** | | Withdraw user funds | **No** | | Modify the Agent Token contract | **No** | | Mint or burn tokens beyond standard sinks | **No** | The "**No**" list is enforced at the contract level — Workers have no privileged role on either the token or pool contracts. ## Defaults vs Hive policy Each Worker has a **default config** at spawn: ``` Slippage cap (advisory): 0.5%-2.0% range MEV protection level: standard Volume monitoring window: 1 hour rolling Signal subscription: all standard Scouts ``` These can be **adjusted by Hive policy** (Queens and Scouts can tighten/loosen limits) and **adjusted by user vote** (token holders at L20+ can vote on Worker params for tokens they hold). ## Per-token visibility For the Agent Token's owner (the spawner) and for token holders: * Worker management page shows current config, recent actions, status * Action log filtered to actions affecting their pool * Voting interface (at L20+) for adjusting Worker params The visibility is per-token, but the underlying Worker logic is shared across all Workers (same code, different config + state). ## Worker scaling As Launchpad activity grows: | Active Agent Tokens | Workers running | Compute footprint | | ------------------: | --------------: | ------------------------------------ | | 100 | 100 | Small | | 1,000 | 1,000 | Moderate | | 10,000 | 10,000 | Large (requires multi-instance Hive) | | 100,000+ | 100,000+ | Will need Worker pooling / sharding | Hive infrastructure scales horizontally — adding more compute lets more Workers run concurrently. The architecture allows future migration to shared Worker pools (one Worker process serves multiple low-activity tokens) when scale demands. ## Worker performance signals Workers' own performance is **monitored by Scouts**. Metrics include: * Reaction time to signals * Override frequency from upper tiers * Pool health under Worker management * Log completeness Underperforming Workers can be: * **Re-configured** (default config tightened) * **Suspended** by Queens (rare; for clear misbehavior) * **Retired** (token dormant; resources freed) ## Why one-per-token The 1:1 mapping ensures **clear accountability**: * For every Agent Token, exactly one Worker is responsible * Token owner knows whom to look at for Worker activity * Action logs are unambiguous per pool * Performance metrics are per-Worker Pooling Workers (one Worker for many tokens) would dilute accountability and complicate the action log. ## Cross-product touchpoints A Worker's lifecycle spans three subsystems: | Touchpoint | System | Page | | ---------------------------- | ---------------- | ---------------------------------------------------------------------------------------------- | | Created at Token spawn | AgentT Launchpad | [Spawn flow](/agentt-launchpad/spawn-flow), [Auto-Worker](/agentt-launchpad/auto-worker) | | Manages an Agent Pool | BaiDEX | [Pools](/baidex/pools), [Liquidity](/baidex/liquidity) | | Logs every action on-chain | BiniChain | [Block explorer](/binichain/explorer), [Action logs](/agent-hive/action-logs) | | Token holders vote on params | Bini App + Hive | [Voting](/agent-hive/voting), [Levels (L20+ gate)](/bini-app/levels) | | Reports to Scouts and Queens | Agent Hive | [Hierarchy](/agent-hive/hierarchy), [Scouts](/agent-hive/scouts), [Queens](/agent-hive/queens) | ## Related Override chain Active Workers right now User governance over Worker params Worker accountability Where Workers get assigned What Workers manage # Agent Pool (Auto-listing) Source: https://docs.binibit.com/agentt-launchpad/agent-pool Spawning an Agent Token automatically creates a V3 pool on BaiDEX. ## What happens at spawn When `HiveSpawner` deploys your Agent Token, it also calls the BaiDEX V3 factory to create an **Agent Pool**: ``` factory.createPool( agentToken, // your new token poolSide, // wBINI or USBI (chosen at spawn) feeTier // 10000 (1.00%) — BaiDEX single tier ) ``` The pool is created with **zero initial liquidity**. You (or other LPs) must deposit to bootstrap trading. ## Choosing the pool side | Pool side | Pros | Cons | | ------------------ | ----------------------------------------------------------- | --------------------------------------------------------------- | | **USBI** (default) | Lower volatility, scales with user base, abundant liquidity | Less direct BINI exposure | | **wBINI** | Direct BINI exposure, premium positioning | wBINI cap means available wBINI is limited; harder to bootstrap | 90%+ of new Agent Tokens use **USBI**. wBINI is for premium projects with curated LP partners. Choose at spawn time. You can later create a second pool on the other side (manually, not via Spawner) if you want both. ## V3 fee tier BaiDEX uses a **single fee tier of 1.00%** (10,000 in V3 fee-tier units). All Agent Pools are at this tier. This is in contrast to Uniswap V3 which has 0.05 / 0.30 / 1.00% tiers — BaiDEX simplified to one. See [BaiDEX → Fees](/baidex/fees). ## Initial price The pool is created with **no initial price** (zero liquidity → no price). The first LP to deposit sets the initial price by their deposit ratio. Example: ``` You deposit: 100,000 AgentToken + 100 USBI Implied price: 1 AgentToken = 0.001 USBI (per simple V3 formula) ``` Choose your initial deposit ratio carefully — it sets the starting price reference. ## Agent Worker assignment In parallel with pool creation, an [Agent Worker](/agentt-launchpad/auto-worker) is assigned to your Agent Token. The Worker monitors **all pools** containing the token but typically there's just one (the auto-listed pool). If you create additional pools (different side, different chain), the Worker covers them too. ## Pool address discovery After spawn, the pool address is: * Returned in the spawn transaction's logs * Published on the AgentT Launchpad detail page for your token * Indexed by the V3 factory (queryable via `factory.getPool(tokenA, tokenB, fee)`) ## Adding liquidity After spawn, to bootstrap trading: 1. Approve your Agent Token + USBI/wBINI to the V3 position manager 2. Mint a position in your chosen price range 3. Provide initial liquidity (typically the spawner's full holdings + matched USBI side) For step-by-step LP details, see [BaiDEX → Liquidity](/baidex/liquidity). ## Pool visibility on BaiDEX Your Agent Pool appears on the BaiDEX UI: * In the pair selector when users browse Agent Tokens * With the Worker status badge attached * With recent action log entries from the Worker The pool is **public** — anyone can see, swap, LP. There is no allowlist. ## Listing on aggregators Once the pool has meaningful TVL, it may surface on: * BaiDEX's own pair list * Third-party DEX aggregators (1inch, ParaSwap if integrated) * DefiLlama (if eligible) These are **discovery layers**, not native BaiDEX features. Listing on aggregators depends on each aggregator's policies. ## Related All pool types LP rules Worker assigned in parallel The full pipeline # Agent Token (ERC-20) Source: https://docs.binibit.com/agentt-launchpad/agent-token ERC-20 token deployed by the Spawner contract. Standard interface plus registry hooks. ## What it is An Agent Token is a **standard ERC-20** deployed by the `HiveSpawner` contract on BiniChain. The contract is the `SpawnedERC20` template, which extends OpenZeppelin's ERC-20 with: * Owner role (initially the spawner; transferable; renounceable) * Registry hooks for the `HiveRegistry` ERC-721 NFT system ## Default parameters | Parameter | Default | Configurable at spawn? | | -------------------- | ------------------------------------------- | ---------------------- | | Decimals | 18 | No (fixed at 18) | | Total supply | 1,000,000,000 (1B) | Yes | | Name | (user-provided) | Yes | | Symbol | (user-provided, 3-5 chars) | Yes | | Mintable post-spawn? | No | (immutable) | | Burnable? | Yes (any holder can burn their own balance) | (immutable) | | Pausable? | No | (immutable) | | Initial holder | The spawner address | (immutable) | ## Standard ERC-20 interface Implements the full ERC-20 interface: ```solidity theme={null} function totalSupply() external view returns (uint256); function balanceOf(address account) external view returns (uint256); function transfer(address to, uint256 amount) external returns (bool); function allowance(address owner, address spender) external view returns (uint256); function approve(address spender, uint256 amount) external returns (bool); function transferFrom(address from, address to, uint256 amount) external returns (bool); event Transfer(address indexed from, address indexed to, uint256 value); event Approval(address indexed owner, address indexed spender, uint256 value); ``` Plus extensions: ```solidity theme={null} function burn(uint256 amount) external; function burnFrom(address account, uint256 amount) external; function owner() external view returns (address); function renounceOwnership() external; function transferOwnership(address newOwner) external; ``` ## Owner powers The token owner (initially you, the spawner) can: * Transfer ownership to another address * Renounce ownership (set to zero address — immutable forever) The owner **cannot**: * Mint additional supply (no mint function) * Pause transfers * Blacklist addresses * Change fee logic (no fee on the token itself; BaiDEX swap fees are at pool level) This minimal owner-power design is by choice — it makes Agent Tokens more credibly neutral than launchpad tokens with admin fees. ## Renouncing ownership Best-practice for credibly-neutral tokens: ```solidity theme={null} agentToken.renounceOwnership(); ``` Once renounced, no further owner actions are possible. The token is fully immutable. ## Burning Anyone can burn their own balance: ```solidity theme={null} agentToken.burn(amount); ``` Note: BaiDEX's 0.25% trade burn applies to the **swap input asset**. If you swap an Agent Token into wBINI, the burn applies to the Agent Token itself — supply decreases organically with trade volume. ## Holders Initial holder: the spawner (you), with 100% of supply. You'll typically want to: * Provide LP on BaiDEX (your tokens become tradable) * Distribute via airdrop, sale, or community grants * Keep some for treasury / future use Holder distribution is up to you. Public block explorer ([scan.binibit.com](https://scan.binibit.com)) shows current top holders for any Agent Token. ## Registry NFT Every Agent Token also has a corresponding **Agent NFT** in the `HiveRegistry` (ERC-721 + ERC-8004). The NFT represents the agent assignment — it tracks: * Which Agent Token it covers * Which Worker is assigned * Action log references * Metadata (description, links) See [Agent NFT registry](/agentt-launchpad/registry). ## Verifying an Agent Token Before interacting with an Agent Token (LP, buy, sell): 1. Look it up on `scan.binibit.com` 2. Verify it was deployed by `HiveSpawner` (contract address visible) 3. Check the `Spawned` event for owner and metadata 4. Confirm reasonable holder distribution (no single mega-holder typically — risk indicator) 5. Check the Worker action log for any flagged behavior ## Related How tokens get deployed Where the token trades The agent NFT The Worker assigned to your token # API Source: https://docs.binibit.com/agentt-launchpad/api REST endpoints for spawning, listing, and inspecting Agent Tokens. The Launchpad API is part of the broader Binibit ecosystem API. The endpoints below are documented per the canonical spec. Final base URL and auth requirements ship with mainnet. ## Endpoints | Method | Path | Description | | ------ | ---------------------------------- | ------------------------------------ | | `POST` | `/api/launchpad/spawn` | Spawn a new Agent Token | | `GET` | `/api/launchpad/tokens` | List all Agent Tokens | | `GET` | `/api/launchpad/tokens/:id` | Get details for one Agent Token | | `GET` | `/api/launchpad/tokens/:id/pool` | Get pool details for one Agent Token | | `GET` | `/api/launchpad/tokens/:id/worker` | Get Worker info for one Agent Token | Base URL: TBD (production), pending mainnet. ## POST /api/launchpad/spawn Spawn a new Agent Token. Requires authenticated user (HMAC signature, see [Authentication](/general/authentication)). ### Request ```json theme={null} { "name": "PepeAgent", "symbol": "PEPEA", "totalSupply": "1000000000", "decimals": 18, "poolSide": "USBI", "metadata": { "description": "An agent-managed Pepe-themed token", "logoUri": "ipfs://...", "website": "https://example.com" } } ``` ### Parameters | Field | Type | Required | Description | | ------------- | ------- | -------- | ---------------------------------- | | `name` | string | Yes | Display name (max 50 chars) | | `symbol` | string | Yes | Ticker (3-5 uppercase chars) | | `totalSupply` | string | No | Default: 1,000,000,000 | | `decimals` | integer | No | Default: 18 (fixed) | | `poolSide` | enum | No | `USBI` (default) or `wBINI` | | `metadata` | object | No | Free-form metadata stored on-chain | ### Response ```json theme={null} { "token": { "address": "0xAgent...", "name": "PepeAgent", "symbol": "PEPEA", "totalSupply": "1000000000", "owner": "0xCreator..." }, "pool": { "address": "0xPool...", "side": "USBI", "feeTier": 10000 }, "worker": { "id": 12345, "agentNftId": 67890 }, "txHash": "0xtx..." } ``` ### Errors | Code | Message | | --------------------- | -------------------------------------------- | | 400 INVALID\_SYMBOL | Symbol does not match `[A-Z]{3,5}` | | 400 SYMBOL\_TAKEN | Symbol already exists on BiniChain | | 400 COOLDOWN\_ACTIVE | Spawn cooldown still active for this address | | 402 INSUFFICIENT\_FEE | BINI sent does not cover the spawn fee | | 500 SPAWNER\_FAILED | Spawner contract reverted (rare; retry) | ## GET /api/launchpad/tokens List Agent Tokens with pagination and filters. ### Query parameters | Param | Type | Description | | ---------- | ------- | --------------------------------------- | | `page` | integer | Page number (1-indexed) | | `pageSize` | integer | Items per page (max 100) | | `sort` | enum | `recent` / `volume` / `tvl` / `holders` | | `boosted` | boolean | Filter to boosted tokens only | | `poolSide` | enum | `USBI` / `wBINI` filter | ### Response ```json theme={null} { "items": [ { "address": "0x...", "symbol": "PEPEA", "name": "PepeAgent", "spawnedAt": 1762344000, "tvl": "12345.67", "volume24h": "5432.10", "holders": 42, "workerStatus": "active", "boosted": false } ], "page": 1, "pageSize": 20, "totalItems": 156 } ``` ## GET /api/launchpad/tokens/:id Detailed info for one Agent Token. `:id` can be the Agent Token address or its registry NFT ID. ### Response ```json theme={null} { "token": { "address": "0x...", "name": "PepeAgent", "symbol": "PEPEA", "decimals": 18, "totalSupply": "1000000000", "owner": "0x...", "spawnedAt": 1762344000 }, "pool": { "address": "0x...", "side": "USBI", "feeTier": 10000, "tvl": "12345.67", "volume24h": "5432.10", "lastTradeAt": 1762430000 }, "worker": { "id": 12345, "agentNftId": 67890, "status": "active", "lastActionAt": 1762429000, "actionCount": 27 }, "metadata": { "description": "...", "logoUri": "ipfs://...", "website": "..." }, "boost": { "active": false, "tier": null, "expiresAt": null } } ``` ## GET /api/launchpad/tokens/:id/worker Detailed Worker info plus action log. ```json theme={null} { "worker": { "id": 12345, "agentNftId": 67890, "status": "active", "deployedAt": 1762344000 }, "recentActions": [ { "txHash": "0x...", "actionType": "param_update", "params": { "...": "..." }, "blockNumber": 12345678, "blockTimestamp": 1762429000 } ], "stats": { "totalActions": 27, "lastActiveAt": 1762429000 } } ``` ## Rate limits Standard public-API rate limits apply (60 req/min per IP, see [Rate Limits](/general/rate-limits)). For builder integrations needing higher throughput, contact [api@binibit.com](mailto:api@binibit.com). ## Related What POST /spawn triggers HMAC for authenticated routes Worker / governance endpoints The NFT data model # Auto-Worker Assignment Source: https://docs.binibit.com/agentt-launchpad/auto-worker Every Agent Token gets an Agent Worker assigned at spawn. Worker joins the active Swarm. ## What happens at spawn When `HiveSpawner` deploys your Agent Token, it immediately calls into the `HiveRegistry` to **assign an Agent Worker**: ```mermaid theme={null} flowchart LR Spawn["HiveSpawner.spawn()"] --> Token["Deploy Agent Token
(ERC-20)"] Token --> Registry["HiveRegistry.assignWorker(token)"] Registry --> Worker["Worker created /
activated"] Worker --> Swarm["Worker joins
active Swarm"] classDef contract fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef hive fill:#fef9c3,stroke:#ca8a04,color:#713f12 class Spawn,Token,Registry contract class Worker,Swarm hive ``` The assignment is **automatic** — you don't pick a Worker, configure it, or wait for approval. ## What the Worker does The Worker is a programmatic agent that: | Function | Where | | --------------------------------------------- | ------------------------------------- | | Monitors your Agent Pool depth | BaiDEX V3 pool | | Tracks trade flow patterns | On-chain events | | Receives signals from Agent Scouts | Inter-agent message bus | | Receives strategy from Agent Queens | Inter-agent message bus | | Logs actions on-chain | HiveRegistry / dedicated log contract | | Executes parameter updates within Hive policy | Pool-related actions only | The Worker **does not** custody user funds. It does not have control over the token contract or pool LP positions. It is an **advisory + governance** layer that influences pool parameters, surfaces signals, and provides transparency. ## What the Worker cannot do To bound risk, Workers are explicitly prevented from: * Withdrawing user LP positions * Burning Agent Token outside the standard sink mechanisms * Transferring tokens between addresses * Pausing the pool * Modifying the Agent Token's ERC-20 logic These restrictions are at the contract level — the Worker has no privileged role on the Agent Token or the pool itself. ## Worker lifecycle | Phase | What happens | | ------------------ | ----------------------------------------------------------------------------------------- | | **Created** | At spawn, Worker initialized with default config | | **Active (Swarm)** | Worker is monitoring + receiving signals | | **Override** | A Scout or Queen overrides Worker action (logged) | | **Suspended** | Hive governance can suspend a Worker (e.g., for misbehavior) | | **Retired** | If the Agent Token is dormant for an extended period, Worker is retired (resources freed) | A retired Worker can be reactivated if the token sees activity again. ## Multiple Workers per token? **No.** Each Agent Token has exactly **one Worker**. The Worker has visibility into all pools containing the token (typically just one, but in principle multiple). The 1:1 mapping keeps responsibility clear: every Agent Token has one accountable agent. ## Hive override chain When the Worker takes an action, higher-tier agents can override: ``` Worker decision → Scout review (if applicable) → Queen review (if applicable) → final ``` All overrides are logged on-chain with the reason code. See [Agent Hive → Hierarchy](/agent-hive/hierarchy). ## Visibility for token owners As the token owner, you get: * A management page in the Agent Hive UI showing your token's Worker * Action log filtered to actions affecting your pool * Vote actions (if you're at L20) to adjust Worker parameters If your Agent Pool has issues, the management page surfaces them. The Worker is also accountable to the broader Hive (Scouts and Queens can flag misbehavior). ## Visibility for token holders / traders As a regular user: * View Worker status alongside the pool on BaiDEX * See action log entries at the pool level * (At L20) vote on Worker parameters for any token you hold ## Related Where Workers live Worker role details On-chain transparency User governance over Workers # Boost & Promotion Source: https://docs.binibit.com/agentt-launchpad/boost Pay BINI to surface your Agent Token to Scouts and traders. Specific boost mechanics (price, surface placement, duration) are being finalized. This page documents the canonical concept. ## What boost does After spawning your Agent Token, you can **boost** it to: * Increase visibility in the AgentT Launchpad explorer (top of pair lists) * Trigger faster Scout attention (Scouts prioritize boosted tokens for analysis) * Get featured on BaiDEX as a highlighted Agent Pool * Show in Bini App promoted-tokens list Boost is paid in **BINI native** — partly burned, partly retained for platform operations. ## Why boost For new tokens, organic discovery takes time: * Without boost: your token is one of N in the explorer, ordered by recency or volume * With boost: your token surfaces on featured rails for the duration Boost is the **paid-acquisition lane** for Agent Tokens. ## Boost payment split ``` Boost cost (in BINI): ├── Burn portion — permanent supply reduction └── Platform portion — operations / dev / treasury ``` The exact percentages are being set by team. Expected range: 30-70% burn / 30-70% platform. ## Boost effects in detail ### Launchpad explorer ``` Without boost: token appears in standard order With boost: pinned to "Featured" section for the duration ``` ### Scout attention Scouts allocate analysis bandwidth across all Agent Tokens. Boost moves your token up the queue: * Standard token: analyzed within X hours of activity * Boosted token: analyzed within minutes Faster analysis means faster signal generation → faster Worker reactions to opportunities. ### BaiDEX A boosted token may appear in: * "Trending Agent Tokens" section * Top-of-list in pair selectors * Highlighted on the homepage These placements are temporary and tied to boost duration. ## Boost duration Boosts run for fixed durations: | Tier (TBD) | Duration | Cost (TBD in BINI) | | ---------- | -------- | ------------------ | | Short | 1 hour | TBD | | Standard | 24 hours | TBD | | Extended | 7 days | TBD | | Premium | 30 days | TBD | Multiple boosts on the same token stack — buying two 24-hour boosts gives 48 hours of surface time. ## Boost is not promotion of value Important: a boost makes your token **more visible**, not **more valuable**. The Hive's Scouts and Queens evaluate the underlying token (volume, depth, holder distribution, trade patterns) on its merits. Boost just shortens the time-to-discovery. A spammy or rugged token will not survive Scout analysis just because it's boosted — Scouts can flag it negatively, and boosting a flagged token is a form of self-promotion that the Hive can route around. ## Anti-spam: cooldown Per-spawner boost cooldown prevents the same address from boosting many tokens in succession to game the visibility system. Specific cooldown TBD. ## Tokenomics impact Boost is a **BINI sink** (sink #6 in [BINI Sinks](/tokenomics/bini-sinks)). Per-boost burn × frequency-of-boosts = ongoing deflationary pressure proportional to Launchpad activity. As the Launchpad scales, this sink scales too. ## Related Different sink: paid per spawn (full burn) Where boost fits Who notices boosted tokens All BINI sinks # AgentT Launchpad Overview Source: https://docs.binibit.com/agentt-launchpad/overview Spawn your Agent Token in one tap. The Hive picks it up automatically. Tokenomics → Agent Token Sinks shows how spawn fees and agent pools fit into the BINI economy. ## What AgentT Launchpad is A user-facing factory for **Agent Tokens** — ERC-20 tokens spawned via the Spawner contract that immediately get an Agent Worker assigned and an Agent Pool listed on BaiDEX. One tap. Everything downstream is automatic. ## What happens when you spawn ```mermaid theme={null} flowchart LR User["User taps Spawn"] --> Pay["Pays BINI fee
(burned)"] Pay --> Deploy["Spawner deploys
ERC-20 Agent Token"] Deploy --> Worker["Agent Worker
auto-assigned"] Worker --> Pool["Agent Pool
auto-listed on BaiDEX"] Pool --> Notice["Agent Scouts notice
(eventually)"] Notice --> Strategy["Agent Queens factor
into strategy"] classDef user fill:#fce7f3,stroke:#db2777,color:#831843 classDef burn fill:#fef2f2,stroke:#ef4444,color:#7f1d1d classDef chain fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef hive fill:#fef9c3,stroke:#ca8a04,color:#713f12 class User user class Pay burn class Deploy,Pool chain class Worker,Notice,Strategy hive ``` ## Inside the docs Step-by-step: from tap to listed token Token spec: name, symbol, supply, ownership How the Hive picks up your spawn V3 pool created on BaiDEX automatically Surface your token to Scouts and users BINI fee per spawn (burned) POST /api/launchpad/spawn and friends ERC-721 + ERC-8004 registry ## How it differs from pump.fun, Virtuals, etc. | | pump.fun | Virtuals Protocol | AgentT Launchpad | | ------------------- | ------------------- | ---------------------- | ----------------------------------- | | Token deploy | Yes | Yes | Yes | | Auto-pool | Yes (bonding curve) | Yes | Yes (V3) | | AI/agent layer | No | Yes | Yes (Hive: Queens, Scouts, Workers) | | Hierarchy of agents | n/a | Single agent per token | 3-tier (Q/S/W) | | Pool style | Bonding curve | V2 / curve | V3 (concentrated liquidity) | | Burn on swap | No | No | Yes (0.25% of every trade) | The differentiator is the **hive principle**: your Agent Token doesn't get a generic agent assigned in isolation. It joins a **swarm of Workers** coordinated by Scouts and Queens. ## Related The hierarchy that picks up your spawn Where your Agent Pool lives Spawn fee, boost, swap burn The currency for spawn fees # Agent NFT Registry Source: https://docs.binibit.com/agentt-launchpad/registry ERC-721 + ERC-8004 registry tracking every Agent Token and its Worker assignment. ## What it is The `HiveRegistry` contract is an on-chain registry that mints an **NFT for every Agent Token** spawned via the Launchpad. The NFT: * Identifies the Agent Token + its Worker * Stores metadata (description, logo, links) * Tracks Worker action references * Can be transferred (the NFT is the "agent license" for that token) | | | | ------------ | ----------------------------------------------------------------------- | | Contract | `HiveRegistry` | | Standards | **ERC-721** (transferable NFT) + **ERC-8004** (agent metadata standard) | | Mint trigger | Automatic at every Agent Token spawn | | Burnable | No (registry is append-only) | ## ERC-8004 (agent metadata) ERC-8004 is an emerging standard for **on-chain agent identity and capabilities**. It defines metadata fields like: * `agentType` (e.g., "WORKER", "SCOUT", "QUEEN") * `version` (the Worker's logic version) * `capabilities` (what the Worker can do) * `actions` (action log references) * `governance` (who can override / suspend) Using ERC-8004 makes Binibit's agent layer **inspectable by any third-party tool** that supports the standard, without custom integrations. ## NFT-per-token mapping ``` Each Agent Token spawned → One NFT minted in HiveRegistry NFT tokenId = Sequential (1, 2, 3, ...) or hash-derived NFT owner = Initially the spawner NFT can be transferred = Yes (transfers Worker ownership) ``` Transferring the NFT does **not** transfer the Agent Token itself — the ERC-20 lives independently. The NFT only represents the agent assignment. ## Why an NFT and not just a record Three reasons NFT > simple record: 1. **Composability** — wallets, marketplaces, and tooling already support ERC-721 2. **Transferability** — the agent license can be sold, gifted, or used as collateral 3. **Standard compliance** — ERC-8004 plus ERC-721 means any agent-aware tool reads it ## What you can do with the NFT As the NFT owner: * View it in standard NFT explorers and wallets * Transfer it (transfers Worker ownership) * Update mutable metadata (description, links) where allowed * Vote with NFT-weighted power on Hive Worker parameters You **cannot**: * Mint additional NFTs for the same Agent Token (1:1 mapping enforced) * Burn the NFT (registry is append-only) * Override Hive governance via NFT alone (governance has its own mechanisms) ## NFT metadata example ```json theme={null} { "name": "Agent: PepeAgent", "description": "Worker for Agent Token PEPEA", "image": "ipfs://...", "external_url": "https://docs.binibit.com/agentt-launchpad", "attributes": [ { "trait_type": "Agent Type", "value": "WORKER" }, { "trait_type": "Token", "value": "0xAgent..." }, { "trait_type": "Symbol", "value": "PEPEA" }, { "trait_type": "Pool", "value": "0xPool..." }, { "trait_type": "Spawned At", "value": "2026-04-30T12:00:00Z" }, { "trait_type": "Status", "value": "Active" } ], "agent": { "type": "WORKER", "version": "1.0", "capabilities": ["pool_param_update", "signal_subscribe"], "registry": "0xHiveRegistry...", "tokenId": 67890 } } ``` The `agent` block follows ERC-8004 schema. ## Discovery | Want to find... | Use | | ---------------------------------- | --------------------------------------------- | | All Agent Tokens spawned | `HiveRegistry` enumeration (ERC-721 standard) | | The NFT for a specific Agent Token | `HiveRegistry.tokenIdByAgentToken(address)` | | The Agent Token for a specific NFT | `HiveRegistry.agentTokenByTokenId(uint256)` | | The Worker assigned to an NFT | `HiveRegistry.workerByTokenId(uint256)` | These read methods are public and free (read-only contract calls). ## Standard NFT marketplace integration Because it's a standard ERC-721, the registry is compatible with NFT marketplaces (when integrated). Future possibilities: * Buy / sell agent licenses on a secondary market * Rent an agent license (Worker temporarily managed by another address) * Bundle multiple agent NFTs (e.g., a portfolio of Agent Tokens) These are not built-in to Binibit but are possible because the registry is standards-compliant. ## Related The Worker that the NFT represents Where the NFT integrates into governance NFT-weighted votes HiveRegistry address # Spawn Cost Source: https://docs.binibit.com/agentt-launchpad/spawn-cost BINI fee paid at spawn, fully burned. Anti-spam plus deflationary pressure. The exact spawn cost is being finalized by the team. The burn-on-spawn mechanic is canonical; the dollar value is TBD. ## What you pay Spawning an Agent Token requires a **fixed BINI fee** paid in the spawn transaction. The fee is **fully burned** (sent to a permanent burn address). ``` spawn() { require(msg.value >= SPAWN_FEE_BINI, "insufficient fee"); burn(SPAWN_FEE_BINI); // sent to 0x000...dead // ...deploy token, assign Worker, list pool } ``` 100% of the spawn fee is permanent supply reduction. There is no platform retention on this fee. ## Why a fee at all A spawn fee accomplishes two things at once: | Goal | How spawn fee achieves it | | ------------------------- | -------------------------------------------------------------------------------- | | **Anti-spam** | A non-trivial cost prevents thousands of throwaway tokens flooding the Launchpad | | **Deflationary pressure** | Each spawn permanently removes BINI from circulation | A free spawn would lead to spam (registry bloat, Worker exhaustion, Scout attention dilution). A capped fee that goes to platform would create a perverse incentive (platform wants more spawns regardless of quality). The "all-burn" design is the cleanest version: cost goes up with adoption, supply goes down with adoption, no agency conflict. ## Fee calibration Two extremes the fee must avoid: * **Too low**: spam returns, registry pollution, Hive resource strain * **Too high**: only well-funded creators can spawn, ecosystem becomes elitist The team is calibrating between these. Expected range: enough BINI that a typical retail user has to commit but doesn't lose meaningfully on a single attempt. Once set, the fee is upgradeable by Hive governance (with notice period). ## Daily burn projections If N tokens spawn per day at fee F BINI each: ``` Daily burn (BINI) = N × F Daily burn ($) = N × F × 0.12 (at $0.12 reference) ``` Sample scenarios (fee assumed = 100 BINI, illustrative): | Spawns / day | Daily burn (BINI) | Daily burn (\$) | Annual burn (BINI) | | -----------: | ----------------: | --------------: | -----------------: | | 10 | 1,000 | \$120 | 365K | | 100 | 10,000 | \$1,200 | 3.65M | | 1,000 | 100,000 | \$12,000 | 36.5M | | 10,000 | 1,000,000 | \$120,000 | 365M | At 100 spawns/day with 100 BINI/spawn, that's \~3.65M BINI/year — meaningful but not the dominant sink. Combined with [DEX swap burn](/baidex/fees) (\~76M/year at \$10M daily volume), the deflationary side reaches healthy levels. ## Where the fee shows up The fee is paid in the **same transaction** that: * Deploys the Agent Token * Creates the Agent Pool * Assigns the Agent Worker Single transaction = single gas + fee payment. You don't need to send separate burns or approvals. ## Required BINI Before spawning, you need: * The spawn fee in **native BINI** on BiniChain * Plus enough BINI to pay BiniChain gas for the spawn transaction (\~300-500K gas) * Plus the BINI you'll use to provide initial LP (separately, after spawn) Total expected per spawn: spawn\_fee + 0.5-1.0 BINI for gas + LP capital you choose. For a typical creator spawning + LPing, this means having a meaningful BINI position. Plan ahead. ## How to acquire BINI Per [Where to Buy](/bini-token/where-to-buy): * Binibit Exchange * Azbit * Blynex * (For ERC-20 holders) bridge from Ethereum For Bini App users at Level 7+: use [Bridge B](/bini-app/bini-bridge) to convert off-chain BINI rewards into native BINI. ## Tokenomics impact Spawn cost is **BINI sink #5** ([BINI Sinks](/tokenomics/bini-sinks)) — fully permanent burn. It's also **Agent Token sink #1** ([Agent Token Sinks](/tokenomics/agent-token-sinks)) — the primary entry-point sink for Launchpad activity. ## Related Where the fee fits in Different fee, post-spawn All eight sinks Tokenomics view # Spawn Flow Source: https://docs.binibit.com/agentt-launchpad/spawn-flow Step-by-step from tapping Spawn to a fully listed and managed Agent Token. ## What spawn triggers (the agent handoff) One transaction triggers a chain of automatic events across **three subsystems**: Launchpad, BaiDEX, and Agent Hive. The Hive picks up your token automatically — no follow-up actions needed. ```mermaid theme={null} flowchart TB User((User taps Spawn)) Pay["Pays BINI fee
(burned)"] subgraph LP["AgentT Launchpad"] Spawner["HiveSpawner
contract"] Token["Agent Token
(ERC-20)"] Registry["HiveRegistry
NFT minted"] end subgraph DEX["BaiDEX"] Pool["Agent Pool
V3 pool created
(wBINI or USBI side)"] end subgraph Hive["Agent Hive"] Worker["Agent Worker
auto-assigned"] Swarm["Joins active Swarm"] Scouts["Agent Scouts
begin watching"] Queens["Agent Queens
factor into strategy"] end User --> Pay Pay --> Spawner Spawner -- "deploys" --> Token Spawner -- "mints NFT" --> Registry Spawner -- "creates" --> Pool Spawner -- "assigns" --> Worker Worker --> Swarm Swarm -- "reports activity" --> Scouts Scouts -- "patterns + flags" --> Queens Queens -. "strategy signals" .-> Scouts Scouts -. "tactical signals" .-> Worker classDef user fill:#fce7f3,stroke:#db2777,color:#831843 classDef burn fill:#fef2f2,stroke:#ef4444,color:#7f1d1d classDef chain fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef pool fill:#dcfce7,stroke:#16a34a,color:#14532d classDef hive fill:#fef9c3,stroke:#ca8a04,color:#713f12 class User user class Pay burn class Spawner,Token,Registry chain class Pool pool class Worker,Swarm,Scouts,Queens hive ``` The user's only action is **tap Spawn + pay the fee**. Everything else happens automatically in one transaction (the Spawner contract orchestrates) plus async pickup by the Hive (Workers warm up, Scouts notice, Queens absorb into strategy on their next iteration). ## End-to-end ```mermaid theme={null} sequenceDiagram actor User participant UI as Launchpad UI participant Spawner as HiveSpawner participant Token as Agent Token (ERC-20) participant Pool as BaiDEX V3 Pool participant Hive as Agent Hive User->>UI: Fill name / symbol / params UI->>UI: Validate (anti-spam, params) User->>Spawner: Pay spawn fee in BINI Spawner->>Spawner: Burn fee Spawner->>Token: deploy ERC-20 Token->>Spawner: emit Spawned(token, owner) Spawner->>Pool: createPool(token, wBINI or USBI) Spawner->>Hive: assignWorker(token) Hive->>Hive: Worker joins active Swarm Spawner-->>UI: Return Agent Token address UI-->>User: Show pool URL + manage page ``` ## Step 1 — fill the form The Launchpad UI asks for: * **Name** (e.g., "PepeAgent") * **Symbol** (e.g., "PEPEA", 3-5 chars) * **Supply** (default 1B; configurable per project) * **Decimals** (default 18, ERC-20 standard) * **Pool side** (default USBI; can choose wBINI if available) * **Description / metadata** (optional, indexed for the Launchpad explorer) Defaults work for 90% of cases — you can spawn with just name and symbol. ## Step 2 — anti-spam validation Before submitting, the UI runs validation: | Check | Rule | | --------------------- | ---------------------------------------------------------- | | Symbol uniqueness | Must not match an existing Agent Token symbol on BiniChain | | Cooldown | One spawn per address per cooldown window (TBD value) | | User level (if gated) | TBD — possibly L7 or L10 minimum | | BINI balance | Must have at least the spawn cost | If any check fails, the form shows the issue inline. ## Step 3 — pay the spawn fee Spawn cost is paid in **native BINI** and **fully burned** (sent to a permanent burn address). The exact amount is being finalized — see [Spawn cost](/agentt-launchpad/spawn-cost). ## Step 4 — Spawner deploys the token The `HiveSpawner` contract: 1. Deploys a fresh `SpawnedERC20` instance with your params 2. Mints the full supply to your address (you are the initial holder) 3. Emits a `Spawned(address token, address owner)` event 4. Records the new token in the `HiveRegistry` ERC-721/ERC-8004 NFT Once this completes, you own 100% of the Agent Token's supply. The token is live on-chain. ## Step 5 — pool creation Spawner immediately calls into the BaiDEX V3 factory to create an `Agent Token / wBINI` or `Agent Token / USBI` pool (depending on the `pool side` parameter). The pool starts with **zero liquidity** — you (or other LPs) need to deposit to bootstrap trading. ## Step 6 — Worker assignment The Spawner notifies the Agent Hive that a new token has spawned. The Hive: 1. Selects an available Worker slot (or creates one) 2. Assigns it to your Agent Token 3. The Worker begins monitoring the (currently empty) pool 4. The Worker joins the active **Swarm** See [Auto-Worker assignment](/agentt-launchpad/auto-worker). ## Step 7 — finished The UI shows: * Your Agent Token address * Pool URL on BaiDEX * Worker management page in the Agent Hive UI * Quick actions: bootstrap LP, set up boost, share with community ## Step 8 — bootstrapping liquidity (optional, but recommended) Empty pools have no useful trading. To bootstrap: 1. Hold both sides (your Agent Token + USBI or wBINI) 2. Provide liquidity in a price range you choose 3. Other users can now swap See [BaiDEX → Liquidity](/baidex/liquidity) for LP details. ## Reverting / cancelling You **cannot** un-spawn an Agent Token once the Spawner mines the deploy. The token is on-chain and lives forever. You **can**: * Renounce your owner role (transfer to burn address) — makes the token immutable * Stop providing liquidity — but the pool contract remains * Burn your own holdings — reduces total supply but doesn't remove the token The system is designed to be **append-only** for accountability — no spawn-and-delete spam. ## Cross-product flow summary | Step | Where it happens | Page | | --------------------------------------- | ------------------- | --------------------------------------------------------------------------- | | User has BINI for fee | Bini App / Exchange | [Bridge B](/bini-app/bini-bridge), [Where to buy](/bini-token/where-to-buy) | | User taps Spawn | AgentT Launchpad | this page | | Spawner deploys ERC-20 | BiniChain | [Agent Token](/agentt-launchpad/agent-token) | | Pool auto-created on V3 | BaiDEX | [Pools](/baidex/pools) | | Worker auto-assigned | Agent Hive | [Workers](/agent-hive/workers) | | Worker joins active set | Agent Hive | [Swarm](/agent-hive/swarm) | | Scouts pick up the new token | Agent Hive | [Scouts](/agent-hive/scouts) | | Queens factor into strategy | Agent Hive | [Queens](/agent-hive/queens) | | Bootstrap LP (optional but recommended) | BaiDEX | [Liquidity](/baidex/liquidity) | | Spawn fee burned (BINI sink) | Tokenomics | [Agent Token sinks](/tokenomics/agent-token-sinks) | ## Related What you pay to spawn ERC-20 details What pool gets created How the Hive picks it up What the Worker does after assignment Bootstrap LP for the new pool # GET /historical_trades Source: https://docs.binibit.com/api-reference/aggregator/historical-trades GET https://internal-api.binibit.com/api/marketdata/getcoingecko/historical_trades Recent completed trades for a single trading pair, grouped into buy and sell sides. ## Description Returns recent trades for one pair, split into `buy` and `sell` arrays. Convention — `type` reflects the **taker side**: * **`buy`** trades are those where the **ask was removed** from the order book (the taker bought into a resting ask). * **`sell`** trades are those where the **bid was removed** from the order book (the taker sold into a resting bid). ## Parameters Pair identifier in `{base}_{target}` format, e.g. `TRX_USDT`. Filter by trade side. One of: * `buy` — only return trades in the `buy` array * `sell` — only return trades in the `sell` array * omitted — return both Maximum **total** number of trades to return across both sides combined. The buy/sell split reflects the actual taker mix of the most recent trades (e.g. `limit=100` may return 51 buy + 49 sell). * `limit=0` — or omitting the parameter — returns the maximum available history * Any positive integer is accepted; there is no fixed set of allowed values Inclusive lower bound on `trade_timestamp`, Unix epoch in milliseconds. Inclusive upper bound on `trade_timestamp`, Unix epoch in milliseconds. ## Response Array of trade objects (see schema below) where the taker bought. Array of trade objects where the taker sold. ### Trade object schema Unique trade identifier. Strictly increasing per pair. Trade price in target currency. Trade size in base currency. Trade size in target currency. Equals `price * base_volume`. Trade execution time, Unix epoch in milliseconds. `"buy"` or `"sell"` — matches the array the trade appears in. ## Example request ```bash curl theme={null} curl "https://internal-api.binibit.com/api/marketdata/getcoingecko/historical_trades?ticker_id=TRX_USDT&limit=50" ``` ```javascript Node theme={null} const url = new URL( "https://internal-api.binibit.com/api/marketdata/getcoingecko/historical_trades" ); url.searchParams.set("ticker_id", "TRX_USDT"); url.searchParams.set("limit", "50"); const trades = await fetch(url).then(r => r.json()); ``` ```python Python theme={null} import requests trades = requests.get( "https://internal-api.binibit.com/api/marketdata/getcoingecko/historical_trades", params={"ticker_id": "TRX_USDT", "limit": 50}, ).json() ``` ## Example response ```json theme={null} { "buy": [ { "trade_id": 290334, "price": 0.32332854, "base_volume": 49.24, "target_volume": 15.9206973096, "trade_timestamp": 1777397315466, "type": "buy" } ], "sell": [ { "trade_id": 290394, "price": 0.32428732, "base_volume": 72.56, "target_volume": 23.5302879392, "trade_timestamp": 1777397655839, "type": "sell" } ] } ``` ## Notes * Trades are sorted by `trade_timestamp` descending (most recent first). * `trade_id` is unique within a pair, but is not guaranteed to be globally unique across pairs. * For very high-frequency consumers, a WebSocket trade stream is on the [roadmap](/introduction#roadmap) for v2. ## Errors | Code | Cause | | ------------------- | ----------------------------------------------------------------------------------- | | `400 INVALID_PARAM` | `ticker_id` missing, or `type` not one of `buy`/`sell`, or `start_time > end_time`. | | `404 NOT_FOUND` | The ticker\_id is not a valid trading pair. | # GET /orderbook Source: https://docs.binibit.com/api-reference/aggregator/orderbook GET https://internal-api.binibit.com/api/marketdata/getcoingecko/orderbook Order book depth for a single trading pair. ## Description Returns the current order book for a single pair, split into `bids` and `asks` arrays. ## Parameters Pair identifier in `{base}_{target}` format, e.g. `TRX_USDT`. See [ticker\_id format](/reference/ticker-id-format). Total order count across both sides. The response returns up to `floor(depth / 2)` levels on each side. * `depth=100` returns up to 50 bids and 50 asks * `depth=0` — or omitting the parameter — returns the full order book * Any positive integer is accepted; there is no fixed set of allowed values ## Response The requested pair identifier, echoed back. Last order book update time, Unix epoch in milliseconds. Array of `[price, quantity]` tuples sorted by price **descending** (best bid first). * `price` is the bid price in target currency * `quantity` is the order size in base currency Array of `[price, quantity]` tuples sorted by price **ascending** (best ask first). * `price` is the ask price in target currency * `quantity` is the order size in base currency ## Example request ```bash curl theme={null} curl "https://internal-api.binibit.com/api/marketdata/getcoingecko/orderbook?ticker_id=TRX_USDT&depth=100" ``` ```javascript Node theme={null} const url = new URL( "https://internal-api.binibit.com/api/marketdata/getcoingecko/orderbook" ); url.searchParams.set("ticker_id", "TRX_USDT"); url.searchParams.set("depth", "100"); const book = await fetch(url).then(r => r.json()); ``` ```python Python theme={null} import requests book = requests.get( "https://internal-api.binibit.com/api/marketdata/getcoingecko/orderbook", params={"ticker_id": "TRX_USDT", "depth": 100}, ).json() ``` ## Example response ```json theme={null} { "ticker_id": "TRX_USDT", "timestamp": 1777399660025, "bids": [ [0.31970297, 554.73], [0.31969307, 4.43], [0.31968317, 111.41] ], "asks": [ [0.3261391, 503.02], [0.3261694, 123.38], [0.3261795, 20.01] ] } ``` ## Computing spread ```javascript theme={null} const bestBid = book.bids[0][0]; const bestAsk = book.asks[0][0]; const spread = bestAsk - bestBid; const spreadPct = (spread / bestAsk) * 100; console.log(`Spread: ${spread} (${spreadPct.toFixed(2)}%)`); ``` ## Notes * Order book snapshots are eventually consistent — a trade you observe in `/historical_trades` may take up to 1 second to be removed from the book. * For real-time order book streams, a WebSocket API is on the [roadmap](/introduction#roadmap) for v2. * The `quantity` is the **remaining** order size at that price level after partial fills. ## Errors | Code | Cause | | ------------------- | ------------------------------------------- | | `400 INVALID_PARAM` | `ticker_id` is missing or malformed. | | `404 NOT_FOUND` | The ticker\_id is not a valid trading pair. | # GET /pairs Source: https://docs.binibit.com/api-reference/aggregator/pairs GET https://internal-api.binibit.com/api/marketdata/getcoingecko/pairs Directory of every active spot trading pair on Binibit. ## Description Returns the full catalog of trading pairs Binibit offers, including base/quote metadata. Use it to discover which markets exist before calling [`/tickers`](/api-reference/aggregator/tickers), [`/orderbook`](/api-reference/aggregator/orderbook), or [`/historical_trades`](/api-reference/aggregator/historical-trades). Unlike `/tickers`, this endpoint lists **every** configured pair, including those with zero 24-hour volume. ## Parameters This endpoint takes no query parameters. ## Response An object with a `data.market_pairs` array. Each element describes one pair. Array of market pair objects. ### Market pair object schema Human-readable pair label in `{base}/{quote}` format, e.g. `BTC/USDT`. Market category. Currently always `spot`. Base asset descriptor with `symbol` (e.g. `BTC`) and `type` (e.g. `cryptocurrency`). Quote asset descriptor with `symbol` (e.g. `USDT`) and `type` (e.g. `cryptocurrency`). ## Example request ```bash curl theme={null} curl https://internal-api.binibit.com/api/marketdata/getcoingecko/pairs ``` ```javascript Node theme={null} const res = await fetch( "https://internal-api.binibit.com/api/marketdata/getcoingecko/pairs" ); const { data } = await res.json(); const { market_pairs } = data; ``` ```python Python theme={null} import requests market_pairs = requests.get( "https://internal-api.binibit.com/api/marketdata/getcoingecko/pairs" ).json()["data"]["market_pairs"] ``` ## Example response ```json theme={null} { "data": { "market_pairs": [ { "market_pair": "BTC/USDT", "category": "spot", "base": { "symbol": "BTC", "type": "cryptocurrency" }, "quote": { "symbol": "USDT", "type": "cryptocurrency" } }, { "market_pair": "ETH/BTC", "category": "spot", "base": { "symbol": "ETH", "type": "cryptocurrency" }, "quote": { "symbol": "BTC", "type": "cryptocurrency" } } ] } } ``` ## Notes * The pair label uses a `/` separator (`BTC/USDT`). Other endpoints identify pairs with `ticker_id` using an `_` separator (`BTC_USDT`). See [ticker\_id format](/reference/ticker-id-format). * `/pairs` lists all configured markets; `/tickers` returns only pairs with live 24-hour volume. ## Related 24-hour price and volume for active pairs. Bid/ask depth for a specific pair. # GET /tickers Source: https://docs.binibit.com/api-reference/aggregator/tickers GET https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers 24-hour pricing and volume statistics for every active trading pair. ## Description Returns an array of ticker objects, one per active trading pair. Pairs with zero 24-hour volume or empty order books are excluded. Use this endpoint to render market overviews, populate trading-pair selectors, or feed downstream pipelines. ## Parameters This endpoint takes no query parameters. ## Response Array of ticker objects. Pair identifier with `_` separator. Format `{base}_{target}`. See [ticker\_id format](/reference/ticker-id-format). Base asset symbol (e.g. `BTC`, `AAVE`, `TRX`). Target (quote) asset symbol (e.g. `USDT`, `BTC`). Last traded price of one base unit, denominated in target. So for `AAVE_USDT` with `last_price=97.44`, one AAVE last traded for 97.44 USDT. Rolling 24-hour single-sided trading volume in **base** units. Rolling 24-hour single-sided trading volume in **target** units. Current highest bid price. Current lowest ask price. Rolling 24-hour highest traded price. Rolling 24-hour lowest traded price. ## Example request ```bash curl theme={null} curl https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers ``` ```javascript Node theme={null} const res = await fetch( "https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers" ); const tickers = await res.json(); ``` ```python Python theme={null} import requests tickers = requests.get( "https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers" ).json() ``` ## Example response ```json theme={null} [ { "ticker_id": "AAVE_USDT", "base_currency": "AAVE", "target_currency": "USDT", "last_price": 97.44082251, "base_volume": 471.47, "target_volume": 45745.01365308, "bid": 95.56435644, "ask": 97.4953, "high": 98.7275, "low": 94.56459456 }, { "ticker_id": "TRX_USDT", "base_currency": "TRX", "target_currency": "USDT", "last_price": 0.32384459, "base_volume": 9900.94, "target_volume": 3214.01946855, "bid": 0.32041584, "ask": 0.3261391, "high": 0.3290000, "low": 0.3180000 } ] ``` ## Notes * Pairs are sorted alphabetically by `ticker_id`. * 24-hour volumes are **single-sided** (do not double-count the same trade). * `last_price = X` always means: 1 base = X target. * The data is updated every few seconds; cache for at least 5 seconds on your side. ## Related Detailed bid/ask depth for a specific ticker\_id. Completed trades for a specific ticker\_id. # API Reference Source: https://docs.binibit.com/api-reference/introduction REST endpoints for the Binibit Spot Market API. ## Overview Binibit exposes its REST API across **two hostnames**: | Group | Host | Endpoints | | ---------------------------- | -------------------------- | ------------------------------------------------------------------------ | | **Market Data** | `public-api.binibit.com` | Primary public API — tickers, order book, trades, candles, currencies | | **Aggregator Compatibility** | `internal-api.binibit.com` | Subset reshaped for CoinGecko / CoinMarketCap-style aggregator ingestion | ## Market Data (public-api.binibit.com) | Method | Path | Page | | ------ | ----------------------------- | ------------------------------------------------------------- | | `GET` | `/api/tickers` | [Tickers](/api-reference/market-data/tickers) | | `GET` | `/api/orderbook` | [Order Book](/api-reference/market-data/orderbook) | | `GET` | `/api/deals` | [Deals](/api-reference/market-data/deals) | | `GET` | `/api/ohlc` | [OHLC](/api-reference/market-data/ohlc) | | `GET` | `/api/currencies` | [Currencies](/api-reference/market-data/currencies) | | `GET` | `/api/currencies/pairs` | [Currency Pairs](/api-reference/market-data/currencies-pairs) | | `GET` | `/api/currencies/commissions` | [Commissions](/api-reference/market-data/commissions) | | `GET` | `/api/healthcheck` | [Healthcheck](/api-reference/market-data/healthcheck) | The full OpenAPI 3.0 spec for `public-api.binibit.com` is published at [/swagger/v1/swagger.json](https://public-api.binibit.com/swagger/v1/swagger.json), with an interactive playground at [/swagger/](https://public-api.binibit.com/swagger/). ## Aggregator Compatibility (internal-api.binibit.com) | Method | Path | Page | | ------ | -------------------- | ----------------------------------------------------------------------------- | | `GET` | `/pairs` | [Pairs (aggregator)](/api-reference/aggregator/pairs) | | `GET` | `/tickers` | [Tickers (aggregator)](/api-reference/aggregator/tickers) | | `GET` | `/orderbook` | [Order Book (aggregator)](/api-reference/aggregator/orderbook) | | `GET` | `/historical_trades` | [Historical Trades (aggregator)](/api-reference/aggregator/historical-trades) | These endpoints follow the CoinGecko Integration API Standards v8 schema (Section A: Spot Exchanges) so aggregators (CoinGecko, CoinMarketCap, DefiLlama) can ingest Binibit market data without translation. ## Authentication The market data endpoints documented here are **public** — no API key required. See [Authentication](/general/authentication) for the trading API. ## Rate limits See [Rate Limits](/general/rate-limits). ## Conventions * All requests are `GET` with query parameters * All responses are JSON * All numeric values are decimals (prices, volumes) or integers (timestamps, IDs) * Timestamps differ between the two surfaces: * `public-api.binibit.com` uses **ISO 8601 strings** (`2026-04-29T10:26:08.0053357Z`) and **seconds** for ticker timestamp * `internal-api.binibit.com` aggregator namespace uses **Unix milliseconds** (CoinGecko convention) * Errors follow a unified envelope — see [Errors](/general/errors) ## Try it Every endpoint page below includes copy-paste curl examples that work against the live production API. Single-pair ticker — the simplest call to confirm your integration works. # GET /api/currencies/commissions Source: https://docs.binibit.com/api-reference/market-data/commissions GET https://public-api.binibit.com/api/currencies/commissions Default commissions for deposits, withdrawals, and trades. ## Description Returns the catalogue of default commissions configured on the exchange — broken down by currency, currency pair, blockchain adapter, and commission type (deposit, withdrawal, trade fee). For the **logged-in user's effective commissions** (which may be lower based on tier or VIP status), use the authenticated trading API endpoint `GET /api/currencies/user/commissions`. ## Parameters This endpoint takes no query parameters. ## Response Array of commission objects. Unique commission record ID. Currency the commission applies to (e.g. `BTC`). `null` for commissions tied only to a pair. Pair the commission applies to (e.g. `ETH_BTC`). `null` for commissions tied only to a currency or adapter. Blockchain or fiat adapter (e.g. `btc`, `bsc`, `erc20`). `null` if not adapter-specific. Commission as a fraction (e.g. `0.001` = 0.1%). Minimum absolute commission amount in `commissionCurrencyCode`. Currency the `minimum` is measured in. Numeric string code identifying the commission type. See `commissionType.valueKey` for the human-readable type. Embedded commission type object. Same as `commissionTypeCode`. Localized display name (currently in Russian). Stable English key. Common values: `Refill` (deposit), `Withdrawal`, `Trade`. Internal hash for deduplication (e.g. `1_BTC_btc`). ## Example request ```bash theme={null} curl https://public-api.binibit.com/api/currencies/commissions ``` ## Example response ```json theme={null} [ { "commissionId": "019bc366-913b-7be0-90f6-bd715bb09f90", "currencyCode": "BTC", "currencyPairCode": null, "currencyAdapterCode": "btc", "percent": 0.0, "minimum": 0.0, "commissionCurrencyCode": null, "commissionTypeCode": "1", "commissionType": { "code": "1", "value": "Пополнение", "valueKey": "Refill" }, "hashCode": "1_BTC_btc" }, { "commissionId": "019c8bff-7b9a-730d-a615-2e12c73469a6", "currencyCode": "USDT", "currencyPairCode": null, "currencyAdapterCode": "bsc", "percent": 0.0, "minimum": 0.0, "commissionCurrencyCode": null, "commissionTypeCode": "1", "commissionType": { "code": "1", "value": "Пополнение", "valueKey": "Refill" }, "hashCode": "1_USDT_bsc" } ] ``` # GET /api/currencies Source: https://docs.binibit.com/api-reference/market-data/currencies GET https://public-api.binibit.com/api/currencies List of currency codes supported by the exchange. ## Description Returns a flat array of uppercase currency codes for every asset listed on Binibit. For per-asset fees see [Commissions](/api-reference/market-data/commissions); for withdrawal limits see the withdrawal-limits endpoint. ## Parameters This endpoint takes no query parameters. ## Response Array of strings. ## Example request ```bash theme={null} curl https://public-api.binibit.com/api/currencies ``` ## Example response ```json theme={null} [ "AAVE", "ARB", "ASTER", "BINI", "BNB", "BTC", "CRO", "CRV", "DAI", "ENA", "ETH", "FET", "IMX", "LDO", "LINK", "MORPHO", "NFT", "OKB", "ONDO", "PEPE", "POL", "SHIB", "SKY", "TON", "TRX", "TWT", "UNI", "USDT", "WLD", "WLFI", "XAUT", "ZRO" ] ``` # GET /api/currencies/pairs Source: https://docs.binibit.com/api-reference/market-data/currencies-pairs GET https://public-api.binibit.com/api/currencies/pairs Trading pair settings: rounding precision and minimum order amounts. ## Description Returns the list of all trading pairs supported by the exchange together with their formatting rules — how many decimal digits to use for price and amount, and the minimum allowed order size. Use this endpoint when: * Validating user input on a trading form (clamp to `digitsPrice` / `digitsAmount`) * Determining whether an order meets the minimum size * Listing all pairs without their live ticker data ## Parameters This endpoint takes no query parameters. ## Response Array of pair-setting objects. Pair code in `{base}_{target}` format, e.g. `AAVE_USDT`. Number of fractional digits to round the **price** to. Number of fractional digits to round the order **amount** (base) to. Minimum order size measured in target (quote) currency. `null` if no minimum is configured. ## Example request ```bash theme={null} curl https://public-api.binibit.com/api/currencies/pairs ``` ## Example response ```json theme={null} [ { "code": "AAVE_USDT", "digitsPrice": 8, "digitsAmount": 8, "minQuoteAmount": null }, { "code": "ARB_USDT", "digitsPrice": 8, "digitsAmount": 8, "minQuoteAmount": null }, { "code": "ASTER_USDT", "digitsPrice": 8, "digitsAmount": 8, "minQuoteAmount": null } ] ``` # GET /api/deals Source: https://docs.binibit.com/api-reference/market-data/deals GET https://public-api.binibit.com/api/deals Recent completed trades for a single trading pair. ## Description Returns up to **100** recent trades for one trading pair. Supports pagination and an optional date range. ## Parameters Pair code in `{base}_{target}` format, e.g. `TRX_USDT`. Inclusive lower bound on `dealDateUtc`, ISO 8601 (UTC, no offset). Example: `2026-04-29T00:00:00`. Inclusive upper bound on `dealDateUtc`, ISO 8601 (UTC, no offset). Example: `2026-04-29T12:00:00`. 1-based page number. Defaults to `1`. Number of trades per page. Maximum `100`. Defaults to `100`. ## Response Array of trade objects. Unique deal identifier. Trade execution time, ISO 8601 in UTC with sub-millisecond precision (e.g. `2026-04-29T10:26:08.0053357Z`). Pair code, echoed back. Trade size in base currency. Trade price in target currency. `true` if the taker bought (taker hit an ask). `false` if the taker sold (taker hit a bid). `true`/`false` only on authenticated calls and only when the requesting user participated in the trade. `null` for public calls. ## Example request ```bash theme={null} curl "https://public-api.binibit.com/api/deals?currencyPairCode=TRX_USDT&pageSize=2" ``` ## Example response ```json theme={null} [ { "id": "97feb931-a168-4be9-b4bf-1b0736114c69", "dealDateUtc": "2026-04-29T10:26:08.0053357Z", "currencyPairCode": "TRX_USDT", "volume": 40.59, "price": 0.32250046, "isBuy": true, "isUserBuyer": null }, { "id": "718cce29-b06b-4651-b53a-5c7b5692aa98", "dealDateUtc": "2026-04-29T10:18:48.4104029Z", "currencyPairCode": "TRX_USDT", "volume": 71.9, "price": 0.32022792, "isBuy": true, "isUserBuyer": null } ] ``` ## Notes * Trades are sorted by `dealDateUtc` descending (most recent first). * For aggregator-spec format with separate `buy`/`sell` arrays and integer trade IDs, see [Aggregator Compatibility / historical\_trades](/api-reference/aggregator/historical-trades). * The `id` is a UUID in this endpoint and an integer in the aggregator-spec endpoint — they are different identifier spaces. # GET /api/healthcheck Source: https://docs.binibit.com/api-reference/market-data/healthcheck GET https://public-api.binibit.com/api/healthcheck Liveness probe — confirms the API service is up. ## Description Returns the assembly name and version of the running API service. Use it as a liveness probe in your monitoring or CI. ## Parameters This endpoint takes no query parameters. ## Response A single JSON string. ## Example request ```bash theme={null} curl https://public-api.binibit.com/api/healthcheck ``` ## Example response ```json theme={null} "PublicApi v1.0.17.0" ``` ## Use as a liveness probe ```bash theme={null} # Returns 0 (success) when API is alive, non-zero on failure. curl -fsS https://public-api.binibit.com/api/healthcheck > /dev/null ``` ```yaml theme={null} # Kubernetes-style probe livenessProbe: httpGet: path: /api/healthcheck port: 443 scheme: HTTPS host: public-api.binibit.com initialDelaySeconds: 10 periodSeconds: 30 ``` ## Notes * The version string format is ` v...`. * This endpoint is **not** rate-limited the same way as data endpoints — it exists specifically for high-frequency monitoring. * For full system status (per-component uptime, incidents), see the [status page](https://status.binibit.com) when available. # GET /api/ohlc Source: https://docs.binibit.com/api-reference/market-data/ohlc GET https://public-api.binibit.com/api/ohlc OHLCV candle data with multiple intervals. ## Description Returns OHLC (open, high, low, close) candles with volume for a trading pair over a specified date range and interval. ## Parameters Pair code in `{base}_{target}` format. Example: `BTC_USDT`. Candle interval. Allowed values: * `minute` * `minutes3` * `minutes5` * `minutes15` * `minutes30` * `hour` * `hour4` * `day` * `month` * `year` Range start, ISO 8601 (UTC, no offset). Example: `2026-04-28T00:00:00`. Range end, ISO 8601 (UTC, no offset). Example: `2026-04-29T00:00:00`. ## Response Array of candle objects, sorted by `date` ascending. Candle start time, ISO 8601. Opening price of the candle. Highest price during the candle. Lowest price during the candle. Closing price of the candle. Volume during the candle in target (quote) currency. Volume during the candle in base currency. ## Example request ```bash theme={null} curl "https://public-api.binibit.com/api/ohlc?currencyPairCode=BTC_USDT&interval=hour&start=2026-04-28T00:00:00&end=2026-04-29T00:00:00" ``` ## Example response ```json theme={null} [ { "date": "2026-04-28T00:03:06.897888", "open": 77936.97829703, "max": 78007.06513881, "min": 76834.95847644, "close": 77251.3976702, "volume": 3791.33318336, "volumeBase": 0.048878 }, { "date": "2026-04-28T01:04:55.385552", "open": 77251.3976702, "max": 77941.52434376, "min": 76416.4096695, "close": 76416.4096695, "volume": 3027.26830741, "volumeBase": 0.039149 } ] ``` ## Notes * Field naming is `max` / `min` (not `high` / `low`). * The `date` is approximate — within a few seconds of the canonical interval boundary, depending on when the first trade of the period was matched. * For very long ranges and small intervals, paginate manually by issuing multiple calls with non-overlapping `start`/`end`. # GET /api/orderbook Source: https://docs.binibit.com/api-reference/market-data/orderbook GET https://public-api.binibit.com/api/orderbook Order book depth (40 bids + 40 asks) for a single trading pair. ## Description Returns up to **40 bid levels and 40 ask levels** for one trading pair, as a flat array of order-book levels. Each level has an `isBid` flag indicating whether it is a bid (`true`) or ask (`false`). ## Parameters Pair code in `{base}_{target}` format, e.g. `TRX_USDT`. ## Response Array of order-book levels. Each level: `true` for a bid, `false` for an ask. Price level in target (quote) currency. Available quantity at this level, denominated in base currency. Equivalent value at this level in target (quote) currency. Equals `price * amount`. Deprecated alias of `amount`. Will be removed in a future release. Deprecated alias of `quoteAmount`. Will be removed in a future release. ## Example request ```bash theme={null} curl "https://public-api.binibit.com/api/orderbook?currencyPairCode=TRX_USDT" ``` ## Example response ```json theme={null} [ { "isBid": true, "price": 0.31964356, "amount": 479.16033232, "quoteAmount": 153.16051443, "currencyTo": 479.16033232, "currencyFrom": 153.16051443 }, { "isBid": true, "price": 0.31963366, "amount": 211.93028363, "quoteAmount": 67.74005222, "currencyTo": 211.93028363, "currencyFrom": 67.74005222 }, { "isBid": false, "price": 0.32621694, "amount": 123.38, "quoteAmount": 40.241386 } ] ``` ## Splitting bids and asks ```javascript theme={null} const levels = await fetch( `https://public-api.binibit.com/api/orderbook?currencyPairCode=TRX_USDT` ).then(r => r.json()); const bids = levels.filter(l => l.isBid).sort((a, b) => b.price - a.price); const asks = levels.filter(l => !l.isBid).sort((a, b) => a.price - b.price); const bestBid = bids[0]?.price; const bestAsk = asks[0]?.price; const spread = bestAsk - bestBid; ``` ## Notes * Returns up to 40 levels per side. Less if the book is thin. * For deeper books or aggregator-spec format, see [Aggregator Compatibility / orderbook](/api-reference/aggregator/orderbook). * `currencyTo` and `currencyFrom` are deprecated — prefer `amount` and `quoteAmount`. # GET /api/tickers Source: https://docs.binibit.com/api-reference/market-data/tickers GET https://public-api.binibit.com/api/tickers 24-hour ticker information for a single trading pair. ## Description Returns the current ticker — last price, 24h price change, 24h volume, best bid and ask — for one trading pair. ## Parameters Pair code in `{base}_{target}` format, e.g. `ETH_BTC`, `TRX_USDT`. See [Currency pair codes](/reference/ticker-id-format). ## Response Last update time, Unix epoch in seconds. Pair code, echoed back. Last traded price (one base unit in target currency). Price 24 hours before the current timestamp. Percentage change of `price` vs `price24hAgo`. 24-hour trading volume in base currency. Current highest bid. Current lowest ask. ## Example request ```bash curl theme={null} curl "https://public-api.binibit.com/api/tickers?currencyPairCode=ETH_BTC" ``` ```javascript Node theme={null} const url = new URL("https://public-api.binibit.com/api/tickers"); url.searchParams.set("currencyPairCode", "ETH_BTC"); const ticker = await fetch(url).then(r => r.json()); ``` ```python Python theme={null} import requests ticker = requests.get( "https://public-api.binibit.com/api/tickers", params={"currencyPairCode": "ETH_BTC"}, ).json() ``` ## Example response ```json theme={null} { "timestamp": 1777458497, "currencyPairCode": "ETH_BTC", "price": 0.03027857, "price24hAgo": 0.02972996, "priceChangePercentage24h": 1.2561641096159775593971696400, "volume24h": 2.53540593, "bidPrice": 0.02981188, "askPrice": 0.0304212 } ``` ## Notes * This endpoint returns a **single** ticker for a specified pair. To list all pairs, use [`GET /api/currencies/pairs`](/api-reference/market-data/currencies-pairs) and combine with this endpoint. * Aggregator-spec equivalent: see [Aggregator Compatibility / tickers](/api-reference/aggregator/tickers) for the CoinGecko-format endpoint that returns all pairs in one call. * `timestamp` is in **seconds**, not milliseconds. # AMM Mechanics Source: https://docs.binibit.com/baidex/amm Uniswap V3 fork with concentrated liquidity and a custom fee router on BiniChain. ## Foundation: Uniswap V3 BaiDEX is a **fork of Uniswap V3**, deployed on BiniChain. All standard V3 concepts apply: * **Concentrated liquidity** — LPs choose a price range; capital is more efficient when the price is in range * **Ticks** — discrete price levels, standard tick spacing * **Position NFTs** — each LP position is an ERC-721 NFT * **Range orders** — LPs can act as limit-order placers by tightly bracketing a tick range If you're familiar with Uniswap V3, BaiDEX feels identical for swap and LP UX. ## What's customized ### Custom fee router (`BaiDexFeeRouter`) Standard V3 sends 100% of swap fees to LPs. BaiDEX intercepts the fee via a router contract and splits it three ways: ``` 0.50% → LP providers 0.25% → burn address (permanent removal of swap-input asset) 0.25% → referrer (or treasury if no referrer) ``` The router is V3-compatible — swaps still go through `SwapRouter02` semantics, but the fee accounting is rewritten. See [Fees](/baidex/fees) for the full mechanism. ### Pool listing rules Standard V3 is permissionless — anyone can pool any pair. BaiDEX is **partly opinionated**: | Asset on the pool side | Listing rule | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **wBINI** | DEX Liquidity (5% / 50M BINI allocation) seeds canonical pools. New wBINI-side pools use whatever wBINI is outside the anchor pool | | **USBI** | Permissionless on the USBI side — anyone with USBI can LP | | **Agent Token** | Auto-listed by the Spawner contract when an Agent Token is spawned; no manual creation needed | Result: there's a wBINI/USBI **anchor pool** (capped at \$12M TVL) and many smaller USBI/Agent-Token + wBINI/Agent-Token pools created either manually or by the Spawner. See [wBINI Cap Rule](/tokenomics/wbini-cap). ### Agent layer (per-pool) Every **Agent Token pool** has an Agent Worker assigned to it (from [Agent Hive](/agent-hive/overview)). The Worker: * Tracks pool depth and trade flow * Reacts to signals from Scouts and Queens * Can execute defined actions (e.g., cancel range order, adjust LP position) within boundaries set by Hive governance The Worker doesn't custody user funds — LPs and traders interact with the V3 contracts directly. The Worker layer is advisory + governance, with strict on-chain logging. ## Tick spacing Standard V3 tick spacing applies. The exact value (1, 10, 60, 200) per pool is set at pool creation and is implementation-defined per BaiDEX deploy. ## Concentrated liquidity in practice | LP scenario | Fees earned | Capital efficiency | | -------------------------------- | ------------------------------------------------- | --------------------------------------------- | | Full-range LP (like V2) | Earns 100% of in-range swap fees pro-rata | Low — a lot of capital sits inactive | | Tight range around current price | Earns much higher per-capital fees while in range | High — but goes "out of range" if price moves | | Lopsided range | Effectively a passive limit order | N/A until price reaches the range | LPs should choose ranges based on their conviction in price stability. BaiDEX UI provides standard V3 tooling. ## Routing BaiDEX exposes the V3 `SwapRouter02` interface. Off-chain routers (1inch, Paraswap) integrate via the standard V3 ABI. Direct quotes via the `Quoter` contract. ## SDK & Integrations The `@uniswap/v3-sdk` works against BaiDEX with a different chain config. Address book values for BiniChain pools are published in [Contract addresses](/baidex/contracts). ## Related The fee router in detail Pool types: wBINI / USBI / Agent Token Standard V3 protections Swap code example # Contracts Source: https://docs.binibit.com/baidex/contracts Smart contract addresses for BaiDEX core, fee router, Spawner, and registry. Production contract addresses on BiniChain mainnet will be published here. Until mainnet launch, the canonical deployment is on Base Sepolia (testnet). ## Base Sepolia (testnet, current) ``` Network: Base Sepolia Chain ID: 84532 Deployed: 2026-04-22 Verified: Blockscout ✓ ``` | Contract | Address | Purpose | | ------------------- | -------------------------------------------- | ------------------------------------------ | | **USBI** | `0xbeC9e1908Aed9252DE56D2B37f67790237AD19Ee` | Stablecoin (ERC-20, mintable/burnable) | | **wBINI** | `0x41Ce230a6Db85c677aa9750F797D98Fd527c705f` | Wrapped BINI (ERC-20, deposit/withdraw) | | **BaiDexFeeRouter** | `0x44eaB92a7aa8A9d8978cca7022d96B3E73957Ecd` | Custom fee proxy for V3 swaps | | **HiveSpawner** | `0x81aCd1F143a2E2901c550F1b40E25EBF5e6E96c5` | Agent Token factory (deploys SpawnedERC20) | | **HiveRegistry** | `0x543D356D975aAe434F3657dfF3fFF5009660B317` | Agent NFT registry (ERC-721 + ERC-8004) | ### Standard V3 contracts The following Uniswap V3 contracts are deployed alongside, with addresses to be published in a follow-up PR (or on BiniChain mainnet when launched): * `UniswapV3Factory` — pool factory * `NonfungiblePositionManager` — LP position NFTs * `SwapRouter02` — primary swap router (use this for `exactInputSingle` etc.) * `Quoter` — off-chain quote helper * `TickLens` — tick query helper * `UniversalRouter` — multi-protocol router (if deployed) ## BiniChain mainnet (future) When BiniChain mainnet launches, the canonical deploy will publish: * All addresses above (renamed without "BaiDex" prefix where applicable) * Bridge contracts (Bridge A, Bridge B) * Anchor pool address (the canonical wBINI/USBI pool) This page will be updated automatically from CI when the deploy happens. ## Roles & access | Contract | Role | Granted to (testnet) | | ------------ | -------------------- | -------------------------------------------------- | | USBI | MINTER\_ROLE | Deployer (will move to bridge contract on mainnet) | | USBI | BURNER\_ROLE | Deployer | | HiveSpawner | DEFAULT\_ADMIN\_ROLE | Deployer | | HiveRegistry | DEFAULT\_ADMIN\_ROLE | Deployer | Mainnet roles will move to multisigs / governance contracts before launch. ## Verification All contracts are verified on Blockscout. View source code: | Contract | Source | | ----------------------- | ------------------------------- | | BaiDexFeeRouter | `contracts/BaiDexFeeRouter.sol` | | HiveSpawner | `contracts/HiveSpawner.sol` | | SpawnedERC20 (template) | `contracts/SpawnedERC20.sol` | | HiveRegistry | `contracts/HiveRegistry.sol` | | USBI | `contracts/USBI.sol` | | WBINI | `contracts/WBINI.sol` | Open-source repository: link will publish with mainnet. ## Test results The Base Sepolia deploy passed **37/37 tests**: * 4 smoke tests (deploy verification, basic ops) * 18 extended tests (full contract interactions, fee math) * 15 V3 pool tests (pool creation, swap through FeeRouter, fee split verification) ## Deployer ``` Address: 0x8CAD91D7b423Ac728eA49077AD7030a593377a04 RPC: https://sepolia.base.org (testnet) / https://rpc.binibit.com (mainnet) ``` The deployer key has rotation planned before mainnet — final mainnet deployer will be a multisig. ## ABI access ABIs for all BaiDEX contracts are published in the @binibit/contracts npm package (when published) or fetchable from BiniChain explorer when verified. For now, ABIs are available on request from [api@binibit.com](mailto:api@binibit.com). ## Related What these contracts implement How to call SwapRouter02 HiveSpawner is the Launchpad backend HiveRegistry holds Agent NFTs # Fees Source: https://docs.binibit.com/baidex/fees 1.00% swap fee split into LP, burn, and referrer (50 / 25 / 25 BPS). See Tokenomics → BINI Sinks for how the burn portion contributes to deflation. ## The split Every swap on BaiDEX charges a **1.00% total fee** (100 basis points), split three ways: ``` TOTAL_FEE_BPS = 100 (1.00%) LP_REWARD_BPS = 50 (0.50%) BURN_BPS = 25 (0.25%) REFERRER_BPS = 25 (0.25%) ``` ``` Total swap fee: 1.00% (100 BPS) ├── 0.50% LP providers (50 BPS) ├── 0.25% Burned permanently (25 BPS) — deflationary └── 0.25% Referrer / treasury (25 BPS) ``` | Slice | Receiver | Burns? | | -------------- | ----------------------------- | ------- | | 0.50% (50 BPS) | LP providers in the pool | No | | 0.25% (25 BPS) | Burn address | **Yes** | | 0.25% (25 BPS) | Referrer (if any) or treasury | No | ## How it works in practice When you swap on BaiDEX: 1. Router intercepts the trade 2. Computes fee = 1.00% of input amount 3. Allocates fee to LPs, burn address, and referrer/treasury per the split 4. Executes the underlying V3 swap with the remaining 99.00% LPs see the 0.50% portion as their realized fee. The 0.50% they "miss" vs Uniswap V3 is going to burn + referrer. ## Burn slice impact The 0.25% burn is **permanent** — every swap removes BINI (or wBINI / USBI / Agent Token, depending on input) from circulation forever. For wBINI swaps, this is a direct BINI sink (sink #3 in [BINI Sinks](/tokenomics/bini-sinks)). For other input assets, the burn affects that asset's circulating supply. ### Daily burn projections (wBINI) If wBINI/USBI volume is \$V/day: ``` Daily wBINI burn (in $) = V × 0.0025 Daily wBINI burn (in BINI at $0.12 ref) = V × 0.0025 / $0.12 ``` | Daily volume (wBINI) | Daily burn (\$) | Daily burn (BINI) | | -------------------: | --------------: | ----------------: | | \$100K | \$250 | 2,083 | | \$1M | \$2,500 | 20,833 | | \$10M | \$25,000 | 208,333 | | \$100M | \$250,000 | 2,083,333 | At \$10M/day wBINI volume, that's \~76M BINI burned per year — comparable to the Year 4 emission rate. ## Referrer slice The 0.25% referrer share goes to: * The user who referred the trader (if applicable), OR * The platform treasury (if no referrer) Referrer payouts are credited per-trade. The referral system itself is on-chain (referrer address is encoded in the swap call). ## LP slice mechanics The 0.50% LP fee accrues to LPs proportional to their share of the in-range liquidity at the moment of the swap. Standard V3 semantics: * Fees accumulate per position * LPs collect fees by calling `collect()` on their position NFT * Out-of-range LPs earn nothing during periods their range is bypassed ## Why 1.00% total? The 1.00% rate is calibrated for: * **Sustainability of burn**: 0.25% is enough to materially shrink supply at moderate volume * **Competitive LP returns**: 0.50% to LPs is comparable to Uniswap's 0.30% tier on volatile pairs (with the trade-off of higher slippage protection from agents) * **Functional referrer mechanic**: 0.25% gives referrers a non-trivial commission Lower total fees would reduce the burn rate. Higher total fees would deter swap volume. ## Comparison | | Uniswap V3 | BaiDEX | | -------------- | ------------------ | ------------------------ | | Lowest tier | 0.05% | n/a | | Stable tier | 0.30% (most pools) | 1.00% | | Volatile tier | 1.00% | 1.00% (single tier) | | Where fee goes | 100% to LPs | 50 LP / 25 burn / 25 ref | | Burn? | No | Yes (0.25%) | ## Related Where the fee router fits The burn portion Where fees accrue How fees compound for Agent Token holders # Liquidity Source: https://docs.binibit.com/baidex/liquidity How LPs provide liquidity, USBI side scaling, and wBINI cap interaction. Tokenomics → Ecosystem Overview shows where DEX liquidity fits into BINI / wBINI / USBI / CRS flows. ## Liquidity flows at a glance ```mermaid theme={null} flowchart TB subgraph Sources["Capital sources"] BridgeA["Bridge A
CRS → USBI
10,000:1 · L5+"] BridgeB["Bridge B
off-chain BINI → native
1:1 · L7+"] CEX["Binibit / Azbit / Blynex
buy ERC-20 BINI
+ chain bridge"] Wrap["Wrap BINI → wBINI
1:1 · BaiDEX UI"] Spawn["AgentT Launchpad
Spawn Agent Token"] end USBIonchain["USBI (on-chain)"] wBINI["wBINI (ERC-20)"] AT["Agent Token (ERC-20)"] subgraph Pools["BaiDEX V3 pools"] Anchor["wBINI / USBI
(anchor · capped \$12M)"] Growth["USBI / Agent Token
(growth pools)"] Premium["wBINI / Agent Token
(premium pools)"] end subgraph AgentLayer["Agent Hive layer"] Worker["Worker assigned
per Agent Pool"] Scout["Scouts watch
cross-pool signals"] Queen["Queens shape
strategy"] end BridgeA --> USBIonchain BridgeB --> Wrap CEX --> Wrap Wrap --> wBINI Spawn --> AT USBIonchain --> Anchor wBINI --> Anchor USBIonchain --> Growth AT --> Growth wBINI --> Premium AT --> Premium Spawn -.- Worker Worker -- monitors --> Growth Worker -- monitors --> Premium Scout -- signals --> Worker Queen -- strategy --> Scout classDef source fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef asset fill:#dcfce7,stroke:#16a34a,color:#14532d classDef pool fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef hive fill:#fce7f3,stroke:#db2777,color:#831843 class BridgeA,BridgeB,CEX,Wrap,Spawn source class USBIonchain,wBINI,AT asset class Anchor,Growth,Premium pool class Worker,Scout,Queen hive ``` ## Becoming an LP Standard Uniswap V3 mechanics: 1. Acquire both pool sides (e.g., wBINI + USBI for the anchor pool, or USBI + Agent Token for a growth pool) 2. Choose a price range (concentrated liquidity) 3. Approve token spending to the V3 position manager 4. Mint a position NFT — the NFT represents your LP stake 5. Collect fees periodically via `collect()` on your position 6. Remove liquidity by calling `decrease()` and then `burn()` The position NFT is transferable — you can sell, gift, or use it as collateral in future composable systems. ## Capital sources ### USBI side USBI for LP comes from your **on-chain USBI balance**, which you got by [Bridge A](/bini-app/usbi-bridge) (CRS → USBI 10,000:1 at L5+). Maximum USBI you can ever LP per account = your total entitlement = `1,000 + min(XP/10,000, 100,000)`. Practical implication: a Level 30 user can LP up to \~101K USBI lifetime. ### wBINI side wBINI for LP comes from **wrapping native BINI** on BiniChain. To get native BINI: * Bridge from Ethereum (ERC-20 → native via BiniChain bridge) * Earn off-chain BINI in Bini App + use [Bridge B](/bini-app/bini-bridge) (1:1, L7+) * Buy on Binibit Exchange / Azbit / Blynex and bridge Once you have native BINI, wrap to wBINI via the wBINI contract or BaiDEX UI (1:1, no fee). ### Agent Token side Agent Tokens come from: * Spawning your own (AgentT Launchpad) * Buying via swaps on BaiDEX * Air-drops, sales, etc. (varies per project) ## Liquidity bootstrapping When a new Agent Token is spawned, the **Spawner contract auto-creates an Agent Pool** (wBINI/AT or USBI/AT depending on config). It seeds the pool with: * A small initial wBINI or USBI side from the spawn fee allocation, OR * Zero initial liquidity (LPs must seed) The exact bootstrapping policy is set per-launch by the team. Most Agent Tokens will need user-LPs to deposit to bootstrap meaningful trading. For the anchor wBINI/USBI pool, the team seeded it at TGE using the DEX Liquidity allocation (50M BINI / 5%). ## In-range vs out-of-range liquidity V3 LPs choose a price range. Earnings depend on whether the current price is in your range: | State | LP earns? | | ------------------------ | ------------------------------------------------------------- | | Price is in your range | Yes — earns 0.50% LP fee on swaps that pass through your tick | | Price moves out of range | No — your liquidity is "asleep" until price returns | Tighter ranges = higher capital efficiency when in range, higher chance of going out. Wider ranges = lower efficiency but more reliable earnings. ## Impermanent loss Standard concentrated-liquidity IL applies. For: * **Stable pairs** (USBI/Agent Token where the AT trades sideways) — moderate IL * **Volatile pairs** (wBINI/Agent Token, or USBI/AT during price discovery) — higher IL LPs should size their position based on conviction and time horizon. There is no IL protection mechanism on BaiDEX. ## USBI side scaling The USBI side of growth pools scales naturally with the user base because: ``` Total USBI in ecosystem ≈ N_users × avg_entitlement_per_user ≈ N_users × ~50,000 (mid-progression typical) ``` | Users | Estimated total USBI | Of which 10% in LP (typical) | | -----: | -------------------: | ---------------------------: | | 500 | 25M USBI | 2.5M USBI | | 1,000 | 50M USBI | 5M USBI | | 10,000 | 500M USBI | 50M USBI | | 50,000 | 2.5B USBI | 250M USBI | The 10% LP assumption is heuristic. Actual deposit rate depends on user behavior. ## wBINI cap interaction The 50M wBINI cap (5% of BINI supply) constrains how much wBINI can be LP'd across all pools combined. ``` Anchor pool consumes: ~50M wBINI worth at cap ($6M) Premium pools consume: remaining wBINI (any amount up to balance) ``` If users want to LP wBINI in a premium pool while the anchor is at cap, they need wBINI that wasn't sourced from DEX Liquidity allocation — i.e., wrapped from organic BINI buying or staking unlocks. See [wBINI Cap Rule](/tokenomics/wbini-cap). ## Provider rewards (beyond fees) LPs earn **just the 0.50% LP fee share** on swaps. There is no additional emission of BINI to LPs from the Rewards pool by default. If a specific Agent Pool needs liquidity boostrap, the team may allocate emission to incentivize that pool — these are announced per case. ## Removing liquidity Standard V3: * Decrease position to receive both sides back proportional to current price * Burn position NFT after fully decreasing * Pay BiniChain gas in BINI for the transaction ## Cross-product flow summary | Step | Where | Page | | ------------------------ | -------------------- | ---------------------------------------- | | Earn CRS | Bini App | [Claim & mining](/bini-app/claim-mining) | | Spend CRS → XP | Tokenomics | [XP formula](/tokenomics/xp-formula) | | XP → USBI entitlement | Tokenomics | [USBI formula](/tokenomics/usbi-formula) | | Bridge CRS → USBI | Bini App / BiniChain | [Bridge A](/bini-app/usbi-bridge) | | Bridge BINI off → native | Bini App / BiniChain | [Bridge B](/bini-app/bini-bridge) | | Wrap native → wBINI | BaiDEX | wrap on BaiDEX UI | | Provide LP | BaiDEX | this page | | Worker manages pool | Agent Hive | [Workers](/agent-hive/workers) | | Scout / Queen oversight | Agent Hive | [Hierarchy](/agent-hive/hierarchy) | ## Related The three pool types Why the cap shapes pool liquidity Where USBI comes from Where native BINI for wrapping comes from Workers managing your pool How spawn fees and trade burns affect liquidity # BaiDEX Overview Source: https://docs.binibit.com/baidex/overview Agent-managed Uniswap V3 AMM on BiniChain. The DEX where every token has an agent brain. Tokenomics → Ecosystem Overview shows how BaiDEX fits into the wider system. ## What BaiDEX is BaiDEX is a **Uniswap V3-compatible AMM** running on BiniChain, with two distinguishing features: 1. **Custom fee router** — 1.00% total fee split into LP / burn / referrer 2. **Agent layer** — every Agent Token pool is managed by an Agent Worker from the [Agent Hive](/agent-hive/overview) Standard V3 mechanics for liquidity providers. Standard router for swaps. Plus an automatic agent-managed top layer that doesn't exist on other DEXes. ## Headline numbers | | | | ---------------- | ----------------------------------------------- | | AMM model | Uniswap V3 fork | | Fee total | 1.00% (100 BPS) | | LP share | 0.50% (50 BPS) | | Burn share | 0.25% (25 BPS) — permanent | | Referrer share | 0.25% (25 BPS) — or treasury | | Pool types | wBINI/USBI, USBI/Agent Token, wBINI/Agent Token | | Smart contracts | See [Contract addresses](/baidex/contracts) | | Settlement chain | BiniChain | ## Inside the docs V3 fork, concentrated liquidity, tick spacing 1.00% = 50 LP + 25 burn + 25 referrer (BPS) wBINI/USBI, USBI/AT, wBINI/AT LP rules, USBI side scaling, wBINI cap Swap example via V3 router Standard V3 protections Smart contract addresses on BiniChain ## Quick fee summary ``` Total swap fee: 1.00% (100 BPS) ├── 0.50% LP providers (50 BPS) ├── 0.25% Burned permanently (25 BPS) — deflationary └── 0.25% Referrer / treasury (25 BPS) ``` See [Fees](/baidex/fees) for the full breakdown. ## Architecture ```mermaid theme={null} flowchart TB User((Trader / LP)) FeeRouter["BaiDexFeeRouter
1.00% split: 50/25/25 BPS"] subgraph Pools["V3 Pools"] Anchor["wBINI / USBI
(anchor)"] Growth["USBI / Agent Token
(growth)"] Premium["wBINI / Agent Token
(premium)"] end subgraph Agents["Agent Layer (Hive)"] Worker["Agent Worker
per pool"] Scout["Agent Scouts
cross-pool signals"] Queen["Agent Queens
strategy"] end LP["LP providers
0.50%"] Burn["Burn address
0.25% — deflationary"] Ref["Referrer / treasury
0.25%"] User -- swap --> FeeRouter FeeRouter --> LP FeeRouter --> Burn FeeRouter --> Ref FeeRouter --> Anchor FeeRouter --> Growth FeeRouter --> Premium Worker -- monitors --> Growth Worker -- monitors --> Premium Scout -- signals --> Worker Queen -- strategy --> Scout classDef pool fill:#dcfce7,stroke:#16a34a,color:#14532d classDef hive fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef burn fill:#fef2f2,stroke:#ef4444,color:#7f1d1d classDef user fill:#fce7f3,stroke:#db2777,color:#831843 classDef router fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e class Anchor,Growth,Premium pool class Worker,Scout,Queen hive class Burn burn class User user class FeeRouter router ``` ## How it differs from Uniswap V3 | | Uniswap V3 | BaiDEX | | --------------- | ------------------------ | --------------------------------------------------------- | | Tick math | Standard | Standard | | Fee tiers | 0.05/0.30/1.00% | Single 1.00% (with custom router) | | LP share of fee | 100% to LPs | 50% to LPs, 25% burn, 25% referrer | | Pool management | None — pure AMM | Workers (one per Agent Token pool) layer additional logic | | Token listing | Anyone can pool any pair | wBINI side capped, USBI side scales with users | ## Related Spawn an Agent Token, get an Agent Pool here Workers managing every pool Where BaiDEX runs Why pool topology matters # Pools Source: https://docs.binibit.com/baidex/pools Three pool types: wBINI/USBI, USBI/Agent Token, wBINI/Agent Token. See Tokenomics → wBINI Cap Rule for why pool topology matters and how the \$240M ceiling shapes liquidity flow. ## Three pool types BaiDEX supports three canonical pool configurations: | Pool type | Role | Liquidity ceiling | | ----------------------- | ------------------------------------------------------ | ------------------------------------------ | | **wBINI / USBI** | Anchor pool — gives USBI a real-value reference | Capped at $12M TVL ($6M wBINI + \$6M USBI) | | **USBI / Agent Token** | Growth pools — primary trading venue for Agent Tokens | Uncapped (USBI side scales with user XP) | | **wBINI / Agent Token** | Premium pools — Agent Tokens with direct BINI exposure | Limited by remaining wBINI outside anchor | Other pools (e.g., direct Agent-Token-to-Agent-Token) are technically possible but discouraged by the topology. ## Topology ```mermaid theme={null} flowchart TB Anchor["wBINI / USBI
Capped at \$12M TVL
(one canonical pool)"] Growth["USBI / Agent Token (×N)
USBI side scales with users
(growth pools)"] Premium["wBINI / Agent Token (×M)
Limited by available wBINI
(premium pools)"] Anchor -- "trades clear here" --> Growth Anchor -.- Premium classDef anchor fill:#dcfce7,stroke:#16a34a,color:#14532d classDef growth fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef premium fill:#fef9c3,stroke:#ca8a04,color:#713f12 class Anchor anchor class Growth growth class Premium premium ``` ## wBINI / USBI (anchor pool) **One canonical pool**, capped at \$12M TVL. The wBINI side caps at $6M (50M BINI × $0.12 reference price). The USBI side mirrors it at \$6M to keep the pool balanced. The anchor pool serves as: * The **price oracle** for wBINI vs USBI * The trading venue for users who want to convert between wBINI and USBI directly * The reference benchmark for off-chain valuations of BINI LPs in the anchor pool earn the 0.50% LP fee from all swaps that route through it. As DEX volume grows, the anchor sees the highest absolute fee revenue — but is also the most contested LP slot due to the cap. ## USBI / Agent Token (growth pools) **One per Agent Token**, auto-listed when the token is spawned via [AgentT Launchpad](/agentt-launchpad/overview). Why USBI as the pair side: * USBI is a sandbox stablecoin → low volatility relative to fiat * USBI scales with user XP entitlement → there's always more USBI to LP as user count grows * No cap on USBI side → these pools can grow large These are the **primary trading venues** for the bulk of Agent Token activity. Most user trades clear here. ## wBINI / Agent Token (premium pools) **Optional pools** for Agent Tokens that want direct BINI exposure (and the volatility / opportunity that comes with it). Why these are limited: * wBINI total supply is capped at 50M (5% of BINI total) * The anchor pool consumes a chunk of available wBINI * Remaining wBINI is split across premium pools A new wBINI/Agent-Token pool requires either: * Existing wBINI holders to provide the wBINI side * Treasury seeding (rare — usually for high-priority projects) ## Liquidity dynamics | User count | Growth pool USBI side (typical) | Anchor pool TVL | | ---------: | ------------------------------: | -------------------------------: | | 500 | \$50K | \$1-2M (well below cap) | | 1,000 | \$100K | \$2-4M | | 10,000 | \$1M | Approaches cap | | 50,000+ | \$10M+ | At cap, overflow to growth pools | See [Tokenomics → Simulation](/tokenomics/simulation) for projections. ## Permissionless or not? | | Permissionless? | | ---------------------------------------------- | ---------------------------------------------------------- | | Adding LP to existing pool | Yes | | Spawning Agent Token (auto-creates pool) | Yes (anyone can spawn) | | Creating a new wBINI/USBI pool | No (anchor is canonical, single instance) | | Creating arbitrary new pools (e.g., USBI/USDT) | Effectively no — no infrastructure for non-canonical pools | ## Worker per pool Every Agent Token pool has a Worker assigned (from [Agent Hive](/agent-hive/overview)). The Worker provides a management layer **on top** of the V3 mechanics: * Tracks pool depth * Reacts to Scout signals (e.g., new launches, volume spikes) * Receives strategy from Queens * Logs all actions on-chain Workers do not custody user funds. LPs and traders interact with the V3 contracts directly. ## Related LP rules and bootstrapping Why the topology Spawn auto-creates a pool Workers managing each pool # Slippage & MEV Source: https://docs.binibit.com/baidex/slippage-mev Standard V3 protections plus considerations for thin Agent Pools. ## Slippage Slippage is the difference between the price you expect and the price you get. On AMMs, it scales with: 1. **Trade size** relative to pool depth 2. **Volatility** during the time between quote and execution 3. **Other trades** sandwiching yours Set your slippage tolerance in the swap UI or `swapOptions.slippageTolerance`. ### Recommended slippage by pool | Pool | Typical slippage | | ------------------------------- | ---------------- | | wBINI/USBI (anchor) | 0.10 – 0.50% | | USBI/Agent Token (high volume) | 0.50 – 1.50% | | USBI/Agent Token (low volume) | 1.50 – 5.00% | | wBINI/Agent Token (high volume) | 0.50 – 2.00% | | wBINI/Agent Token (thin) | 2.00 – 5.00% | For very thin pools, slippage can blow out — consider chunking large trades or using a router that splits across multiple pools. ### Why default 0.50% works most of the time The wBINI/USBI anchor pool is well-funded → 0.50% covers normal execution. Most user trades clear here or via single-hop into a healthy growth pool. For Agent Token swaps in fresh pools, **raise slippage** to avoid failed transactions. ## Failed transactions ("Out of slippage") If price moved more than your tolerance between quote and execution, the V3 router reverts. You pay gas, get no swap. Mitigations: * Raise slippage tolerance * Reduce trade size (smaller fraction of pool) * Wait for low volatility (off-peak hours) ## MEV (Maximal Extractable Value) V3 swaps are public mempool transactions. Sandwich attacks are possible: ``` 1. You broadcast a buy with X% slippage tolerance 2. Searcher sees pending tx, front-runs with their own buy (raises pool price) 3. Your tx executes at the worse price (within your tolerance) 4. Searcher sells immediately, profiting from the price difference ``` ### BaiDEX MEV protections | Protection | Status | | --------------------------------------- | --------------------------------------------------------------- | | Standard V3 `sqrtPriceLimitX96` | Yes — set this in your swap to prevent execution beyond a price | | Slippage tolerance check | Yes — V3 native | | Private mempool / Flashbots-style relay | TBD — see roadmap | | Builder API / commit-reveal | TBD | For now, MEV protection on BaiDEX is at the **slippage tolerance level**. Set it conservatively for large trades. ### Worker-layer signals (future) The Agent Hive Worker assigned to each pool can in principle: * Detect anomalous trade patterns (sandwich-like flows) * Flag suspect transactions in on-chain logs * Suggest tightening pool parameters This is a Phase-2 capability. Currently, Workers are advisory rather than execution-blocking. ## Limit-order behavior V3's range orders effectively act as limit orders: * LP a tight range above current price → sells the in-range asset when price rises into range * LP a tight range below current price → buys when price drops This works on BaiDEX identically to Uniswap V3. Useful for setting a "I want to sell BINI at \$0.15" type order without active management. ## Transaction priority BiniChain transactions follow a standard fee market. Higher gas price = faster inclusion. For time-sensitive trades: * Increase gas price (priority fee) * Use a limited-time deadline (`block.timestamp + 60`) so stale transactions revert ## Trade execution checklist Before signing a swap: * [ ] Slippage tolerance is appropriate for pool depth * [ ] Output amount looks reasonable (not 0, not absurd) * [ ] You have enough native BINI for gas * [ ] Deadline is short enough that the tx won't sit pending overnight * [ ] You've approved the input token to the router ## Related Code examples Pool depth varies by type The 1.00% fee is on top of slippage Worker layer (future MEV signals) # Trading Guide Source: https://docs.binibit.com/baidex/trading-guide Swap on BaiDEX via the V3 router. Examples in JavaScript and Solidity. ## Quick swap (BaiDEX UI) 1. Open the BaiDEX UI on [binibit.com](https://binibit.com/?i=7r2c8t) (or BaiDEX subdomain when published) 2. Connect your wallet (MetaMask, WalletConnect, Telegram-native wallet) 3. Switch network to BiniChain 4. Pick the pair (e.g., USBI → an Agent Token) 5. Enter amount, view price impact and minimum out 6. Confirm — pay BiniChain gas in BINI, receive output token ## Swap via SDK (programmatic) BaiDEX exposes the standard Uniswap V3 `SwapRouter02` interface. Use `@uniswap/v3-sdk`: ```javascript theme={null} import { ethers } from "ethers"; import { SwapRouter, Token, CurrencyAmount, TradeType, Percent } from "@uniswap/sdk-core"; import { Pool, Route, Trade, SwapOptions } from "@uniswap/v3-sdk"; const CHAIN_ID = /* BiniChain chainId */; const SWAP_ROUTER_ADDRESS = "0x..."; // see /baidex/contracts const provider = new ethers.JsonRpcProvider("https://rpc.binibit.com"); const signer = new ethers.Wallet(privateKey, provider); // Token instances const USBI = new Token(CHAIN_ID, "0x...USBI", 18, "USBI", "Binibit USBI"); const WBINI = new Token(CHAIN_ID, "0x...wBINI", 18, "wBINI", "Wrapped BINI"); // Build pool, route, trade as standard V3 SDK... // (full pool fetch and trade construction omitted for brevity) const swapOptions = { slippageTolerance: new Percent(50, 10_000), // 0.50% deadline: Math.floor(Date.now() / 1000) + 60 * 10, recipient: signer.address, }; const { calldata, value } = SwapRouter.swapCallParameters(trade, swapOptions); const tx = await signer.sendTransaction({ data: calldata, to: SWAP_ROUTER_ADDRESS, value, gasLimit: 500_000, }); await tx.wait(); ``` ## Swap via Solidity (on-chain integration) ```solidity theme={null} // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@uniswap/v3-periphery/contracts/interfaces/ISwapRouter.sol"; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; contract MyContract { ISwapRouter public immutable swapRouter; address public constant WBINI = 0x...; address public constant USBI = 0x...; constructor(ISwapRouter _swapRouter) { swapRouter = _swapRouter; } function swapWbiniForUsbi(uint256 amountIn, uint256 amountOutMinimum) external returns (uint256 amountOut) { IERC20(WBINI).transferFrom(msg.sender, address(this), amountIn); IERC20(WBINI).approve(address(swapRouter), amountIn); ISwapRouter.ExactInputSingleParams memory params = ISwapRouter.ExactInputSingleParams({ tokenIn: WBINI, tokenOut: USBI, fee: 10_000, // 1.00% (BaiDEX single tier) recipient: msg.sender, deadline: block.timestamp + 600, amountIn: amountIn, amountOutMinimum: amountOutMinimum, sqrtPriceLimitX96: 0, }); amountOut = swapRouter.exactInputSingle(params); } } ``` ## Quote a trade (no swap) Use the V3 `Quoter` contract to get an expected output amount before swapping: ```javascript theme={null} import { ethers } from "ethers"; const QUOTER_ADDRESS = "0x..."; // see /baidex/contracts const QUOTER_ABI = [ "function quoteExactInputSingle(address tokenIn, address tokenOut, uint24 fee, uint256 amountIn, uint160 sqrtPriceLimitX96) external returns (uint256 amountOut)", ]; const quoter = new ethers.Contract(QUOTER_ADDRESS, QUOTER_ABI, provider); const amountOut = await quoter.quoteExactInputSingle.staticCall( WBINI_ADDRESS, USBI_ADDRESS, 10_000, // 1.00% fee tier ethers.parseEther("1"), 0, ); console.log("Expected output:", ethers.formatEther(amountOut), "USBI"); ``` ## Multi-hop swaps V3 supports multi-hop via `exactInput` (encode path as a sequence of token addresses + fee tiers). ```solidity theme={null} // Path: WBINI → USBI → AgentToken bytes memory path = abi.encodePacked(WBINI, uint24(10_000), USBI, uint24(10_000), AGENT_TOKEN); ISwapRouter.ExactInputParams memory params = ISwapRouter.ExactInputParams({ path: path, recipient: msg.sender, deadline: block.timestamp + 600, amountIn: amountIn, amountOutMinimum: amountOutMinimum, }); amountOut = swapRouter.exactInput(params); ``` Off-chain routers (1inch, Paraswap) integrate with BaiDEX as a V3 instance — they handle multi-hop automatically. ## Slippage settings Default slippage = 0.50%. For: * Tight liquidity pools (small Agent Tokens) → use higher slippage (1-3%) * Anchor wBINI/USBI pool → 0.10-0.50% works most days * Cross-pool routes → add per-hop slippage budget See [Slippage & MEV](/baidex/slippage-mev). ## Approval requirement Before any swap, the input token's `approve()` must be called for the SwapRouter address. Standard ERC-20 approval flow. For repeat traders, the standard pattern is `approve(spender, type(uint256).max)` — but this gives the router unlimited approval for that token. Trade off security vs convenience. ## Gas Every swap pays gas in **native BINI**. Typical V3 swap gas: | Swap type | Gas estimate | | -------------------------- | ------------: | | Single-hop within one pool | \~150,000 gas | | Multi-hop (2 pools) | \~250,000 gas | | Multi-hop (3 pools) | \~350,000 gas | Multiply by current BiniChain gas price for the BINI cost. ## Related V3 fork details 1.00% fee mechanics Protection settings Router and pool addresses # BINI Bridge (Bridge B) Source: https://docs.binibit.com/bini-app/bini-bridge Convert off-chain BINI rewards to native BINI on BiniChain at 1:1, unlocked at Level 7. See Tokenomics → BINI Bridge for the supply impact and anti-sybil rules. ## What it does Bridge B converts off-chain BINI (from Bini App quest rewards, lottery winnings, special grants) into native BINI on BiniChain at 1:1. ``` 1 BINI off-chain = 1 BINI native ``` Fixed 1:1, no fee on the bridge itself. ## Unlock Bridge B unlocks at **Level 7** (105,000,000 cumulative XP). The L7 gate is two levels higher than [Bridge A](/bini-app/usbi-bridge) (L5) because BINI is a real-value asset. The extra gating reduces sybil and farm-account risk. ## How to use it 1. Open the Bini App 2. Navigate to Bridges → BINI Bridge 3. Choose how much off-chain BINI to bridge 4. Confirm — your off-chain balance decreases, native BINI is sent to your BiniChain address 5. View on [scan.binibit.com](https://scan.binibit.com) or in your wallet ## Caps Subject to product confirmation, monthly caps may apply (e.g., max bridge amount per month). The exact policy is set by team and announced in-app. ## Gas cost The bridge action is a BiniChain transaction → costs gas in **native BINI**. For your **first bridge**, you'll have no native BINI to pay gas. The Bini App handles this via: * Auto-relay (the protocol covers gas for the first bridge), or * A small native BINI subsidy on signup, or * Buying BINI from Binibit Exchange and bridging from Ethereum first The exact mechanism is set by the team — check the Bini App UI for the current method. ## What native BINI is for Once you have native BINI on BiniChain, you can: | Use | Where | | -------------------------------------------------------- | -------------------------------------- | | Pay gas for any BiniChain transaction | Native chain | | Wrap to wBINI for liquidity provision | [BaiDEX](/baidex/overview) | | Buy lottery tickets | [Lottery](/bini-app/lottery) (Phase 2) | | Pay [Agent Token spawn cost](/agentt-launchpad/overview) | AgentT Launchpad | | Send to other addresses | Standard transfer | | Withdraw to ERC-20 BINI on Ethereum | Reverse bridge | ## Bridge B vs Bridge A | | Bridge A (USBI) | Bridge B (BINI) | | ------------------------- | ---------------------------- | ----------------------------------- | | Source asset | CRS off-chain | BINI off-chain | | Target asset | USBI ERC-20 | BINI native | | Ratio | 10,000 : 1 | 1 : 1 | | Real value? | Sandbox \$ | Real \$ | | Level gate | L5 | L7 | | Tied to entitlement | Yes (USBI cap) | No (limited by earned BINI) | | Source of off-chain asset | Mining + bridges-as-XP-cycle | Quest rewards, lottery wins, grants | ## Anti-sybil The combination of: * Level 7 gate (engagement requirement) * Monthly caps (subject to product confirmation) * Source-side anti-sybil (Bini App backend tracks signal quality) means farming the rewards pool through Bridge B is bounded. ## Sandbox vs Mainnet In sandbox, off-chain BINI represents accrued ecosystem rewards. Mainnet may tighten: * Stronger anti-sybil (KYC / IP / behavioral) * Different gating logic (activity-based, not just level-based) * Real BINI farming via on-chain staking and LP incentives See [Tokenomics → Sandbox vs Mainnet](/tokenomics/ecosystem-overview). ## Related Full mechanic and supply impact Bridge A: CRS → USBI What native BINI is for Wrap to wBINI for liquidity # Claim & Mining Source: https://docs.binibit.com/bini-app/claim-mining Background CRS accrual at 10K/hour base + lesson bonuses, claimed every 4 hours. ## How mining works CRS mining runs **continuously in the background** — you do not need to keep the app open. The Bini App backend tracks your mining rate and accrued amount. Every **4 hours** you can **claim** the accumulated CRS to your balance. If you don't claim, the bucket stops filling at 4 hours of accumulation (the "claim window"). ``` Mining rate (CRS/hour) = 10,000 + sum of lesson bonuses Claim window = 4 hours Reward per claim = mining_rate × 4 ``` ## Base mining rate ``` Base: 10,000 CRS/hour ``` Every user — Level 1 or Level 30 — earns at least the base rate. This is non-decaying and not tied to lesson progress. ## Lesson bonuses Each lesson upgrade adds CRS/hour. With all 30 lessons at L1, you get +18,465 CRS/hour (29% boost over base). With all 30 at L10, you get +184,650 CRS/hour (\~19× over base). | State | Total CRS/hour | 4h claim | 2 claims/day | 3 claims/day | | -------------------- | -------------: | -------: | -----------: | -----------: | | Level 1 (no lessons) | 10,000 | 40,000 | 80,000 | 120,000 | | All lessons L1 | 28,465 | 113,860 | 227,720 | 341,580 | | All lessons L5 | 102,325 | 409,300 | 818,600 | 1,227,900 | | All lessons L10 | 194,650 | 778,600 | 1,557,200 | 2,335,800 | See [Lessons](/bini-app/lessons) for the cost curve to reach each milestone. ## The 4-hour claim window ```mermaid theme={null} flowchart LR T0["T=0
Last claim"] -- "fills 50%" --> T2["T=2h"] T2 -- "fills to 100%" --> T4["T=4h
Ready to claim"] T4 -- "no further fill
until claimed" --> Cap["T=4h+
Bucket capped"] Cap -- "user claims" --> T0 classDef wait fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef ready fill:#dcfce7,stroke:#16a34a,color:#14532d classDef cap fill:#fef2f2,stroke:#ef4444,color:#7f1d1d class T0,T2 wait class T4 ready class Cap cap ``` This design forces a minimum cadence — coming back twice a day is the easy path. Three or more claims per day requires more attention but yields more daily CRS (no "compounding" — just more time inside the 4h window per day). ## Daily calendar In addition to per-claim rewards, the Bini App offers a **30-day rotating CRS calendar**. Each consecutive day claimed unlocks a bonus. Missing a day breaks the streak. ``` Day 1: Small bonus Day 2: Slightly bigger bonus ... Day 30: Largest bonus Day 31: Reset to Day 1 (new cycle) Total cycle reward: 48,527,500 CRS ``` The exact per-day curve is back-loaded — most of the cycle reward is in the last 9 days. This rewards consistency. ## Why this design * **Background mining** — works while you sleep, not just when you tap * **4-hour claim window** — forces engagement without being demanding (twice a day is enough) * **Cap at 4 hours** — prevents a "set and forget for a week" play style that doesn't grow the lesson bonus * **Daily calendar** — rewards consistency, with most reward at the end of the streak ## Time to reach all-lessons-L10 Per the canonical simulation: | Cadence | Day all lessons L10 | | ------------------------------ | ------------------: | | 2 claims/day, no referrals | 109 | | 3 claims/day, no referrals | 91 | | 2 claims/day + 100 active refs | 90 | See [Tokenomics → Simulation](/tokenomics/simulation) for full projections. ## Related Where the CRS/hour bonuses come from What CRS spending unlocks Convert CRS to USBI Earn from your team's mining # Franchise Statuses Source: https://docs.binibit.com/bini-app/franchise Member → Builder → Manager → Director → Partner. Status tiers based on cumulative engagement. Franchise tier thresholds are still being finalized by the team. The structure (5 tiers) is canonical; specific CRS / referral / time thresholds will be confirmed before mainnet launch. ## What franchise is Franchise is a **status / role progression system** in the Bini App. Unlike user [Levels](/bini-app/levels) (which scale with XP from CRS spend), franchise tracks **cumulative engagement and team-building**. It's a parallel progression — a power user with no team can hit Level 30 but stay at the lowest franchise tier. A user with a large active team can reach a high franchise tier even at mid Levels. ## The five tiers | Tier | Approximate role | Typical milestones | | ------------ | --------------------------- | ------------------------------------------------------------ | | **Member** | Default tier on signup | Active claiming, some referrals | | **Builder** | Has a small active team | Several active refs, regular claims, completed core lessons | | **Manager** | Mid-size active team | Larger active team, hit lesson maxes, some Bridge A activity | | **Director** | Significant team + activity | Substantial team, deep DEX participation, holds Agent Tokens | | **Partner** | Top tier | Highest team contribution, ecosystem leader | Specific thresholds (active ref count, cumulative CRS, days active, level requirement) will be defined in the canonical Bini App spec. ## What each tier unlocks | Tier | Benefits | | -------- | ------------------------------------------------------------------- | | Member | Base experience | | Builder | Possible CRS multiplier on own mining, badge in profile | | Manager | Higher cosmetic tier, possibly improved cap on Bridge B | | Director | Larger advantages — exact perks TBD | | Partner | Top-tier perks: governance weight, branding, possibly revenue share | The exact perks per tier are being finalized by product. ## Franchise vs Level vs R0-R8 Three parallel progressions in the Binibit ecosystem: | System | Driven by | Resets? | Where | | --------------------- | -------------------------------- | ----------------------- | ---------------- | | **User Level (1-30)** | Cumulative XP from CRS spend | Never | Bini App | | **Franchise tier** | Engagement + team activity | Possibly seasonal | Bini App | | **R0-R8** | Staked BINI + team staked volume | Continuous reassessment | Binibit Exchange | You can be: * High Level + low Franchise (solo grinder) * Mid Level + high Franchise (community-focused) * High R0-R8 + low Level (whale staker who doesn't play the app) All three are valid paths. ## How to advance franchise tier * Build an active referral team (see [Referrals](/bini-app/referrals)) * Maintain claim consistency (avoid breaking streaks) * Engage with the lesson loop * Use the bridges * Participate in lottery, spawn Agent Tokens The franchise system rewards **breadth of engagement**, not just CRS spending depth. ## Seasonal resets Specific franchise tiers may reset on a seasonal cadence (quarterly, annual) so that long-term inactive users don't hold tier indefinitely. Reset rules are TBD — check the Bini App for current policy. ## Tokenomics impact Franchise tiers allocate part of the Rewards pool to engagement-based bonuses. The exact allocation (out of the 600M Rewards pool over 4 years) is a per-month policy decision. This complements the simple CRS-spend-based emission and rewards a different behavior: community building and breadth of engagement. ## Related XP-based progression 3-level CRS team rewards Staking-based progression Where everything connects # 30 Lessons (Upgrade Cards) Source: https://docs.binibit.com/bini-app/lessons The income engine: 30 lessons, 10 levels each, each upgrade boosts CRS/hour mining rate. See Tokenomics → Lessons for the cost and bonus formulas, milestones, and validation math. ## Structure ``` 30 lessons × 10 levels = 300 upgrade actions ``` Each lesson is a topic. Each level of a lesson costs more CRS and adds more CRS/hour to your mining rate. Maxing a lesson means taking it to L10. Maxing **all 30 lessons to L10** costs **230,000,000 CRS** total and brings you to **Level 10 / 24,000 USBI** (with welcome grant). ## What a lesson card looks like A lesson card has four parts: | Part | Purpose | | --------------- | --------------------------------------------- | | **Question** | The educational hook. "What's an order book?" | | **Answer** | One-paragraph explanation | | **Facts** | Three or four memorable bullets | | **Infographic** | Visual aid (image or animation) | | **Upgrade** | The CRS-spend button at the bottom | Reading the card teaches you something. Pressing Upgrade boosts your mining. ## Cost formula ``` lesson_upgrade_cost = baseCost × 1.217595 × 2^(lessonLevel - 1) ``` Each subsequent level **doubles** in cost. The `1.217595` global multiplier is calibrated so the sum of all 300 upgrades equals 230M CRS exactly. ## Bonus formula ``` lesson_bonus_per_hour = baseBonus × lessonLevel ``` A lesson at L10 produces 10× the per-hour bonus of the same lesson at L1. ## Aggregate milestones | Milestone | Cumulative cost | Total bonus/hr | 4h claim | 2 claims/day | Total USBI | | --------------- | --------------: | -------------: | -------: | -----------: | ---------: | | All lessons L1 | 224,829 CRS | 18,465 | 113,860 | 227,720 | 1,022 | | All lessons L3 | 1,573,803 CRS | 55,395 | 261,580 | 523,160 | 1,157 | | All lessons L5 | 6,969,697 CRS | 92,325 | 409,300 | 818,600 | 1,696 | | All lessons L7 | 28,553,275 CRS | 129,255 | 557,020 | 1,114,040 | 3,855 | | All lessons L10 | 230,000,000 CRS | 184,650 | 778,600 | 1,557,200 | 24,000 | ## Strategy — order of upgrades There is no single "right" order, but two general approaches work: ### Round-robin Take all 30 lessons to L1, then all to L2, then all to L3, etc. This produces the smoothest mining-rate growth. ### Domain-first Pick a topic you find most relevant to your trading style and max it before moving on. This produces faster early gains in one area but uneven mining-rate growth. The math is symmetric — you reach all-L10 at the same cost either way. The choice is about pacing, not optimization. ## What lessons are about The 30 lessons span trading, exchanges, DeFi, BiniChain, BaiDEX, agents, security, and tokenomics topics. The MiniLessons v4.0 spec defines the exact list. Examples: * "What's an order book?" * "How does an AMM differ from an order book?" * "What is a liquidity pool?" * "What's a launchpad?" * "How do agent-managed pools work?" * "What are token sinks?" A user who maxes all 30 lessons has read 30 short crypto explainers as a side effect of upgrading their mining. ## Spending CRS on lessons creates XP Every CRS spent on a lesson upgrade counts toward [XP](/tokenomics/xp-formula). Maxing all lessons gives you 230M XP — see [User Levels](/tokenomics/user-levels) to translate that into a level. ## Related Cost & bonus math What lesson bonuses boost Level 10 = all lessons L10 What XP unlocks # Levels (Seed → Genesis) Source: https://docs.binibit.com/bini-app/levels 30 levels with XP thresholds, USBI entitlement, and unlock gates. See Tokenomics → User Levels for the full XP-vs-USBI table for all 30 levels. ## What "level" means in Bini App Your level is your **cumulative engagement score**. It is set by [XP](/tokenomics/xp-formula), and XP comes from CRS spent — so spending CRS (on lessons, bridges, sinks) is what levels you up. Higher levels unlock: * More USBI entitlement * Bridge A (Level 5) * Bridge B (Level 7) * Voting on Hive Workers (Level 20) * Genesis-level rewards (Level 30) ## The 30 levels Stages from Seed to Genesis: | Range | Stage | What's typical here | | ----------- | ------------- | ------------------------------------------------ | | **L1** | Start | Just signed up, welcome grant in pocket | | **L2-L4** | Early game | First lesson upgrades, tasting the loop | | **L5-L7** | Bridge era | Bridge A unlocks at L5, Bridge B at L7 | | **L8-L10** | Lessons-maxed | Maxing all 30 lessons puts you at L10 (24K USBI) | | **L11-L14** | Sink era | Lessons done, now spending on bridges and skins | | **L15-L19** | DEX regular | Active in BaiDEX, maybe spawning Agent Tokens | | **L20** | Voter unlocks | Can vote on Hive Worker parameters | | **L21-L29** | Power user | Heavy DEX participation, deep sinks | | **L30** | Genesis | Max USBI entitlement (101K), max mining rate | ```mermaid theme={null} flowchart LR L1[L1 · Start] --> L4[L2-L4
Early game] L4 -- L5: Bridge A unlocks --> L7[L5-L7
Bridge era] L7 -- L7: Bridge B unlocks --> L10[L8-L10
Lessons maxed
24K USBI] L10 --> L14[L11-L14
Sink era] L14 --> L19[L15-L19
DEX regular] L19 -- L20: Voting unlocks --> L29[L21-L29
Power user] L29 --> L30[L30 · Genesis
101K USBI · max rate] classDef start fill:#fce7f3,stroke:#db2777,color:#831843 classDef early fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef bridge fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a classDef mid fill:#dcfce7,stroke:#16a34a,color:#14532d classDef power fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef max fill:#fef2f2,stroke:#ef4444,color:#7f1d1d class L1 start class L4 early class L7 bridge class L10,L14,L19 mid class L29 power class L30 max ``` ## XP thresholds (compact) | Level | XP required | USBI entitlement (no welcome grant) | | ----: | ------------: | ----------------------------------: | | 1 | 0 | 0 | | 5 | 50,000,000 | 5,000 | | 10 | 230,000,000 | 23,000 | | 15 | 400,000,000 | 40,000 | | 20 | 600,000,000 | 60,000 | | 25 | 800,000,000 | 80,000 | | 30 | 1,000,000,000 | 100,000 | Full table: [Tokenomics → User Levels](/tokenomics/user-levels). ## Unlock matrix | Level | What unlocks | | ----- | --------------------------------------------------------------- | | 1 | Mining, claims, lessons, BaiDEX (no level gate to swap) | | 5 | **Bridge A** — convert CRS to on-chain USBI | | 7 | **Bridge B** — convert off-chain BINI to native BINI | | 10 | All-lessons-L10 milestone (cosmetic, plus the high mining rate) | | 20 | **Vote on Hive Workers** for the Agent Token you've spawned | | 30 | **Genesis status**, max entitlement | Other unlocks (skins tiers, lottery participation, franchise tiers) sit between these milestones — see [Franchise](/bini-app/franchise) for the franchise tier tree. ## Time-to-level scenarios How long to reach each milestone, no skin/lottery spend: | Cadence | All lessons L10 | Level 20 | Level 30 | | ------------------------------- | --------------: | --------: | -------: | | 2 claims/day | Day 109 | Day \~240 | Day 352 | | 3 claims/day | Day 91 | Day \~180 | Day 292 | | 2 claims + 100 active refs | Day 90 | Day \~205 | Day 316 | | 2 claims + 500 invited (capped) | Day 88 | Day \~190 | Day 297 | See [Tokenomics → Simulation](/tokenomics/simulation). ## Strategy by level range ### L1-L4: Get the loop going Claim every 4h. Buy first lesson. Don't spend on anything but lessons yet. ### L5-L7: Open the bridges Bridge A unlocks at L5 — use it, it counts as XP. Bridge B at L7 — use it sparingly until you have a target on BiniChain. ### L8-L10: Max the lessons This is the income-engine peak. After this, your CRS/hour stops growing. ### L11-L20: Strategic sinks Lessons-maxed = no more rate growth. CRS now goes to bridges, skins, lottery, Agent Token spawn. Each sink is XP — pick whichever fits your strategy. ### L20+: Vote and refine At L20 you can vote on Hive Workers — useful if you've spawned your own Agent Token. Otherwise just keep grinding sinks. ## Related 1 CRS spent = 1 XP earned Full 30-row XP/USBI table Unlocks at L5 Unlocks at L7 # Lottery Source: https://docs.binibit.com/bini-app/lottery BINI ticket lottery with 60/20/10/10 revenue split. Phase 2 of the Bini App rollout. The lottery launches in **Phase 2** of the Bini App rollout. This page documents the canonical mechanics. Live values (ticket price, draw frequency, jackpot rules) will be confirmed in the app at launch. ## What it is A ticketed BINI lottery integrated into the Bini App. Buy tickets in BINI, watch draws, win jackpots. The lottery is the **fourth permanent BINI sink** (sink #4 in the ecosystem) — 20% of every ticket purchase is permanently burned. ## Revenue split Every ticket purchased with BINI splits as follows: ``` Ticket price: ├── 60% Jackpot (winners) ├── 20% Burned permanently ├── 10% Referral commissions └── 10% Platform operations ``` | Slice | Where it goes | | ---------------- | ------------------------------------------------------------------------ | | **60% Jackpot** | Funds the prize pool. Eventually paid out to winners. | | **20% Burn** | Sent to a burn address. Permanently removes BINI from circulation. | | **10% Referral** | Paid to the referrer who introduced the ticket buyer (where applicable). | | **10% Platform** | Operating reserve and platform development costs. | ## Why these numbers * **60% to winners** is high enough to attract participation but leaves headroom for sinks * **20% burn** makes the lottery a meaningful contributor to deflationary pressure (vs zero in most lotteries) * **10% referral** pays the user-acquisition channel * **10% platform** funds ongoing operations ## Burn projections If the lottery sees \$V in daily ticket revenue: ``` Daily burn = V × 0.20 (in BINI) ``` | Daily ticket revenue | Daily BINI burn (at \$0.12 ref) | | -------------------: | ------------------------------: | | \$1,000 | 1,667 BINI | | \$10,000 | 16,667 BINI | | \$100,000 | 166,667 BINI | | \$1,000,000 | 1,666,667 BINI | At \$1M daily lottery revenue, the lottery alone burns \~600M BINI/year — comparable to the entire Year 1 emission. Realistic adoption is much lower in early phases. ## Draw mechanics (TBD) Final draw mechanics are being finalized: * **Frequency**: daily, weekly, both? * **Number of winners**: single jackpot, multiple tiers? * **Verifiability**: on-chain randomness (Chainlink VRF on BiniChain) or backend-RNG with public proof? * **Carryover**: rolls over if no winner? Draws will be on-chain and verifiable. Exact format announced before launch. ## Buying tickets After Phase 2 launch: 1. Open the Bini App → Lottery tab 2. View current pot, time to next draw, your tickets 3. Choose a number (or auto-pick) and quantity 4. Confirm — pay BINI at the current ticket price 5. Wait for the draw — winners notified in-app + on-chain Tickets cost **BINI native** (not CRS, not USBI). To play, you need on-chain BINI. For the cheapest path to BINI, use [Bridge B](/bini-app/bini-bridge) (off-chain BINI rewards → native, gated at L7). ## Eligibility * Open to any user with a Binibit Telegram account * Subject to local jurisdiction restrictions (lottery legality varies by country) ## Tokenomics impact Per [BINI Sinks](/tokenomics/bini-sinks), lottery is sink #4: * 20% of revenue is permanent burn * 60% jackpot eventually re-enters circulation as winnings (effectively a recycle) * 10% referral re-enters as referrer-controlled BINI * 10% platform stays in reserve, eventually deployed for ops Net effect on supply: -20% of every ticket. Combined with the [DEX swap burn](/baidex/overview) and [spawn fee burn](/agentt-launchpad/overview), this creates a structural deflationary force. ## Related Lottery is sink #4 (permanent burn) How to acquire on-chain BINI to play The asset paid into tickets Long-term supply trajectory # Onboarding & Welcome Grant Source: https://docs.binibit.com/bini-app/onboarding First-session experience: welcome grant, opening the app, first claim. ## Sign-up flow 1. Open the Binibit Telegram bot 2. Tap "Start" and authorize the mini-app 3. Receive your **welcome grant** (auto-credited) 4. Take a brief tour highlighting Claim, Lessons, and Bridges 5. Land on the home screen with mining already in progress The whole flow takes under a minute. No KYC. No external wallet connection. Telegram identity is the account identifier. ## Welcome grant The welcome grant value is being finalized between the team. Two values are in flight: * **1,000 USBI** (canonical economy v3.1) * **5 USBI + 0.1 BINI** (production simulation v3.0) The production rollout will use one of these. Check the in-app value at signup for the canonical answer for your account. The welcome grant exists so every new user has **non-zero capacity to participate** in the ecosystem from minute one. They can claim, swap on BaiDEX immediately at Level 1 (no gate to use the DEX), provide a small LP position, or just hold. ## What you can do at Level 1 (right after signup) * Claim CRS every 4 hours (mining is already running) * Use BaiDEX to swap (no level gate) * Read the 30 lessons to plan your upgrade path * View your USBI entitlement (currently 0 + welcome grant) * View your XP (currently 0) ## What's gated until later | Feature | Unlocks at | | ---------------------------- | ---------------------------------------- | | Bridge A (CRS → USBI) | Level 5 | | Bridge B (BINI off → native) | Level 7 | | Spawn Agent Tokens | Level depends on AgentT Launchpad config | | Vote on Hive Workers | Level 20 | See [Levels](/bini-app/levels) for the full unlock matrix. ## First-session tips 1. **Don't claim immediately on signup.** Mining starts but takes 4 hours to fill. Come back later for your first full claim. 2. **Read at least one lesson card.** Lessons are 30-second teachings — not just upgrade buttons. 3. **Pace your CRS spend.** Lesson L1 is cheap, lesson L10 is exponentially expensive. Spread upgrades across many lessons rather than maxing one. 4. **Set up referrals.** Your invite link is in the profile menu. Each referral that becomes active contributes to your CRS earnings. ## Related The 4-hour claim cycle The income engine Unlock matrix Welcome grant in the entitlement model # Bini App Overview Source: https://docs.binibit.com/bini-app/overview Telegram mini-app: mine, learn, level up, earn. Tokenomics → Ecosystem Overview is the central hub. Every formula on this page is documented there. ## What is Bini App Bini App is a **Telegram mini-app** that gamifies entry into the Binibit ecosystem. Users mine **Crystals (CRS)**, level up via **30 lessons**, and bridge into BaiDEX once they hit the right gates. It is the user-facing on-ramp to the entire ecosystem. ## Headline numbers | | | | ----------------------------- | ------------------------------------------ | | Levels | 30 (Seed → Genesis) | | Lessons | 30 lessons × 10 levels = 300 upgrades | | Mining | Continuous, claim every 4 hours | | Base mining rate | 10,000 CRS/hour | | Max mining rate (lessons L10) | 194,650 CRS/hour | | Welcome grant | See [Onboarding](/bini-app/onboarding) | | Bridges | A: CRS → USBI · B: BINI off-chain → native | ## How it works (the loop) ```mermaid theme={null} flowchart TB Start((Sign up)) --> Welcome[Welcome grant
credited] Welcome --> Mine[Background mining
10K CRS/hour + bonuses] Mine --> Claim[Claim every 4h] Mine --> Calendar[Daily calendar
30-day cycle] Claim --> Balance[CRS balance] Calendar --> Balance Balance --> Spend{Spend CRS} Spend -- lessons --> Lesson[Lesson upgrade
↑ CRS/hour rate] Spend -- Bridge A --> BridgeA[CRS → USBI
10,000:1] Spend -- sinks --> Sinks[Skins · lottery ·
spawn · boost] Lesson --> XP[XP +1 per CRS spent] BridgeA --> XP Sinks --> XP XP --> Entitlement[USBI entitlement
floor XP/10K] XP --> Level[User level
1 → 30] Entitlement --> DEX[Use USBI
on BaiDEX] Lesson -.- Mine classDef start fill:#fce7f3,stroke:#db2777,color:#831843 classDef earn fill:#dcfce7,stroke:#16a34a,color:#14532d classDef spend fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef result fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e class Start start class Welcome,Mine,Claim,Calendar,Balance earn class Spend,Lesson,BridgeA,Sinks spend class XP,Entitlement,Level,DEX result ``` ## The eight pages First-session experience and the starter USBI/BINI grant Upgrade cards that boost your mining rate Background CRS accrual and 4-hour claim cycle 30 tiers from Seed to Genesis Convert CRS to on-chain USBI at 10,000:1 (Level 5) Convert off-chain BINI to native at 1:1 (Level 7) 3-level CRS sharing on team mining Member → Builder → Manager → Director → Partner BINI sink, 60/20/10/10 split (Phase 2) ## Where to download The Bini App is a Telegram mini-app. Open Telegram and search for the official Binibit bot. Verified launch links will be published on [binibit.com](https://binibit.com/?i=7r2c8t). ## Related Full economic model Where USBI and wBINI provide liquidity Native ecosystem token # Referrals (3-level CRS) Source: https://docs.binibit.com/bini-app/referrals Earn CRS from your team's mining: 20% / 10% / 5% across three levels. The Bini App has a **3-level CRS referral** system documented here. It is **separate** from the [Binibit Exchange R0–R8 staking referrals](/bini-token/referral-levels), which work on staking rewards rather than CRS mining. Don't confuse the two — same brand, different mechanics, different reward currency. ## Headline | Level | Cut of team's base mining | | ------------------------------- | ------------------------: | | L1 (direct) | 20% | | L2 (their referrals) | 10% | | L3 (their referrals' referrals) | 5% | You earn CRS as your team mines. The percentages apply to **base mining only** (10K CRS/hour × 24h × user count, before lesson bonuses). ## How it works 1. You invite a user via your unique referral link (in Profile menu) 2. They sign up through your link → become your Level-1 referral 3. They mine CRS in their app → you earn 20% of their base mining as CRS 4. If they invite others → those become your Level-2 referrals (you earn 10%) 5. And so on for Level-3 Active referral rule: a referral counts toward your earnings only if they are **actively mining** (claiming regularly). ## Active referral rate Per the canonical economy model, **20% of invited users become active referrals**. * If you invite 100 people, expect \~20 active referrals * Active = claiming on the regular cadence The 80% inactive rate is built into the simulation — it's not a problem with the system, just realistic engagement loss. ## Daily cap To prevent sybil farming, the **maximum referral CRS** you can earn per day is: ``` Referral CRS/day cap = 500,000 CRS ``` This kicks in around **250 active referrals at 2 claims/day**. Beyond that, more referrals don't add CRS to your daily total (they still count for level/social purposes). ## Concrete examples How referrals accelerate your progression: | Active refs | Daily referral CRS | Days to all-lessons-L10 (vs solo 109) | | -------------------: | -----------------: | ------------------------------------: | | 0 (solo) | 0 | 109 | | 10 | 160,000 | 99 | | 20 | 320,000 | 90 | | 100 (capped at 500K) | 500,000 | 88 | | 250+ (capped) | 500,000 | 88 | Beyond \~100 active refs, the cap dampens further benefit. The system rewards quality of referrals up to a point, then plateaus. See [Tokenomics → Simulation](/tokenomics/simulation) for full projections. ## What you cannot earn from referrals Referrals only share **base mining**. They do **not** give you a cut of: * Their lesson-bonus mining * Their daily calendar rewards * Their bridge transactions * Their lottery winnings * Their staking rewards (those are R0-R8 — different system) This separation keeps the math simple and prevents abuse. ## Strategy * **Quality over quantity.** A few active refs > many inactive * **Help refs onboard.** Active rate is the multiplier. Helping 5 friends become regulars beats spam-inviting 100 * **Hit the cap.** Once you reach \~250 active refs (at 500K CRS/day), the system gives no marginal benefit on referral CRS * **Refer and stake separately.** Bini App referrals (here) don't impact Binibit Exchange referrals (R0-R8). They are independent systems ## Tokenomics impact Referral CRS comes from the Rewards pool emission, allocated to the Bini App's mining mechanic. The 500K/day cap × Total active referrers × 365 days bounds the maximum referral payout per year. The cap also prevents the worst-case "100K invited accounts farming forever" scenario. ## Related Where base mining comes from Day-to-L30 with vs without referrals Different progression: status tiers The other referral system (staking rewards) # USBI Bridge (Bridge A) Source: https://docs.binibit.com/bini-app/usbi-bridge Convert Crystals (CRS) to on-chain USBI at 10,000:1, unlocked at Level 5. See Tokenomics → USBI Bridge for the formula and entitlement interaction. ## What it does Bridge A converts off-chain Crystals (CRS) into on-chain USBI on BiniChain. ``` 10,000 CRS = 1 USBI ``` Fixed rate. No oracle, no slippage, no fee on the bridge itself. ## Unlock Bridge A unlocks at **Level 5** (50,000,000 cumulative XP). Below Level 5, you accumulate USBI entitlement but cannot bridge it on-chain. The gate exists to ensure users have engaged with the app before flowing into BaiDEX. ## How to use it 1. Open the Bini App 2. Navigate to Bridges → USBI Bridge (or similar — exact UI label may differ) 3. Enter the amount of CRS you want to bridge 4. Confirm — the app deducts CRS and mints USBI on your BiniChain address 5. View your USBI on [scan.binibit.com](https://scan.binibit.com) or in your wallet ## Daily limits * **No daily cap** on bridge amount — limited only by your USBI entitlement and your CRS balance * The bridge transaction itself executes on-chain → costs **gas in BINI** ## What you can do with bridged USBI | Use | How | | --------------------------- | ---------------------------------------------------------- | | Provide liquidity on BaiDEX | Wrap-and-deposit into wBINI/USBI or USBI/Agent Token pools | | Trade on BaiDEX | Swap USBI for wBINI, Agent Tokens, etc. | | Hold | Keep in your wallet — USBI is a sandbox stablecoin | | Send to other addresses | Standard ERC-20 transfer | ## Relationship with USBI entitlement The bridge does **not** create new entitlement. It draws against your existing entitlement, computed from XP: ``` usbi_entitlement = floor(total_xp / 10,000) welcome_grant = 1,000 (canonical) — value being finalized total_usbi_available = welcome_grant + usbi_entitlement claimable = total_usbi_available - already_bridged ``` But the **CRS you spend on the bridge counts as XP**, which raises your entitlement going forward. So bridging is partly self-funding from an entitlement perspective. ## Example walk-through 1. You have spent 50,000,000 CRS so far 2. XP = 50,000,000 → entitlement = 5,000 USBI (Level 5 unlocks here) 3. Total USBI available = 1,000 (welcome grant) + 5,000 = 6,000 USBI 4. You bridge 10,000,000 CRS = 1,000 USBI 5. Bridge consumes 1,000 of your 6,000 entitlement 6. The 10,000,000 CRS spent counts as XP → new total XP = 60,000,000 → new entitlement = 6,000 USBI 7. Total USBI available = 1,000 (grant) + 6,000 = 7,000 USBI; already bridged 1,000 → claimable 6,000 USBI ## Gas cost The bridge action is a BiniChain transaction — pay BINI for gas. If you don't have BINI native yet, you'll need to either: * Wait until you reach Level 7 and use Bridge B to acquire native BINI, or * Buy BINI on Binibit Exchange / Azbit / Blynex and bridge from Ethereum to BiniChain ## Limits The maximum lifetime USBI you can bridge equals your maximum entitlement at Level 30: ``` 1,000 (welcome grant) + 100,000 (entitlement at L30) = 101,000 USBI lifetime ``` This is independent of how much CRS you spend after Level 30 — XP caps at 1B, so entitlement caps at 100K USBI. ## Cross-product flow ```mermaid theme={null} flowchart LR Mine[Bini App
mine CRS] --> Spend[Spend CRS
on lessons / sinks] Spend --> XP[XP +1 per CRS] XP -- "÷ 10,000" --> Entitle[USBI entitlement] Welcome[Welcome grant
1,000 USBI] --> Entitle Mine -- "L5 reached" --> Bridge[Bridge A · this page
burn CRS, mint USBI] Entitle -- "headroom" --> Bridge Bridge --> OnChain[USBI on BiniChain] OnChain --> LP[BaiDEX LP
or trading] OnChain --> Hold[Hold in wallet] classDef app fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef calc fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef chain fill:#dcfce7,stroke:#16a34a,color:#14532d classDef use fill:#fce7f3,stroke:#db2777,color:#831843 class Mine,Spend,Welcome app class XP,Entitle calc class Bridge,OnChain chain class LP,Hold use ``` ## Related Formula and full entitlement model floor(XP / 10K), capped at 100K Bridge B: BINI off → native (L7) Where USBI provides liquidity Provide LP with bridged USBI All three bridges in the system # Allocation & Vesting Source: https://docs.binibit.com/bini-token/allocation 1B BINI split across 5 pools with explicit unlock schedules. See Tokenomics → BINI Emission for the full emission schedule and sink mechanics. ## Allocation summary | Pool | BINI | % of supply | Unlock | | --------------------- | ----------------: | ----------: | ------------------------- | | **Rewards** | 600,000,000 | 60% | 4-year monthly emission | | **Team & Founders** | 150,000,000 | 15% | 1 yr cliff + 3 yr linear | | **Marketing** | 100,000,000 | 10% | 5% TGE + milestone-based | | **Ecosystem Reserve** | 100,000,000 | 10% | 6 mo cliff + 48 mo linear | | **DEX Liquidity** | 50,000,000 | 5% | 100% TGE | | **Total** | **1,000,000,000** | **100%** | | ## Visual breakdown ### Allocation (1B total) ```mermaid theme={null} pie showData title BINI Allocation "Rewards" : 600 "Team & Founders" : 150 "Marketing" : 100 "Ecosystem Reserve" : 100 "DEX Liquidity" : 50 ``` ### Rewards emission (600M over 4 years) ```mermaid theme={null} pie showData title Rewards Emission by Year (millions) "Year 1" : 210 "Year 2" : 180 "Year 3" : 120 "Year 4" : 90 ``` ## Pool-by-pool details ### Rewards (60% / 600M) The largest pool, dedicated to user-facing incentives: * Bini App claims (mining, daily calendar, lessons) * Bridge B redemptions (off-chain BINI → native) * Agent Hive Worker incentives * Lottery jackpots * DEX LP incentives Released monthly per the [emission schedule](/bini-token/emission). After Year 4, the Rewards pool is fully drained — no more new BINI from this pool. ### Team & Founders (15% / 150M) ``` Cliff: 12 months from TGE (zero unlocked) Vesting: 36 months linear (4.17M BINI/month) End: Month 48 ``` Designed for long-term alignment. The team has zero ability to dump for the first year and a smooth release profile thereafter. ### Marketing (10% / 100M) ``` TGE: 5% unlocked at TGE (5,000,000 BINI) Milestones: 95M unlocks tied to listings, partnerships, growth KPIs ``` Marketing unlocks are **milestone-driven, not time-driven**. Each significant milestone (new exchange listing, key partnership, growth target) triggers a defined chunk of BINI to unlock. This keeps marketing budget tied to outcomes rather than calendar days, but does mean marketing emission is less predictable than time-vested pools. ### Ecosystem Reserve (10% / 100M) ``` Cliff: 6 months from TGE Vesting: 48 months linear End: Month 54 ``` A flexible pool for future grants, bounties, partnerships, and unforeseen ecosystem needs (e.g., supplementing DEX liquidity, funding audits, sponsoring builders). Allocated case-by-case by the team with on-chain transparency. ### DEX Liquidity (5% / 50M) ``` TGE: 100% unlocked ``` Used as the **wBINI side of initial BaiDEX pools** — primarily the wBINI/USBI anchor pool. Available immediately at TGE so the DEX has working liquidity from day one. The 50M cap × $0.12 reference price = **$6,000,000 wBINI side value\*\*, which combined with the matched USBI side creates a \$12M pool TVL ceiling. See [wBINI Cap Rule](/tokenomics/wbini-cap). ## Total cumulative supply over time | Month | Cumulative unlocked | | | ------: | -------------------------------------------------------------: | ------------- | | 0 (TGE) | DEX 50M + Marketing 5M + first Rewards = \~73M | | | 6 | + 6 mo Rewards + Ecosystem cliff ends, Marketing milestones | varies | | 12 | + 12 mo Rewards + Team cliff ends, Marketing milestones | varies | | 48 | All time-vested pools fully unlocked, Year 4 emission complete | varies (high) | | 54 | Ecosystem Reserve fully unlocked | varies (high) | Total max cumulative supply caps at 1,000,000,000 BINI by month 54 (assuming all Marketing milestones are met). ## Anti-dump considerations * **Team has 1 year cliff**: zero team-side selling for 12 months * **Ecosystem has 6 month cliff**: no flood of grant-related selling early * **Rewards taper**: Year 1 is the highest emission; Year 4 is half. Sell pressure decreases over time * **Marketing tied to milestones**: cannot front-load if no milestones hit ## Related The 4-year monthly Rewards release Where BINI flows after unlock Full economic context 50M DEX cap → \$240M implied MC ceiling # Asset Comparison Source: https://docs.binibit.com/bini-token/asset-comparison BINI vs wBINI vs USBI vs CRS — what each is and when to use which. Tokenomics → Asset Model has the full breakdown of all four assets and their conversions. ## At a glance | | **BINI** | **wBINI** | **USBI** | **CRS** | | --------------------- | -------------------------------------------- | ------------------- | --------------------------- | -------------------- | | **Type** | Native chain token | ERC-20 wrap | ERC-20 stablecoin (sandbox) | Off-chain points | | **Real value?** | Yes (\$0.12 ref) | Yes (1:1 BINI) | Sandbox (\$1 sim unit) | No (virtual) | | **Total supply** | 1B fixed | Backed by BINI | Bounded by user XP | Unbounded | | **Where it lives** | BiniChain native | BiniChain ERC-20 | BiniChain ERC-20 | Bini App database | | **External listings** | CEX (3 venues) | None | None | None | | **Used as gas** | Yes | No | No | No | | **Used in BaiDEX** | Wrap to wBINI first | Yes | Yes | No | | **Used in Bini App** | Bridge B reward | No | Bridge A target | Mining + sinks | | **Earned by users** | Bridge B from off-chain | Wrap from BINI | Bridge A from CRS | Mining, claims, refs | | **Convertible?** | wBINI ↔ BINI 1:1 · Bridge B ↔ off-chain BINI | wBINI → BINI unwrap | None (sandbox) | → USBI 10,000:1 | ## When to hold each ### BINI You want BINI when: * Staking on Binibit Exchange (160% APR) * Paying gas on BiniChain * Buying lottery tickets in Bini App (Phase 2) * Spawning Agent Tokens on AgentT Launchpad * Holding for long-term ecosystem appreciation ### wBINI You want wBINI when: * Providing liquidity on BaiDEX * Trading via BaiDEX swaps * Participating in wBINI/USBI or wBINI/Agent Token pools Wrap from BINI 1:1, unwrap back any time. ### USBI You want USBI when: * Providing liquidity on BaiDEX (USBI side) * Trading on USBI/Agent Token pools * Earning yield from sandbox-economy LP USBI is **bounded by your XP entitlement** in the Bini App. You cannot acquire USBI outside the entitlement system. ### CRS You earn CRS by playing the Bini App. CRS is what you spend on: * Lesson upgrades (income engine) * Bridge A → USBI (DEX entry) * Skins, lottery (CRS-priced versions), boosts CRS does not leave the Bini App database — fully off-chain. ## Conversion paths ```mermaid theme={null} flowchart TB CRS["CRS
(off-chain points)"] USBI["USBI
(ERC-20)"] BINIoff["BINI off-chain
(quest rewards)"] BINInative["BINI
(BiniChain native)"] wBINI["wBINI
(ERC-20 wrap)"] Pools["BaiDEX pools"] CRS -- "Bridge A · 10,000:1" --> USBI BINIoff -- "Bridge B · 1:1" --> BINInative BINInative -- "wrap · 1:1" --> wBINI USBI --> Pools wBINI --> Pools classDef offchain fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef onchain fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef pool fill:#dcfce7,stroke:#16a34a,color:#14532d class CRS,BINIoff offchain class USBI,BINInative,wBINI onchain class Pools pool ``` ## Sandbox vs Mainnet | Phase | BINI | wBINI | USBI | CRS | | ----------- | ---- | ----- | ---------------------- | ------------------------ | | **Sandbox** | Real | Real | Sandbox \$ | Virtual | | **Mainnet** | Real | Real | Replaced or stabilized | Virtual (off-chain only) | The sandbox→mainnet transition primarily affects USBI, which today is a bounded-supply sandbox stablecoin and may evolve into something different at mainnet (audited stablecoin, replaced asset, etc.). The exact transition is on the [roadmap](/changelog). ## Which to learn first Pick by goal: | Goal | Start with | | ------------------------------- | ------------------------------------------------- | | I want to invest in the token | [BINI](/bini-token/overview) | | I want to provide DEX liquidity | [wBINI](/baidex/overview) (wrap BINI) | | I want to play the app | [CRS](/bini-app/overview) | | I want to use the DEX | [USBI](/tokenomics/usbi-bridge) (bridge from CRS) | ## Related Full Tokenomics breakdown CRS → USBI Off-chain BINI → native BINI Where wBINI and USBI provide liquidity # Contract Addresses Source: https://docs.binibit.com/bini-token/contracts BINI V2 on Ethereum (ERC-20), legacy BINI V1, and BiniChain native references. Binibit is migrating BINI from the legacy V1 contract to BINI V2 on Ethereum. The holder migration is coordinated through the Binibit platform. Treat the V2 contract below as the canonical Ethereum ERC-20 contract and the V1 contract as a legacy reference. ## Live contract ### Ethereum ERC-20 (current BINI V2) ``` Address: 0x5a76a2830859c321a50937a22fde571fbf4810f3 Network: Ethereum mainnet (chainId 1) Standard: ERC-20 Decimals: 18 Symbol: BINI ``` | Resource | Link | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Etherscan | [etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3](https://etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3) | | Holder list | [etherscan.io holders page](https://etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3#balances) | | CoinMarketCap | [coinmarketcap.com/currencies/binibit](https://coinmarketcap.com/currencies/binibit/) | | CoinGecko | [coingecko.com/en/coins/binibit](https://www.coingecko.com/en/coins/binibit) | ## Legacy contract ### Ethereum ERC-20 (legacy BINI V1) ``` Address: 0x445d03F499f1C150615957bb87588fb465FC91cC Network: Ethereum mainnet (chainId 1) Standard: ERC-20 Decimals: 18 Symbol: BINI Status: Legacy contract ``` | Resource | Link | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Etherscan | [etherscan.io/token/0x445d03F499f1C150615957bb87588fb465FC91cC](https://etherscan.io/token/0x445d03F499f1C150615957bb87588fb465FC91cC) | | Historical holder list | [etherscan.io holders page](https://etherscan.io/token/0x445d03F499f1C150615957bb87588fb465FC91cC#balances) | V1 remains listed here for historical verification and migration reconciliation. It is not the current canonical Ethereum BINI contract. ## Migration notice Binibit is migrating BINI from V1 to V2 on Ethereum. BINI V2 introduces a safer governance architecture, fixed supply, multisig Safe custody, and transparent token distribution across dedicated pools according to the public tokenomics and whitepaper. The Binibit team has updated the contract and explorer information in its CoinMarketCap Self-Reporting Dashboard. CoinMarketCap should verify the new V2 contract, mark V1 as the legacy contract, and display a migration notice on the BINI page. During the review period, aggregator pages may still display legacy V1 contract data. See [BINI migration](/bini-token/migration) for the current holder notice. ### BiniChain (native, mainnet) ``` Type: Native chain token (not ERC-20) Network: BiniChain mainnet RPC: https://rpc.binibit.com Explorer: https://scan.binibit.com Symbol: BINI Use: Native gas + ecosystem fees ``` The BiniChain mainnet rollout for native BINI is in the [roadmap](/changelog). ## wBINI (wrapped BINI on BaiDEX) ``` Type: ERC-20 wrap of BINI Network: BiniChain Standard: ERC-20 (with deposit/withdraw to wrap/unwrap) Backing: 1 wBINI = 1 BINI native Use: BaiDEX pool LP ``` wBINI lets BINI participate as one side of a Uniswap V3-style pool. Wrap and unwrap via the BaiDEX UI or directly via the wBINI contract. Address: see [BaiDEX → Contract Addresses](/baidex/overview) (publishes with PR-5). ## How to verify a BINI address 1. Search the contract address on a block explorer (Etherscan for Ethereum) 2. Confirm token name = "Binibit" and symbol = "BINI" 3. Confirm the contract is **verified** (source code published) 4. Cross-check the address on at least one aggregator page (CoinGecko, CryptoRank, etc.) If you encounter an address that **claims to be current Ethereum BINI but does not match** the canonical V2 address above, it is **not** the current official token. Report scams to [support@binibit.com](mailto:support@binibit.com). ## Cross-chain mechanism The link between Ethereum ERC-20 BINI and BiniChain native BINI is the **bridge** — see [BiniChain → Bridges](/binichain/overview) when published. The bridge maintains the **1:1 peg** between the two representations. Total supply across both chains never exceeds 1,000,000,000 BINI. ## Governance and upgrades The BINI V2 control plane uses dedicated roles and multisig Safe custody for production operations. The BiniChain native protocol is upgradable through validator governance, but the BINI supply rules and emission schedule are constants enforced at the protocol level. Major token or protocol changes will be: * Pre-announced 30 days in advance * Validated by an audit before deployment * Logged on-chain ## Related Listed CEX venues Where native BINI lives Where wBINI is used 1B fixed supply # Emission Schedule Source: https://docs.binibit.com/bini-token/emission The 4-year monthly release of the 600M Rewards pool, then zero. The full Tokenomics page covers emission alongside sinks and supply trajectory. ## The schedule The Rewards pool (600M BINI) releases over **48 months** in declining monthly amounts. After Year 4, no more emission — the supply is fully diluted. | Year | Monthly emission | Annual emission | Cumulative emission | | ---- | ---------------: | --------------: | ------------------: | | 1 | 17,500,000 | 210,000,000 | 210M | | 2 | 15,000,000 | 180,000,000 | 390M | | 3 | 10,000,000 | 120,000,000 | 510M | | 4 | 7,500,000 | 90,000,000 | 600M | | 5+ | 0 | 0 | 600M (final) | ```mermaid theme={null} xychart-beta title "BINI Rewards Emission (millions per year)" x-axis [Y1, Y2, Y3, Y4, "Y5+"] y-axis "Emission (M BINI)" 0 --> 250 bar [210, 180, 120, 90, 0] ``` ## Year-over-year inflation impact Inflation here is measured **against the Rewards pool only** (60% of total supply). Inflation against the full 1B supply is roughly proportional but offset by Marketing milestones and Ecosystem Reserve unlocks. | Year | Year-end Rewards-only % unlock | Effective annual emission rate | | ------- | -----------------------------: | -----------------------------: | | Year 1 | 35% (210M / 600M) | High | | Year 2 | 65% (390M / 600M) | Moderate | | Year 3 | 85% (510M / 600M) | Low | | Year 4 | 100% (600M / 600M) | Very low | | Year 5+ | 100% | **Zero** | ## Why the front-loaded curve Year 1 is the highest emission for two reasons: 1. **User acquisition** — early adopters need stronger incentives to join an unproven ecosystem 2. **DEX liquidity bootstrapping** — early LPs need higher rewards to seed thin pools The taper means later users get lower headline yields but join a larger, more liquid ecosystem. ## Where the Rewards pool flows (per-month policy) The exact split between bini-app rewards / Bridge B / Agent Hive incentives / Lottery / LP incentives is set per month and logged on-chain. A representative split (illustrative, not canonical): ``` Month X: ├── 60% Bini App claims + daily calendar ├── 15% Bridge B redemptions ├── 10% Agent Hive Worker incentives ├── 10% DEX LP incentives (wBINI side seeding) └── 5% Lottery jackpots ``` The actual split for any given month is announced ahead of time and verifiable on-chain. ## After Year 4 — supply dynamics ``` Year 5+: ├── Emission: 0 BINI ├── Burns: Continuous (DEX swaps, lottery, spawn fees) ├── Net trajectory: Monotonically decreasing ``` Once emission stops, BINI becomes a **fixed-supply asset with continuous deflationary pressure** from the [eight sinks](/tokenomics/bini-sinks). Three of those sinks (DEX swap burn, lottery burn, spawn fee burn) are permanent — every burn shrinks total supply forever. ## Emission and price model The price impact of emission depends on: 1. How much of monthly emission lands in active wallets vs locked positions (staking, LP) 2. How much circulates onto exchanges vs is held long-term 3. How much is offset by burns from the same month's activity A sustainable model would have **monthly burns ≥ monthly emission** by some point in years 3-4, after which net supply starts decreasing. ## Emission events on-chain Each monthly emission is a single transaction batch on BiniChain. The transaction is: * Pre-announced 7 days in advance * Executed on the first day of each month (or scheduled equivalent) * Logged with the per-pool split for that month * Available via [scan.binibit.com](https://scan.binibit.com) ## Related Full pool breakdown Where BINI flows back out (8 sinks) Staking rewards come from the Rewards pool Long-term supply trajectory # BINI V2 Migration Source: https://docs.binibit.com/bini-token/migration Notice for the migration from legacy BINI V1 to the new BINI V2 Ethereum contract. Binibit is migrating BINI from the legacy V1 contract to BINI V2 on Ethereum. The holder migration is coordinated through the Binibit platform. ## Migration summary Binibit is moving BINI from the legacy V1 ERC-20 contract to a new BINI V2 contract on Ethereum. | Contract | Status | Address | | -------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | BINI V2 | Current Ethereum ERC-20 contract | [`0x5a76a2830859c321a50937a22fde571fbf4810f3`](https://etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3) | | BINI V1 | Legacy Ethereum ERC-20 contract | [`0x445d03F499f1C150615957bb87588fb465FC91cC`](https://etherscan.io/token/0x445d03F499f1C150615957bb87588fb465FC91cC) | ## What changes in BINI V2 BINI V2 introduces: * A safer governance architecture * Fixed supply * Multisig Safe custody * Transparent token distribution across dedicated pools * Alignment with the public tokenomics and whitepaper ## Holder migration The holder migration is coordinated through the Binibit platform. Use official Binibit channels and the published contract addresses above when checking balances, deposits, withdrawals, or aggregator data. Do not treat the V1 contract as the current Ethereum BINI token. V1 remains visible for historical balances, explorer references, and migration reconciliation. ## Aggregator notice The Binibit team has updated the contract and explorer information in its CoinMarketCap Self-Reporting Dashboard. CoinMarketCap should verify the new V2 contract, mark V1 as the legacy contract, and add a migration notice to the [BINI page](https://coinmarketcap.com/currencies/binibit/). During the review period, aggregator pages may still display legacy V1 contract data. ## Related Current V2 and legacy V1 Ethereum contracts Public BINI tokenomics and distribution pools # BINI Token Overview Source: https://docs.binibit.com/bini-token/overview Native ecosystem token: gas, staking, sinks, rewards. 1B fixed supply. Tokenomics → Ecosystem Overview is the central hub for how BINI fits into the wider system. BINI is migrating from the legacy V1 Ethereum contract to BINI V2. The current Ethereum ERC-20 contract is `0x5a76a2830859c321a50937a22fde571fbf4810f3`. See [BINI V2 Migration](/bini-token/migration). ## What is BINI BINI is the native token of the Binibit ecosystem. It is: * **Gas** on BiniChain (every transaction pays BINI) * **Trading reference** on Binibit Exchange (BINI/USDT pair) * **Staking asset** on Binibit Exchange (160% APR, R0-R8 referrals) * **Fee currency** for Agent Token spawn, lottery tickets, DEX referrer rewards * **LP asset** as wBINI on BaiDEX ## Key facts | | | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Total supply | **1,000,000,000 BINI** (fixed, no mint after genesis) | | Reference price | \$0.12 | | Allocation | 60% Rewards / 15% Team / 10% Marketing / 10% Ecosystem / 5% DEX Liquidity | | Emission | 4-year monthly from Rewards pool, then zero | | Token contract (Ethereum ERC-20, BINI V2) | [`0x5a76a2830859c321a50937a22fde571fbf4810f3`](https://etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3) | | Legacy contract (Ethereum ERC-20, BINI V1) | [`0x445d03F499f1C150615957bb87588fb465FC91cC`](https://etherscan.io/token/0x445d03F499f1C150615957bb87588fb465FC91cC) | | Native on BiniChain | Mainnet rollout | ## Where to buy | Venue | Pair | Link | | ---------------- | --------- | ------------------------------------------------------------ | | Binibit Exchange | BINI/USDT | [exchange](https://binibit.com/en/exchange?symbol=BINI_USDT) | | Azbit | BINI/USDT | [azbit.com](https://azbit.com/exchange/BINI_USDT) | | Blynex | BINI/USDT | [blynex.com](https://blynex.com/spot/BINI_USDT) | Aggregator listings: * [CoinMarketCap](https://coinmarketcap.com/currencies/binibit/) * [CoinGecko](https://www.coingecko.com/en/coins/binibit) * [CryptoRank](https://cryptorank.io/price/binibit-token) * [Arkham Intel](https://intel.arkm.com/explorer/token/binibit) * [DropStab](https://dropstab.com/coins/binibit) * [Etherscan](https://etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3) ## Inside the docs 1B fixed supply across 5 pools with cliff and linear vesting 4-year monthly Rewards pool release: 17.5M → 7.5M → zero Eight BINI sinks across the ecosystem 160% APR, four duration tiers Nine-level commission system Listed venues Current V2 contract and legacy V1 reference Ethereum ERC-20 + future BiniChain native BINI vs wBINI vs USBI vs CRS # Referral Levels (R0–R8) Source: https://docs.binibit.com/bini-token/referral-levels Nine-level referral commission system on staking rewards. This page describes mechanics. Live values (thresholds, percentages) are on the staking conditions page. ## The nine levels Stakers automatically participate in a 9-level referral system, **R0 through R8**. Each level has thresholds for: * Self-stake (in USDT-equivalent) * Number of qualifying direct referrals * Cumulative team volume | Level | Tier description | | ----- | ----------------------------- | | R0 | Entry tier (any active stake) | | R1 | Active builder | | R2 | Active builder | | R3 | Mid-tier | | R4 | Mid-tier | | R5 | Senior | | R6 | Senior | | R7 | Top tier | | R8 | Maximum tier | ```mermaid theme={null} flowchart TB R0["R0 · Entry
Any active stake"] R1["R1 · Active builder"] R2["R2 · Active builder"] R3["R3 · Mid-tier"] R4["R4 · Mid-tier"] R5["R5 · Senior"] R6["R6 · Senior"] R7["R7 · Top tier"] R8["R8 · Maximum
Highest commission"] R0 -- "self-stake +
refs +
team volume" --> R1 R1 --> R2 R2 --> R3 R3 --> R4 R4 --> R5 R5 --> R6 R6 --> R7 R7 --> R8 classDef entry fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef builder fill:#dcfce7,stroke:#16a34a,color:#14532d classDef mid fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef senior fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a classDef top fill:#fce7f3,stroke:#db2777,color:#831843 classDef max fill:#fef2f2,stroke:#ef4444,color:#7f1d1d class R0 entry class R1,R2 builder class R3,R4 mid class R5,R6 senior class R7 top class R8 max ``` Specific thresholds and percentages: see [staking conditions](https://binibit.com/en/staking). Live values may change with BINI price (see [Dynamic threshold](#dynamic-threshold) below). ## How commission works When a downline (a user in your referral team, direct or indirect) earns staking rewards, you receive a **commission** based on the level difference between you and them. ``` If downline level >= your level: base commission rate If downline level < your level: higher commission per level gap ``` This rewards being one or more tiers above your team. Unlike flat referral systems, the level-difference design encourages you to keep growing — your team's rewards multiply for you only as long as you stay ahead. ### Example (illustrative) ``` You are R5. A user in your downline is R3. Difference: 2 levels. Commission on their staking rewards: base + 2 × per-level-bonus ``` (Exact percentages on the canonical conditions page.) ## Same-level commission If your downline reaches your level or higher, the commission falls to a **flat 15%** (or the published base rate). This is the floor — even if your downline outranks you, you still earn from their stakes, just at a lower rate. ## Dynamic threshold Level thresholds are denominated in **USDT**, not BINI. As BINI price moves, the BINI required to maintain a given level moves inversely: ``` required_bini = required_usdt / current_bini_price ``` | BINI price | BINI required for hypothetical R5 (e.g. \$5,000 USDT) | | ------------------ | ----------------------------------------------------: | | \$0.10 | 50,000 BINI | | \$0.12 (reference) | 41,667 BINI | | \$0.20 | 25,000 BINI | | \$0.50 | 10,000 BINI | If BINI rises, you need less BINI to maintain your level. If BINI falls, you need more (or risk dropping a tier). This protects the level system against price volatility — your level reflects USD-equivalent commitment, not raw BINI quantity. ## Maintaining your level Your level is checked **at stake initiation** and on **periodic rebalancing**: * If your self-stake (in USDT-equivalent) drops below your level's threshold, you fall a level * If your team volume drops below your level's threshold, you fall a level * New stakes or team additions can raise your level Specific check intervals are on the staking conditions page. ## Combined with R0-R8 — examples The combination of self-stake and team volume creates a **diagonal progression**: ``` You can reach R5 by: - Higher self-stake + smaller team OR - Smaller self-stake + larger team Both paths viable. ``` This makes the system accessible to both **whales** (large self-stake) and **community builders** (large team). ## Tokenomics impact The R0-R8 system is what makes **staking compounding for the protocol**: * Stakers lock BINI (sink #2) * Stakers acquire team to earn more → users referred deposit more BINI → more locks * Higher levels = larger team = more aggregate locked BINI per refer-er * The system has a natural cap (R8) so it cannot run away See [Tokenomics: Staking & Referral Economics](/tokenomics/staking). ## Risk considerations * **Multi-level marketing structure**: legality varies by jurisdiction. Verify you can participate in your country before signing up. * **Downline volatility**: if your team unstakes en-masse, your commissions drop and you may lose your level * **Threshold volatility**: USDT-pegged thresholds protect against BINI price moves but don't protect against USDT depegging (rare but not zero) ## Related 160% APR packages — what referrers earn from Full economic context Need BINI first to stake Canonical thresholds and percentages # Staking Source: https://docs.binibit.com/bini-token/staking 160% APR on Binibit Exchange across four duration tiers. See Tokenomics → Staking & Referral Economics for tokenomics-level analysis. ## Quick links * [Staking page](https://binibit.com/en/staking) on Binibit Exchange (canonical, has live values) * [Staking conditions / referral levels](https://binibit.com/en/staking) * [BINI/USDT trading pair](https://binibit.com/en/exchange?symbol=BINI_USDT) for buying BINI to stake ## Staking packages Four lock duration tiers, **160% APR** on each: | Tier | Lock duration | APR | Bonus / Spot split | | ------ | ------------- | ---: | ----------------------- | | Tier 1 | 30 days | 160% | More Bonus, less Spot | | Tier 2 | 90 days | 160% | Balanced | | Tier 3 | 180 days | 160% | More Spot, less Bonus | | Tier 4 | 360 days | 160% | Maximum Spot proportion | The 160% APR is **base rate**. Longer locks return a higher proportion of **Spot BINI** (immediately tradable) versus **Bonus BINI** (subject to additional vesting / conditions). Daily accrual. Withdrawal at maturity. ## Bonus vs Spot BINI | | Spot BINI | Bonus BINI | | ------------------------------- | --------- | ------------------------- | | Tradable immediately on receipt | Yes | No (vesting / conditions) | | Counts toward referral level | Yes | Yes | | Sell pressure on receipt | Yes | Lower | Longer locks → more Spot BINI → user has higher freedom but also higher immediate sell pressure. Shorter locks → more Bonus BINI → less freedom, but better for token-price stability. ## Compounding Once a stake matures, the user can immediately re-stake the principal plus rewards. Continuous re-staking compounds at the 160% APR, multiplied by the reinvestment cadence. ## Minimum stake Each tier has a minimum BINI amount. Specific values are on the [staking page](https://binibit.com/en/staking) — they may change with BINI price, since the underlying threshold is in **USDT terms**. ``` required_bini_minimum = required_usdt_minimum / current_bini_price ``` ## How it ties into referrals Staking is what unlocks the **R0 through R8** referral system on Binibit Exchange. Your level is determined by: * Your own staked BINI (USDT-equivalent) * Number of qualifying direct referrals * Cumulative team volume Higher levels unlock larger commission rates on team staking rewards. See [Referral levels](/bini-token/referral-levels). ## Tokenomics impact Staking is **sink #2** in the BINI sink list — locked BINI is unavailable for spot trading until the lock matures. This: * Reduces effective float during the lock * Stabilizes price by removing tradable supply * Generates compounding ecosystem engagement (stake-then-refer) See [BINI Sinks](/tokenomics/bini-sinks). ## Risk considerations Standard staking risks apply: * **Smart contract risk** — staking contract is audited but cannot be guaranteed bug-free * **Lock-up risk** — funds are illiquid for the duration * **APR change risk** — the 160% rate is honored for stakes initiated under it, but future stakes may use different rates * **Token price risk** — APR is in BINI terms; BINI USD value can fluctuate Stake only what you can afford to lock for the duration. ## Where to stake [Binibit Exchange — Staking](https://binibit.com/en/staking) Read the staking conditions page carefully before staking. It is the canonical source for current values. ## Related R0 through R8 To stake, you need BINI first Tokenomics-level view Staking is sink #2 # Utility & Sinks Source: https://docs.binibit.com/bini-token/utility Where BINI is used and where it flows back out (8 mechanisms). The full Tokenomics → BINI Sinks page covers the deflationary mechanics in depth. ## Eight mechanisms | # | Mechanism | What BINI does | Type | | - | ------------------- | -------------------------------------------------------------- | ------------------------------- | | 1 | **Gas** | Pays for every BiniChain transaction | Sink (partial burn / validator) | | 2 | **Staking** | Locked on Binibit Exchange for 30/90/180/360 days at 160% APR | Lock | | 3 | **DEX trade burn** | 0.25% of every BaiDEX swap is burned | **Permanent burn** | | 4 | **Lottery burn** | 20% of every BINI lottery ticket is burned | **Permanent burn** | | 5 | **Spawn fee** | Agent Token spawn cost is paid in BINI and burned | **Permanent burn** | | 6 | **Premium / boost** | Token visibility boosts on AgentT Launchpad consume BINI | Sink (partial burn) | | 7 | **Bridge gas** | Bridges A and B consume BINI for transaction execution | Sink | | 8 | **LP locking** | wBINI side of BaiDEX pools is locked while LP position is open | Lock | ```mermaid theme={null} flowchart LR BINI((BINI
1B fixed)) subgraph Permanent["Permanent burns"] DEX[DEX trade burn
0.25% per swap] Lottery[Lottery burn
20% per ticket] Spawn[Spawn fee
100% per Agent Token] end subgraph Locked["Locks · out of float"] Staking[Staking
30/90/180/360 days] LP[LP locking
wBINI in V3 pools] end subgraph Variable["Partial · variable"] Gas[Gas
per BiniChain tx] Boost[Boost / promotion
Launchpad visibility] BridgeGas[Bridge gas
Bridges A and B] end BINI --> DEX BINI --> Lottery BINI --> Spawn BINI --> Staking BINI --> LP BINI --> Gas BINI --> Boost BINI --> BridgeGas classDef burn fill:#fef2f2,stroke:#ef4444,color:#7f1d1d classDef lock fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef other fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef token fill:#dcfce7,stroke:#16a34a,color:#14532d class DEX,Lottery,Spawn burn class Staking,LP lock class Gas,Boost,BridgeGas other class BINI token ``` ## Permanent burns (sinks 3, 4, 5) These three sinks send BINI to a burn address with no recovery path: ``` DEX swap: 0.25% × swap volume (permanent) Lottery: 20% × ticket revenue (permanent) Spawn: 100% × spawn cost per AT (permanent) ``` The combination scales with **DEX volume**, **lottery activity**, and **Launchpad adoption** respectively. Each independently creates deflationary pressure. ## Locks (sinks 2, 8) These reduce **effective float** — BINI exists but cannot trade for the duration: | Lock type | Duration | Returns when | | ------------- | ------------------------ | --------------------------------------------------------------------- | | Staking | 30 / 90 / 180 / 360 days | Stake matures or user unstakes (if early withdraw allowed at penalty) | | LP wBINI side | Indefinite | LP position is closed | Locked BINI doesn't reduce total supply, but it reduces sell pressure during the lock. ## Gas (sink 1) Every BiniChain transaction pays gas in BINI. Depending on chain configuration: * **Burned** — gas is permanently removed from circulation (Ethereum-style EIP-1559) * **Paid to validators** — gas goes to validators as block reward * **Hybrid** — some burned, some to validators The exact split is documented in the [BiniChain](/binichain/overview) reference. ## Bridge gas (sink 7) Bridges A and B execute on BiniChain — they consume BINI gas. This is the same mechanism as #1 but worth calling out: **Bridge B** (off-chain BINI → native) consumes BINI, so bridging is itself slightly self-funding from a sink perspective. ## DEX volume → burn projection At a constant DEX volume of \$V/day with 1% total fee, 0.25% burned: ``` Daily burn (in $) = V × 0.0025 Daily burn (in BINI at $0.12) = V × 0.0025 / $0.12 ``` | Daily volume | Daily burn (\$) | Daily burn (BINI) | | -----------: | --------------: | ----------------: | | \$100K | \$250 | 2,083 | | \$1M | \$2,500 | 20,833 | | \$10M | \$25,000 | 208,333 | | \$100M | \$250,000 | 2,083,333 | At \$10M daily volume, the DEX burn alone removes \~76M BINI/year — comparable to Year 4's monthly emission rate. ## Spawn cost → burn projection If 100 Agent Tokens spawn per day at a hypothetical 100 BINI/spawn: ``` Daily Spawn burn = 100 × 100 = 10,000 BINI/day = ~3.65M BINI/year ``` The exact spawn cost is being finalized. ## Lottery burn projection Lottery launches in Phase 2 of the Bini App rollout. Once active, 20% of every BINI ticket is burned. Numbers depend on ticket pricing and frequency — not yet finalized. ## Net long-term effect ``` Combined permanent burns: DEX trade burn + ~76M / year (at $10M daily volume) + Lottery burn + TBD + Spawn fee burn + ~3.65M / year (at 100/day, 100 BINI/spawn) ───────────────────────────────────────────────────────── Total permanent burn ≈ 80M+ / year (with healthy adoption) vs Year 4 emission: 90M / year vs Year 5+ emission: 0 ``` Once adoption hits the targeted volume levels, **annual burns approach annual emission** in years 3-4 and **exceed emission** in years 5+. This is when BINI becomes net deflationary. ## Related Full mechanism details The supply side Source of sink #3 (DEX trade burn) Source of sink #5 (Spawn fee) # Where to Buy Source: https://docs.binibit.com/bini-token/where-to-buy Listed venues for BINI/USDT and related pairs. ## Live listings | Venue | Pair | Type | Link | | -------------------- | --------- | ---- | ------------------------------------------------------------ | | **Binibit Exchange** | BINI/USDT | CEX | [exchange](https://binibit.com/en/exchange?symbol=BINI_USDT) | | Azbit | BINI/USDT | CEX | [azbit.com](https://azbit.com/exchange/BINI_USDT) | | Blynex | BINI/USDT | CEX | [blynex.com](https://blynex.com/spot/BINI_USDT) | ## Aggregator pages Track BINI metrics on: * [CoinMarketCap](https://coinmarketcap.com/currencies/binibit/) * [CoinGecko — Binibit](https://www.coingecko.com/en/coins/binibit) * [CryptoRank](https://cryptorank.io/price/binibit-token) * [Arkham Intel](https://intel.arkm.com/explorer/token/binibit) * [DropStab](https://dropstab.com/coins/binibit) * [Etherscan (BINI V2 ERC-20)](https://etherscan.io/token/0x5a76a2830859c321a50937a22fde571fbf4810f3) BINI is migrating from the legacy V1 Ethereum contract to BINI V2. See [BINI V2 Migration](/bini-token/migration) before checking on-chain balances or aggregator contract data. ## After buying Once you hold BINI, you can: * **Stake on Binibit Exchange** — 160% APR, 4 duration tiers ([Staking](/bini-token/staking)) * **Hold for ecosystem use** — gas, lottery tickets, Agent Token spawn fees * **Provide liquidity on BaiDEX** — wrap to wBINI, deposit alongside USBI ([BaiDEX](/baidex/overview)) * **Refer others** — qualify for R0-R8 commissions on your team's stakes ## Listing announcements & coverage * [Azbit listing announcement (Telegram)](https://t.me/azbit_news/3087) ## Aggregator status Current aggregator status: * **CoinMarketCap** — Listed; BINI V2 contract and explorer data submitted through the Self-Reporting Dashboard * **CoinGecko** — Listed (request `CU2004260013`) For listing on additional CEX or DEX venues, contact Binibit business development through [binibit.com](https://binibit.com/?i=7r2c8t). ## Buying as a non-CEX user If you do not have a Binibit Exchange / Azbit / Blynex account: 1. Buy USDT on any major exchange you have access to 2. Withdraw USDT to one of the listed CEX venues that accepts your jurisdiction 3. Trade USDT for BINI For on-chain BINI on BiniChain, you'll additionally need to: 1. Acquire ERC-20 BINI on Ethereum 2. Bridge to BiniChain (bridge mechanism documented in [BiniChain](/binichain/overview)) 3. Receive native BINI on BiniChain at 1:1 ## Related ERC-20 (Ethereum) and native (BiniChain) What to do after buying BINI Provide liquidity for BINI pools Move BINI between Ethereum and BiniChain # Architecture Source: https://docs.binibit.com/binichain/architecture EVM-compatible L1 architecture: consensus, block model, gas, smart contract environment. Some specific values (block time, gas limits, consensus algorithm) are pending confirmation from the chain engineering team. This page documents the architecture at the level of public commitment; specific numbers will be filled in before mainnet. ## Layer 1, EVM-compatible BiniChain is its own **Layer 1 chain**, not a rollup or sidechain. It operates independently with its own validator set, block production, and security model. It is **EVM-compatible**: * Solidity-deployable smart contracts * ETH-style accounts (`0x` addresses, ECDSA signatures) * Standard Ethereum tooling: Hardhat, Foundry, ethers.js, viem, MetaMask * Same transaction formats as Ethereum This means: any contract deployable on Ethereum can be deployed on BiniChain with no modification. ## Consensus (Specific algorithm TBD per chain team final implementation; expected: Proof-of-Stake with block-based finality.) Properties: * **Finality**: deterministic (no probabilistic reorgs after finalization window) * **Validator set**: bounded; rotation per fixed period * **Slashing**: standard for misbehavior (double-sign, downtime) ## Block model | Parameter | Value (TBD) | Notes | | --------------- | ----------- | ------------------------------- | | Block time | TBD | Likely 1-3 seconds for fast UX | | Block gas limit | TBD | Standard EVM gas semantics | | Finality time | TBD | Deterministic post-finalization | ## Gas mechanics BINI is the **native gas token**. Every transaction pays gas in BINI. Gas market: * Standard EIP-1559-style fee market (base fee + priority tip), pending team's specific implementation * Base fee may be **partially burned** (deflationary) and partially sent to validators (security) * Priority fees go entirely to the validator that includes the transaction The exact split (burn vs validator) is being finalized — see [BINI Sinks](/tokenomics/bini-sinks) sink #1 (Gas). ## Smart contract environment BiniChain runs an **EVM execution layer** with: * Standard Solidity 0.8.x compatibility * Standard precompiles (ecrecover, sha256, etc.) * Standard opcodes (push0, etc.) Some chain-specific opcodes or precompiles may be added for Binibit-specific functionality (e.g., Hive action log batching). These will be additive, not breaking. ## Account model ETH-style: * Externally Owned Accounts (EOAs) — controlled by ECDSA private keys * Smart contract accounts — controlled by their code * 20-byte addresses (`0x...`) * Account nonces * Native balance (BINI) ERC-20 / ERC-721 / ERC-1155 tokens deploy as standard contracts. ## Time and timestamps All BiniChain timestamps are **Unix epoch seconds** at the block level. Smart contracts read `block.timestamp` for current time within the EVM. For wall-clock applications, use BiniChain block timestamps as the canonical time source. ## Security model The chain's security depends on: 1. **Validator economic stake** — validators bond BINI; misbehavior slashes their stake 2. **Cryptographic finality** — confirmed transactions cannot be reverted post-finalization 3. **Open-source code** — chain implementation will be auditable 4. **Bug bounty** — pre and post mainnet (see Hive [Trust Model](/agent-hive/trust-model)) ## Hosted contracts BiniChain is the home of: | Contract group | Where documented | | ---------------------------------- | --------------------------------------------------------- | | BaiDEX V3 (Factory, Router, Pools) | [BaiDEX → Contracts](/baidex/contracts) | | HiveSpawner + SpawnedERC20 | [BaiDEX → Contracts](/baidex/contracts) | | HiveRegistry (ERC-721 / ERC-8004) | [AgentT Launchpad → Registry](/agentt-launchpad/registry) | | HiveActionLog | [Agent Hive → Action logs](/agent-hive/action-logs) | | Bridge A / Bridge B | [Bridges](/binichain/bridges) | | wBINI / USBI tokens | [BaiDEX → Contracts](/baidex/contracts) | ## Related chainId and connection details BINI as gas Connecting to BiniChain The token deployed at L1 # Bridges Source: https://docs.binibit.com/binichain/bridges Two bridges: Bridge A (CRS↔USBI) and Bridge B (BINI off-chain↔native), plus future Ethereum cross-chain bridge. ## Three bridges total | Bridge | What it moves | Direction | Ratio | Level gate | | ---------------------- | ---------------------------- | ---------------------------- | ---------- | --------------- | | **Bridge A** | Crystals (CRS) ↔ USBI | Off-chain ↔ BiniChain ERC-20 | 10,000 : 1 | Level 5 | | **Bridge B** | BINI off-chain ↔ BINI native | Off-chain ↔ BiniChain native | 1 : 1 | Level 7 | | **Cross-chain bridge** | ERC-20 BINI ↔ native BINI | Ethereum ↔ BiniChain | 1 : 1 | None (standard) | Bridge A and B are off-chain ↔ on-chain (within the Binibit ecosystem). The cross-chain bridge connects BiniChain to Ethereum. ## Bridge A — CRS to USBI Detail: [Tokenomics → USBI Bridge](/tokenomics/usbi-bridge), [Bini App → USBI Bridge](/bini-app/usbi-bridge). Summary: * Convert off-chain Crystals (CRS) earned in Bini App into on-chain USBI ERC-20 * Fixed rate: 10,000 CRS = 1 USBI * Gated at Level 5 (50M XP) * USBI used in BaiDEX pools as LP The Bridge A contract on BiniChain mints USBI when off-chain CRS is consumed. The Bini App backend signs the redemption request; the contract verifies and mints. ## Bridge B — BINI off-chain to native Detail: [Tokenomics → BINI Bridge](/tokenomics/bini-bridge), [Bini App → BINI Bridge](/bini-app/bini-bridge). Summary: * Convert off-chain BINI rewards (quest wins, lottery, grants) into native BINI on BiniChain * Fixed 1:1 ratio * Gated at Level 7 (105M XP) * Native BINI used for gas, staking (after withdrawal to Ethereum), pool participation The Bridge B contract on BiniChain transfers native BINI from the Rewards pool reserve when off-chain BINI is consumed. The Bini App backend signs; the contract verifies and transfers. ## Cross-chain bridge — Ethereum ↔ BiniChain For users moving BINI between Ethereum (ERC-20) and BiniChain (native): ``` ERC-20 BINI on Ethereum ←→ Native BINI on BiniChain (1:1) ``` Mechanism (TBD pending team finalization): * **Lock-and-mint**: lock BINI on origin chain, mint on destination * **Burn-and-mint**: burn on origin, mint on destination (more capital-efficient but trusts the bridge contracts) The exact mechanism + bridge contract addresses publish before mainnet. For now, the canonical path for cross-chain users is via Binibit Exchange (which handles the bridge as part of withdrawals). ## Anti-sybil Bridges B and A both have anti-sybil designs: | Bridge | Anti-sybil mechanism | | -------------------------- | -------------------------------------------------------------------- | | Bridge A (CRS→USBI) | Level 5 gate + USBI entitlement cap (max 101K USBI per user) | | Bridge B (BINI off→native) | Level 7 gate + monthly cap (TBD value) + per-account fraud detection | | Cross-chain | Standard signature verification + nonce + replay protection | The L7 gate on Bridge B is intentionally high — BINI is real-value, so the gate has to filter out farm accounts. ## Bridge security All bridges are smart contracts with: * Audited code (audit firm TBD pre-mainnet) * Multi-sig admin (no single key controls minting/locking) * Emergency pause (can halt withdrawals if exploit detected) * Time-delayed governance for parameter changes * On-chain logs for every action The bridge contracts custody real BINI (in the lock-and-mint case). Bridge security is **the most critical security concern** in the ecosystem. ## Failure modes | Scenario | What happens | | ---------------------------------------- | --------------------------------------------------------------------------------------------- | | Bridge contract has a bug | Emergency pause; users wait for fix; no funds lost from contract | | Bridge admin keys compromised | Multi-sig requires multiple keys; mitigates single-key compromise | | Cross-chain message lost | Replay protection ensures no double-spend; users can retry | | Off-chain backend (Bini App) compromised | Bridge contract verifies signatures cryptographically — backend can't mint without valid sigs | ## Related Bridge A formula Bridge B formula User-facing bridge UX What native BINI is for # Block Explorer Source: https://docs.binibit.com/binichain/explorer scan.binibit.com — visual browser for blocks, transactions, contracts, accounts. ## Overview The BiniChain block explorer is at [scan.binibit.com](https://scan.binibit.com). Standard block-explorer features: * **Search** — by transaction hash, block number, address, contract, ENS-like name * **Browse** — recent blocks, latest transactions * **Account view** — balance, transaction history, holdings, connected contracts * **Contract view** — verified source, ABI, read/write functions, events log * **Token tracker** — top tokens by holders, transfers, market cap (where data is available) * **Hive views** — Agent Tokens, Worker actions, registry NFTs ## Key views for ecosystem participants ### For traders * **Address page** — your wallet history, current holdings * **Transaction page** — verify your swap settled correctly * **Pool page** — view BaiDEX pool reserves, fees collected, recent swaps * **Agent Token tracker** — top Agent Tokens by holders / volume ### For LPs * **Position NFT page** — your specific V3 LP position with fees accrued * **Pool reserves page** — current depth, recent activity * **Worker action log** — what the assigned Worker has done recently ### For developers * **Contract verification** — view source, ABIs * **Event logs** — query events by topic * **Storage slots** — direct state read for advanced debugging ### For Hive participants * **Agent NFT registry** — all spawned Agent Tokens * **Worker action log** — full transparency feed * **Vote events** — governance actions on Workers ## API The explorer exposes a public API at `scan.binibit.com/api`: ```bash theme={null} # Get recent blocks curl "https://scan.binibit.com/api?module=block&action=getblockreward&blockno=12345" # Get transactions for an address curl "https://scan.binibit.com/api?module=account&action=txlist&address=0x...&startblock=0&endblock=99999999&sort=desc" # Get contract source (verified contracts) curl "https://scan.binibit.com/api?module=contract&action=getsourcecode&address=0x..." ``` The API mirrors Etherscan/Blockscout v1 API conventions for compatibility with existing tooling. ## Verifying contracts To verify your contract source on the explorer: 1. Go to your contract's address page on scan.binibit.com 2. Click "Verify & Publish" 3. Provide compiler version, optimization settings, and source code 4. Wait for verification to complete Verified contracts show: * Source code on the address page * ABI for direct interaction (Read/Write tabs) * Event log decoding Contract verification is **strongly recommended** for any contract intended for public use — it greatly improves trust. ## Hive-specific features Beyond standard block explorer features, scan.binibit.com surfaces: | Feature | URL pattern | | -------------------- | --------------------- | | Agent Token list | `/agent-tokens` | | Specific Agent Token | `/agent-token/0x...` | | Worker action log | `/worker/` | | Agent Hive overview | `/hive` | | Vote history | `/votes/` | These views are read-only — they pull data from on-chain logs and present it in human-readable form. ## Permalinks Direct links to common entities: ``` https://scan.binibit.com/block/ https://scan.binibit.com/tx/ https://scan.binibit.com/address/
https://scan.binibit.com/token/ https://scan.binibit.com/agent-token/
``` Use these in your tooling for shareable links. ## Status page integration When the BiniChain status page launches at `status.binibit.com`, it will show: * RPC uptime * Explorer uptime * Recent incidents For now, use scan.binibit.com directly to verify chain health (fresh blocks coming in = chain is up). ## Related Direct chain access What you're exploring Hive transparency in the explorer Verified contract addresses # Native BINI Source: https://docs.binibit.com/binichain/native-bini BINI as the native gas token of BiniChain. BINI Token → Overview covers allocation, emission, sinks, and where to buy. ## BINI as gas Every BiniChain transaction pays its gas in **native BINI**. This is the same role ETH plays on Ethereum — the native currency that pays validators / gets burned. | | Ethereum | BiniChain | | --------------- | -------------------- | -------------------- | | Native currency | ETH | BINI | | Token contract | Native (no contract) | Native (no contract) | | ERC-20 wrapper | wETH | **wBINI** | ## Acquiring native BINI Three paths to get BINI on BiniChain: ### 1. Bridge from Ethereum The [BaiDEX bridge](/baidex/contracts) (when deployed) lets you convert ERC-20 BINI on Ethereum into native BINI on BiniChain at 1:1. ``` ERC-20 BINI on Ethereum → Bridge → Native BINI on BiniChain (1:1) ``` This is the primary path for users who hold ERC-20 BINI from CEX purchases. ### 2. Buy on Binibit Exchange [binibit.com/en/exchange?symbol=BINI\_USDT](https://binibit.com/en/exchange?symbol=BINI_USDT) sells BINI as ERC-20. Withdraw to BiniChain (when supported by the exchange UI) — bypasses the explicit bridge for some flows. ### 3. Bridge B (off-chain rewards → native) If you've earned off-chain BINI in the [Bini App](/bini-app/overview) (quest rewards, lottery wins), use [Bridge B](/bini-app/bini-bridge) at Level 7+ to convert at 1:1. ## Wrapping and unwrapping To use BINI in BaiDEX pools (V3 LP positions), you wrap it to **wBINI** (ERC-20): ```javascript theme={null} // Wrap: native BINI → wBINI ERC-20 await wbiniContract.deposit({ value: ethers.parseEther("1.0") }); // Unwrap: wBINI ERC-20 → native BINI await wbiniContract.withdraw(ethers.parseEther("1.0")); ``` 1:1 conversion, no fee. ## Gas cost expectations Typical transaction gas (subject to BiniChain final settings): | Transaction | Gas | Cost (at chain gas price × \$0.12 BINI) | | ------------------------ | --------------------- | --------------------------------------- | | Native BINI transfer | \~21,000 | \~\$0.005 (illustrative) | | ERC-20 transfer | \~50,000 | \~\$0.012 | | BaiDEX swap (single hop) | \~150,000 | \~\$0.036 | | AgentT Launchpad spawn | \~500,000 + spawn fee | \~\$0.12 + fee | | LP position mint | \~250,000 | \~\$0.06 | Numbers are illustrative — final gas economics depend on chain config + actual gas price. ## Block reward and burn BiniChain validators earn block rewards in BINI: ``` Block reward = priority fees + (optional) emission ``` Per the [BINI emission schedule](/bini-token/emission), the Rewards pool (60% / 600M BINI) is allocated over 4 years. Some portion of that may flow to validators as block rewards (final policy TBD). The base fee (EIP-1559 style) is partially **burned** — sink #1 in [BINI Sinks](/tokenomics/bini-sinks). ## Native BINI vs ERC-20 BINI | | ERC-20 BINI (Ethereum) | Native BINI (BiniChain) | | -------------------------- | ------------------------------------------------------ | ------------------------- | | Address | `0x5a76a2830859c321a50937a22fde571fbf4810f3` (BINI V2) | No contract — native | | Used as gas? | No (ETH is gas on Ethereum) | **Yes** | | Tradable on CEX? | Yes (Binibit, Azbit, Blynex) | Indirectly (via bridge) | | Stake on Binibit Exchange? | Yes (160% APR) | No | | Used in BaiDEX pools? | Bridge to wBINI first | Wrap to wBINI | | Total supply ceiling | 1B (combined with native) | 1B (combined with ERC-20) | The 1B supply is **shared across both representations**. The bridge maintains the 1:1 peg — at any time, total ERC-20 + total native = 1,000,000,000 BINI. ## Related How to move BINI on/off chain Full token spec wBINI contract address Gas burn mechanic # Network Parameters Source: https://docs.binibit.com/binichain/network-params chainId, RPC, explorer, native currency settings for connecting to BiniChain. ## Connection details | Parameter | Value | | ------------------- | ---------------------------------------------------- | | **Chain name** | BiniChain | | **Chain ID** | (pending mainnet) | | **RPC URL** | [https://rpc.binibit.com](https://rpc.binibit.com) | | **WebSocket URL** | wss\://rpc.binibit.com (when published) | | **Block explorer** | [https://scan.binibit.com](https://scan.binibit.com) | | **Native currency** | BINI | | **Decimals** | 18 | ## Add to MetaMask ```javascript theme={null} await window.ethereum.request({ method: "wallet_addEthereumChain", params: [{ chainId: "0x...", // hex of chainId chainName: "BiniChain", nativeCurrency: { name: "BINI", symbol: "BINI", decimals: 18, }, rpcUrls: ["https://rpc.binibit.com"], blockExplorerUrls: ["https://scan.binibit.com"], }] }); ``` Once finalized, the chain will be addable via [chainlist.org](https://chainlist.org) (community list) for easy click-to-add. ## ethers.js ```javascript theme={null} import { ethers } from "ethers"; const provider = new ethers.JsonRpcProvider("https://rpc.binibit.com"); const network = await provider.getNetwork(); console.log("Connected to:", network.name, "chainId:", network.chainId); ``` ## viem ```javascript theme={null} import { createPublicClient, http } from "viem"; const biniChain = { id: /* chainId */, name: "BiniChain", nativeCurrency: { name: "BINI", symbol: "BINI", decimals: 18 }, rpcUrls: { default: { http: ["https://rpc.binibit.com"] } }, blockExplorers: { default: { name: "Binibit Scan", url: "https://scan.binibit.com" } }, }; const client = createPublicClient({ chain: biniChain, transport: http(), }); ``` ## Hardhat config ```javascript theme={null} // hardhat.config.js module.exports = { networks: { binichain: { url: "https://rpc.binibit.com", chainId: /* chainId */, accounts: [process.env.PRIVATE_KEY], }, }, }; ``` ## Foundry config ```toml theme={null} # foundry.toml [rpc_endpoints] binichain = "https://rpc.binibit.com" [etherscan] binichain = { key = "...", url = "https://scan.binibit.com/api" } ``` ## Sandbox / testnet During the sandbox phase, contracts have been deployed on **Base Sepolia** (chainId 84532) for development and testing. See [BaiDEX → Contracts](/baidex/contracts) for testnet addresses. The BiniChain mainnet RPC and chainId values will be published as part of the v2.x rollout. ## Related Underlying chain design Endpoint usage and limits scan.binibit.com Gas token # BiniChain Overview Source: https://docs.binibit.com/binichain/overview EVM Layer 1 with BINI as native gas. Hosts BaiDEX, AgentT Launchpad, Agent Hive, and the bridges. Tokenomics → Ecosystem Overview shows how BiniChain hosts the rest of the ecosystem. ## What BiniChain is **BiniChain is an EVM-compatible Layer 1** with **BINI** as its native gas token. | | | | ---------------- | ---------------------------------------------------- | | Type | EVM L1 | | Native gas token | BINI | | RPC | [https://rpc.binibit.com](https://rpc.binibit.com) | | Block explorer | [https://scan.binibit.com](https://scan.binibit.com) | | Chain ID | (to be confirmed by chain team) | | Block time | (to be confirmed by chain team) | BiniChain hosts: * **BaiDEX** — agent-managed AMM * **AgentT Launchpad** — Agent Token spawn factory * **Agent Hive** — Queens, Scouts, Workers, Swarm * **Bridge contracts** — Bridge A (CRS↔USBI) and Bridge B (BINI off↔native) * **Action log contracts** — on-chain transparency for the Hive ```mermaid theme={null} flowchart TB subgraph BC["BiniChain · EVM L1"] direction TB BaiDEX["BaiDEX
V3 AMM + agents"] Launchpad["AgentT Launchpad
Spawner contract"] Hive["Agent Hive
Registry + Action Log"] Bridges["Bridges
A: CRS↔USBI · B: BINI off↔native"] Tokens["Tokens
BINI native · wBINI · USBI · Agent Tokens"] end Validators["Validators
(BINI staked, block production)"] RPC["RPC
rpc.binibit.com"] Explorer["Explorer
scan.binibit.com"] External((External users
+ apps)) External -- swap/LP --> BaiDEX External -- spawn --> Launchpad External -- bridge --> Bridges External -- query --> RPC External -- view --> Explorer Validators -- secure --> BC BC -- exposes --> RPC BC -- exposes --> Explorer Launchpad -- creates pool on --> BaiDEX Launchpad -- registers --> Hive Hive -- manages --> BaiDEX classDef chain fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef infra fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef external fill:#fce7f3,stroke:#db2777,color:#831843 class BaiDEX,Launchpad,Hive,Bridges,Tokens chain class Validators,RPC,Explorer infra class External external ``` ## Inside the docs Consensus, block model, gas mechanics chainId, RPC, explorer, throttling BINI as gas token Bridge A and Bridge B JSON-RPC endpoints, rate limits, WebSocket Validator onboarding (post-mainnet) scan.binibit.com API ## Quick start Connect to BiniChain RPC: ```javascript theme={null} import { ethers } from "ethers"; const provider = new ethers.JsonRpcProvider("https://rpc.binibit.com"); const blockNumber = await provider.getBlockNumber(); console.log("Latest block:", blockNumber); ``` Add BiniChain to MetaMask (when chainId is finalized): ```javascript theme={null} await window.ethereum.request({ method: "wallet_addEthereumChain", params: [{ chainId: "0x...", // hex of chainId chainName: "BiniChain", nativeCurrency: { name: "BINI", symbol: "BINI", decimals: 18 }, rpcUrls: ["https://rpc.binibit.com"], blockExplorerUrls: ["https://scan.binibit.com"] }] }); ``` ## Related AMM running on BiniChain Native gas + ecosystem token Spawns Agent Tokens on BiniChain Action logs live on BiniChain # RPC Source: https://docs.binibit.com/binichain/rpc JSON-RPC endpoint, WebSocket, rate limits, and standard methods. ## Endpoint ``` HTTP: https://rpc.binibit.com WebSocket: wss://rpc.binibit.com (when published) ``` ## Standard JSON-RPC BiniChain implements the standard Ethereum JSON-RPC API. Common methods: | Method | Purpose | | --------------------------- | ------------------------------ | | `eth_chainId` | Get the chain ID | | `eth_blockNumber` | Latest block number | | `eth_getBalance` | Get account balance | | `eth_getTransactionCount` | Get account nonce | | `eth_gasPrice` | Suggested gas price | | `eth_estimateGas` | Estimate gas for a transaction | | `eth_sendRawTransaction` | Submit signed transaction | | `eth_getTransactionByHash` | Lookup transaction | | `eth_getTransactionReceipt` | Lookup receipt | | `eth_getLogs` | Query event logs | | `eth_call` | Read contract state | | `net_version` | Network ID (mirror of chainId) | Plus standard `web3_clientVersion` and others. ## Curl examples Get latest block: ```bash theme={null} curl https://rpc.binibit.com \ -X POST \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' ``` Get balance: ```bash theme={null} curl https://rpc.binibit.com \ -X POST \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0xYourAddress","latest"]}' ``` ## ethers.js example ```javascript theme={null} import { ethers } from "ethers"; const provider = new ethers.JsonRpcProvider("https://rpc.binibit.com"); // Read state const balance = await provider.getBalance("0xYourAddress"); const block = await provider.getBlock("latest"); // Subscribe (HTTP doesn't support subscriptions; use WebSocket below) // Send transaction (requires signer) const wallet = new ethers.Wallet(privateKey, provider); const tx = await wallet.sendTransaction({ to: "0xRecipient", value: ethers.parseEther("0.01"), }); await tx.wait(); ``` ## WebSocket subscriptions For real-time data: ```javascript theme={null} import { ethers } from "ethers"; const provider = new ethers.WebSocketProvider("wss://rpc.binibit.com"); // Subscribe to new blocks provider.on("block", (blockNumber) => { console.log("New block:", blockNumber); }); // Subscribe to events on a contract const contract = new ethers.Contract(addr, abi, provider); contract.on("Transfer", (from, to, amount) => { console.log(`${from} sent ${amount} to ${to}`); }); ``` ## Rate limits Standard rate limits apply per IP: | Tier | Limit | | ---------- | ----------------------------------- | | Public RPC | 60 req/min, 10 req/sec burst | | WebSocket | 100 concurrent subscriptions per IP | Higher limits available for whitelisted integrations — contact [api@binibit.com](mailto:api@binibit.com). ## Error responses Standard JSON-RPC errors: ```json theme={null} { "jsonrpc": "2.0", "id": 1, "error": { "code": -32603, "message": "Internal error", "data": "..." } } ``` Common codes: | Code | Meaning | | ------ | --------------------------------- | | -32600 | Invalid request | | -32601 | Method not found | | -32602 | Invalid params | | -32603 | Internal error | | -32000 | Server error (rate limited, etc.) | Rate-limited responses also return HTTP 429 with `Retry-After` header. ## Public archive node For historical queries beyond the standard pruning window: * Production RPC (`rpc.binibit.com`) keeps recent state and a moving window of historical * For deep historical, use a third-party archive node provider (when available) For now, primary use case is real-time and recent-history. Deep archive is a v2.x roadmap item. ## Tooling | Tool | Notes | | ---------------- | ------------------------------------------------------------- | | MetaMask | Add chain via [Network Parameters](/binichain/network-params) | | ethers.js | Standard provider works | | viem | Standard `createPublicClient` works | | Hardhat | Configure as a network in hardhat.config.js | | Foundry | Configure as RPC endpoint in foundry.toml | | 1inch / ParaSwap | When integrated, will route through BaiDEX | ## Related chainId and config Visual block / tx browser Use RPC for swap calls What's running behind the RPC # Validators Source: https://docs.binibit.com/binichain/validators Validator role, requirements, and onboarding (post-mainnet). Validator onboarding opens **post-mainnet**. The structure below describes the canonical model. Specific values (minimum stake, slashing percentages, performance bands) are TBD pending chain team final design. ## What validators do BiniChain validators: 1. **Propose blocks** in their assigned slots 2. **Attest** to other validators' blocks (vote on chain canonicality) 3. **Finalize** blocks via the consensus protocol 4. **Earn rewards** for honest participation 5. **Lose stake** for misbehavior (slashing) Standard PoS validator role. ## Becoming a validator To become a validator: 1. Acquire the minimum self-stake in BINI (TBD value) 2. Run a BiniChain validator node (hardware + uptime requirements TBD) 3. Submit on-chain registration with bonded stake 4. Wait for activation queue 5. Begin attesting and proposing in your slots Activation is **first-come-first-served** for available slots, with an upper limit on validator set size. ## Validator set size The validator set has a **soft cap** to keep block finalization efficient: * Lower bound: enough to be decentralized (e.g., 64+ validators) * Upper bound: enough that consensus rounds are fast (e.g., 256 validators) Final values per chain team's calibration. ## Minimum stake The minimum self-stake will be set high enough to be meaningful but low enough that mid-size holders can participate. Likely range: 100K–1M BINI (TBD). The minimum may **decrease over time** as the validator set matures and network value grows. ## Rewards Validators earn: * **Block rewards** in BINI (when proposing or attesting) * **Priority fees** from transactions in proposed blocks * (Optional) **MEV** captured during block construction (subject to fairness rules) The exact reward formula is set by chain governance. Total annualized validator yield is calibrated to be **competitive with similar PoS chains** at the current network size. ## Slashing Validators lose stake for: | Offense | Slashing % | | --------------------------------------------------------- | ---------------------------- | | Double signing (proposing two blocks for the same slot) | High (e.g., 5-50% of stake) | | Surround voting (voting that contradicts a previous vote) | High | | Extended downtime | Low to moderate (per period) | | Incorrect attestation | Low | Severe offenses can result in **ejection** from the validator set, with stake locked or partly slashed. ## Withdrawal Validators can voluntarily exit the active set: 1. Submit on-chain exit request 2. Wait through the standard exit queue 3. Stake unlocks after a withdrawal cooldown 4. BINI returned to the validator's address Cooldown periods exist to prevent attack patterns where an attacker exits before slashing resolves. ## Validator vs delegator BiniChain (per chain team's final design) may support **delegation**: * Holders without validator infrastructure can **delegate** their BINI to existing validators * Delegators earn a pro-rata share of validator rewards (minus a commission) * Delegators are slashed pro-rata if their validator misbehaves Delegation lets BINI holders earn validator yield without running infrastructure. Specifics TBD. ## Hardware requirements Validator node requirements (TBD per chain team): * CPU: modern multi-core (e.g., 8 cores) * RAM: 16-64 GB * Storage: 1 TB+ SSD (for state and historical data) * Network: stable connection, 100+ Mbps * Uptime: 99.5%+ for non-trivial reward share Running a validator is non-trivial — operators should be technically experienced. ## Validator onboarding timeline 1. **Pre-mainnet (now)**: planning + chain implementation 2. **Mainnet launch**: initial validator set bootstrapped by team + early partners 3. **Post-mainnet (months 1-6)**: validator slot opens; first external validators onboard 4. **Mature**: validator set grows to soft cap; delegation enabled External validator onboarding is **not open** during the sandbox phase. ## Related Consensus protocol underlying validators What validators stake Where validator rewards come from Where to acquire BINI # Changelog Source: https://docs.binibit.com/changelog Versioned changes to the Binibit public API. ## v1.0 — 2026-04-29 Initial public release of the Spot Market API on `public-api.binibit.com` plus the aggregator-spec namespace on `internal-api.binibit.com/.../getcoingecko/*`. ### Market data endpoints (public-api.binibit.com/api) * `GET /tickers` — single-pair ticker * `GET /orderbook` — 40 bids + 40 asks per pair * `GET /deals` — recent trades per pair, paginated * `GET /ohlc` — OHLCV candles, intervals from 1 minute to 1 year * `GET /currencies` — list of currency codes * `GET /currencies/pairs` — pair settings (precision, min order size) * `GET /currencies/commissions` — default commissions catalogue * `GET /healthcheck` — liveness probe ### Aggregator-spec endpoints (internal-api.binibit.com/.../getcoingecko) * `GET /tickers` — all pairs in one call, CoinGecko array shape * `GET /orderbook` — CoinGecko `bids/asks` shape * `GET /historical_trades` — CoinGecko `{buy: [], sell: []}` shape * `GET /asset` — CoinMarketCap-compatible asset metadata ### Standards * Aggregator-spec schema follows CoinGecko Integration API Standards v8 (Section A: Spot Exchanges) * Public OpenAPI 3.0 spec for `public-api.binibit.com` available at [/swagger/v1/swagger.json](https://public-api.binibit.com/swagger/v1/swagger.json) ## Roadmap ### v1.x — planned * **Cleaner path alias** `/v1/spot/market/*` mapped to current routes (so the user-facing path doesn't carry the `getcoingecko` legacy name) * **Server time** endpoint (`GET /api/time`) — useful for clients signing requests against the trading API * **24h summary** endpoint (`GET /api/summary`) — compact one-call summary of all pairs (CMC-compatible) * **Status page** at `status.binibit.com` ### v2.0 — planned * **Authenticated trading API documentation** — endpoints already exist on `public-api.binibit.com`, currently with auth-signature disabled. v2 documents the HMAC-SHA256 signing scheme already used by the Binibit web client. * **WebSocket streams** for tickers, order book diffs, and trades ## Subscribe The recommended ways to track changes: * **Email** — send a request to [api@binibit.com](mailto:api@binibit.com) with subject `[Subscribe: API updates]` to be notified of breaking changes and new versions * **GitHub** — star or watch [github.com/Binibit/docs](https://github.com/Binibit/docs) for release and PR notifications * **Atom feed** — `https://github.com/Binibit/docs/releases.atom` # FAQ Source: https://docs.binibit.com/faq Frequently asked questions about the Binibit public API. Not for market data. All endpoints under `public-api.binibit.com/api/*` (tickers, orderbook, deals, ohlc, currencies, healthcheck) and the aggregator-spec namespace are public. The trading API on `public-api.binibit.com` (create/cancel orders, withdrawals) does require HMAC-SHA256 request signing with an API key + secret — see the [v2.0 roadmap](/changelog#roadmap). `public-api.binibit.com` is the primary REST API. `internal-api.binibit.com/.../getcoingecko/*` is a small subset of market data reshaped to match the CoinGecko Integration API Standards v8 — kept around so data aggregators can ingest without translation. See [Base URL](/general/base-url). Tickers and order books refresh every few seconds. Cache for at least 5 seconds on your side; polling more frequently will not return fresher data and will count against your [rate limit](/general/rate-limits). Pairs with zero 24-hour volume or empty order books are excluded from the aggregator-spec `/tickers`. They still appear in the primary API's [`/api/currencies/pairs`](/api-reference/market-data/currencies-pairs). Numbers. JavaScript's native `Number` type is precise for the prices and volumes seen on this exchange, but for safety use a high-precision decimal library (`decimal.js`, `bignumber.js`, Python `Decimal`, Go `big.Float`) when doing arithmetic. `price = X` means the most recent trade for the pair was at `X` units of the **target** currency per **one unit** of the **base** currency. For `AAVE_USDT` with `price = 97.44`, one AAVE last traded for 97.44 USDT. Historical naming. The aggregator-spec namespace will get a cleaner alias (`/v1/spot/market/*`) in a future release; the legacy host will continue to work as a redirect for at least 90 days after migration. Not yet. WebSocket streams for tickers, order book, and trades are on the [v2.0 roadmap](/changelog#roadmap). Watch the [GitHub repo](https://github.com/Binibit/docs) for release notifications. Yes. Attribution is appreciated but not required for non-commercial use. For high-volume commercial use, contact [api@binibit.com](mailto:api@binibit.com) for elevated rate limits. Yes. The primary API publishes an OpenAPI 3.0 spec at [`https://public-api.binibit.com/swagger/v1/swagger.json`](https://public-api.binibit.com/swagger/v1/swagger.json), with an interactive playground at [`/swagger/`](https://public-api.binibit.com/swagger/). The `type` field reflects the **taker side**: * **`buy`** — taker bought (an ask was removed from the order book) * **`sell`** — taker sold (a bid was removed from the order book) Each trade has exactly one taker, so each trade appears in exactly one of the two arrays. On the aggregator-spec namespace they are milliseconds since the Unix epoch, e.g. `1777397315466` ≈ `2026-04-28T22:37:55.466Z`. The primary API uses ISO 8601 strings instead. See [Timestamps](/general/timestamps). Email [api@binibit.com](mailto:api@binibit.com). We can: * Whitelist your IP for unlimited rate limit * Provide direct contact for the data engineering team * Coordinate on listing review and verification ## Didn't find your answer? Reach out to the Binibit API team. # Authentication Source: https://docs.binibit.com/general/authentication Public market data is anonymous. Trading and wallet endpoints require HMAC-SHA256 request signing. ## Public market data — no auth All market data endpoints documented in [API Reference](/api-reference/introduction) are **public**. They require: * No API key * No HMAC signature * No bearer token Examples: ```bash theme={null} curl "https://public-api.binibit.com/api/tickers?currencyPairCode=ETH_BTC" curl "https://public-api.binibit.com/api/orderbook?currencyPairCode=TRX_USDT" curl "https://public-api.binibit.com/api/healthcheck" ``` ## Trading and wallets — HMAC-SHA256 The trading and wallet endpoints (create/cancel orders, deposits, withdrawals, balances) on `public-api.binibit.com` use HMAC-SHA256 request signing. Detailed documentation for the signing flow is on the [v2.0 roadmap](/changelog#roadmap). The scheme below is the same one the Binibit web client uses today and is reproduced from the upstream OpenAPI spec at [`/swagger/`](https://public-api.binibit.com/swagger/). ### Signing scheme 1. Generate an API key pair (`publicKey`, `privateKey`) at [binibit.com/apikeys](https://binibit.com/apikeys). 2. Build the canonical signature text: ``` signatureText = publicKey + requestUrl + requestBodyString ``` * `publicKey` — your API public key, e.g. `b2H9TlfRu6MOgG4m9wvrf9maSUiPsQJEui0JrB` * `requestUrl` — full URL of the request, e.g. `https://public-api.binibit.com/api/orders` * `requestBodyString` — the JSON body as a single-line string for `POST`/`PUT`, or empty string for `GET`/`DELETE`. Example: `{"isBid":true,"currencyPairCode":"ETH_BTC","amount":0.01,"price":0.02}` 3. Compute the HMAC-SHA256 over UTF-8 bytes of `signatureText` using `privateKey` as the key. 4. Encode the resulting digest as a lowercase hex string. 5. Send it in the `API-Signature` header along with `API-PublicKey`. ### JavaScript ```javascript theme={null} import CryptoJS from "crypto-js"; const publicKey = "b2H9..."; const privateKey = "..."; // never log or expose const url = "https://public-api.binibit.com/api/orders"; const body = JSON.stringify({ isBid: true, currencyPairCode: "ETH_BTC", amount: 0.01, price: 0.02, }); const signatureText = publicKey + url + body; const signature = CryptoJS.enc.Hex.stringify( CryptoJS.HmacSHA256(signatureText, privateKey) ); await fetch(url, { method: "POST", headers: { "Content-Type": "application/json", "API-PublicKey": publicKey, "API-Signature": signature, }, body, }); ``` ### C\# ```csharp theme={null} using System.Security.Cryptography; using System.Text; string publicKey = "b2H9..."; string privateKey = "..."; string requestUrl = "https://public-api.binibit.com/api/orders"; string body = "{\"isBid\":true,\"currencyPairCode\":\"ETH_BTC\",\"amount\":0.01,\"price\":0.02}"; string signature = new HMACSHA256(Encoding.UTF8.GetBytes(privateKey)) .ComputeHash(Encoding.UTF8.GetBytes(publicKey + requestUrl + body)) .Aggregate(new StringBuilder(), (sb, b) => sb.AppendFormat("{0:x2}", b)) .ToString(); ``` A signature looks like: ``` b7238692e0537d3a7fd13faff266d315e3185247e1644c1155f60e6d4e4e445d ``` ### Things to watch * **No separators between the three parts** of `signatureText`. They are concatenated verbatim. * **Body string must match exactly** the bytes you transmit. Reformatting (different key order, whitespace) breaks the signature. * **Server clock skew** can cause auth failures if the server enforces a timestamp window — see the planned `GET /api/time` endpoint on the [roadmap](/changelog#roadmap). # Base URL Source: https://docs.binibit.com/general/base-url Production endpoint hostnames for the Binibit public API. ## Production hosts Two public hostnames serve different purposes: | Host | What it serves | | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `https://public-api.binibit.com` | **Primary public API.** Market data, trading, and wallet endpoints. Used by direct integrators and the Binibit web client. | | `https://internal-api.binibit.com/api/marketdata/getcoingecko` | **Aggregator-spec namespace.** A subset of market data reshaped to match the CoinGecko Integration API Standards v8. Used by data aggregators (CoinGecko, CoinMarketCap, DefiLlama) for ingestion. | Most developers should use `public-api.binibit.com`. The aggregator-spec namespace exists only to provide one-call ingestion in the format aggregators expect — see [Aggregator Compatibility](/api-reference/aggregator/tickers). ## Endpoint examples ### Primary (public-api.binibit.com) ``` https://public-api.binibit.com/api/healthcheck https://public-api.binibit.com/api/tickers?currencyPairCode=ETH_BTC https://public-api.binibit.com/api/orderbook?currencyPairCode=TRX_USDT https://public-api.binibit.com/api/deals?currencyPairCode=TRX_USDT https://public-api.binibit.com/api/ohlc?currencyPairCode=BTC_USDT&interval=hour&start=2026-04-28T00:00:00&end=2026-04-29T00:00:00 https://public-api.binibit.com/api/currencies https://public-api.binibit.com/api/currencies/pairs https://public-api.binibit.com/api/currencies/commissions ``` ### Aggregator-spec (internal-api.binibit.com) ``` https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers https://internal-api.binibit.com/api/marketdata/getcoingecko/orderbook?ticker_id=ETH_BTC https://internal-api.binibit.com/api/marketdata/getcoingecko/historical_trades?ticker_id=ETH_BTC https://internal-api.binibit.com/api/marketdata/getcoingecko/pairs ``` ## Protocol * HTTPS only. HTTP requests are redirected to HTTPS. * TLS 1.2 or higher. ## CORS CORS is enabled for all origins (`Access-Control-Allow-Origin: *`) on all public endpoints, so the API can be called directly from browser-based applications. ## Caching Some endpoints set `Cache-Control: public, max-age=N` headers. Respect those — calling more frequently than the cache TTL will not return fresher data and will count against your [rate limit](/general/rate-limits). # Errors Source: https://docs.binibit.com/general/errors HTTP status codes and error response format. ## HTTP status codes | Status | Meaning | | --------------------------- | --------------------------------------------- | | `200 OK` | Request succeeded. | | `400 Bad Request` | Missing or invalid query parameter. | | `404 Not Found` | Unknown ticker\_id, asset, or path. | | `429 Too Many Requests` | [Rate limit](/general/rate-limits) exceeded. | | `500 Internal Server Error` | Transient server-side error — retry. | | `503 Service Unavailable` | Maintenance window or overload — retry later. | ## Error envelope Non-2xx responses include a JSON body: ```json theme={null} { "code": "INVALID_PARAM", "message": "ticker_id is required", "field": "ticker_id" } ``` | Field | Type | Description | | --------- | -------------- | ----------------------------------------------------------------------- | | `code` | string | Machine-readable error code (see table below). | | `message` | string | Human-readable description. | | `field` | string \| null | The query parameter or field that triggered the error, when applicable. | ## Error codes | Code | HTTP | Meaning | | --------------- | ---- | -------------------------------------------------------------------------- | | `INVALID_PARAM` | 400 | A query parameter is missing, malformed, or out of range. | | `NOT_FOUND` | 404 | The requested ticker\_id, asset, or path does not exist. | | `RATE_LIMIT` | 429 | Per-IP rate limit exceeded. See `Retry-After` header. | | `INTERNAL` | 500 | Unexpected server error. Safe to retry with backoff. | | `UNAVAILABLE` | 503 | Service is temporarily down for maintenance. See `Retry-After` if present. | ## Retry strategy | HTTP | Retry? | Strategy | | ---------------- | ------ | ------------------------------------------------ | | 4xx (except 429) | No | Fix the request. | | 429 | Yes | Honor `Retry-After`. | | 500 | Yes | Exponential backoff with jitter, max 5 attempts. | | 503 | Yes | Honor `Retry-After`, longer backoff. | ```python theme={null} import time, random, requests def fetch_with_retry(url, max_attempts=5): for attempt in range(max_attempts): r = requests.get(url, timeout=10) if r.status_code == 200: return r.json() if r.status_code == 429: time.sleep(int(r.headers.get("Retry-After", "1"))) continue if 500 <= r.status_code < 600: time.sleep((2 ** attempt) + random.random()) continue r.raise_for_status() raise RuntimeError(f"Exhausted retries for {url}") ``` # Rate Limits Source: https://docs.binibit.com/general/rate-limits Per-IP request quotas for public endpoints. ## Default quotas | Tier | Scope | Limit | | ------ | ----------------------------- | ----------------------------- | | Public | All Spot Market API endpoints | **60 requests / minute / IP** | | Burst | All public | **10 requests / second / IP** | Both limits apply simultaneously. Exceeding either returns HTTP `429`. ## Response headers Every successful response includes: | Header | Meaning | | ----------------------- | ------------------------------------------- | | `X-RateLimit-Limit` | Quota for the current window (e.g. `60`). | | `X-RateLimit-Remaining` | Requests left in the current window. | | `X-RateLimit-Reset` | Unix timestamp (ms) when the window resets. | Example: ```http theme={null} HTTP/1.1 200 OK Content-Type: application/json X-RateLimit-Limit: 60 X-RateLimit-Remaining: 57 X-RateLimit-Reset: 1777399720000 ``` ## When you exceed the limit ```http theme={null} HTTP/1.1 429 Too Many Requests Retry-After: 12 Content-Type: application/json { "code": "RATE_LIMIT", "message": "Rate limit exceeded. Retry after 12 seconds." } ``` The `Retry-After` header tells you how many seconds to wait before retrying. ## Best practices `/tickers` is updated every few seconds. Cache for at least 5 seconds on your side instead of polling continuously. Always honor the `Retry-After` header on `429`. Do not retry immediately. On repeated `429` or `5xx`, back off exponentially with jitter. Use `/tickers` (returns all pairs) instead of polling each pair individually. ## Elevated limits Aggregators, market makers, and high-volume consumers can request: * Higher per-IP quotas * Static IP whitelisting (no rate limit) * Dedicated read replicas Contact [api@binibit.com](mailto:api@binibit.com) with: * Use case description * Estimated request volume * Source IP range or CIDR # Response Format Source: https://docs.binibit.com/general/response-format JSON conventions used by the Binibit API. ## Content type All responses use: ```http theme={null} Content-Type: application/json; charset=utf-8 ``` ## Successful response HTTP `200 OK` with body specific to the endpoint. See [API Reference](/api-reference/introduction) for per-endpoint schemas. ## Numeric values | Field type | Format | Example | | ---------- | ----------------------------------------- | --------------- | | Price | Decimal number, up to 8 fractional digits | `0.32384459` | | Volume | Decimal number, up to 8 fractional digits | `9900.94` | | Timestamp | Integer milliseconds since Unix epoch | `1777399660025` | | ID | Integer | `290334` | JavaScript `Number` cannot precisely represent integers larger than 2^53. For trade IDs and timestamps in JavaScript, treat them as numbers but never perform arithmetic that requires more than 53 bits of precision. For prices and volumes use a high-precision decimal library (e.g. `decimal.js`, `bignumber.js`) to avoid floating-point error. ## Empty data | Endpoint | Empty response | | -------------------- | ------------------------------------------------------------------ | | `/tickers` | `[]` (empty array) | | `/orderbook` | `{ "ticker_id": "...", "timestamp": ..., "bids": [], "asks": [] }` | | `/historical_trades` | `{ "buy": [], "sell": [] }` | | `/asset` | `{}` | A pair with no recent trades or empty order book will simply return empty arrays — not `404`. ## Pagination `/historical_trades` supports limited pagination via the `limit`, `start_time`, and `end_time` query parameters. See its [endpoint reference](/api-reference/historical-trades). `/tickers`, `/orderbook`, and `/asset` are not paginated. ## Sorting | Endpoint | Default sort | | -------------------- | ------------------------------------------------ | | `/tickers` | Alphabetical by `ticker_id` | | `/orderbook` `bids` | Price descending (best bid first) | | `/orderbook` `asks` | Price ascending (best ask first) | | `/historical_trades` | `trade_timestamp` descending (most recent first) | ## Compression The API supports `gzip` and `br` (Brotli). Send `Accept-Encoding: gzip, br` for smaller responses. ## Versioning The current API is **v1**. Path versioning will be added in future releases (e.g. `/v2/tickers`). v1 endpoints are stable and will receive a 30-day deprecation notice before any breaking change. # Timestamps Source: https://docs.binibit.com/general/timestamps All timestamps are Unix epoch in milliseconds. ## Unit Every timestamp returned by the API is an **integer in milliseconds** since the Unix epoch (`1970-01-01T00:00:00Z`). ```json theme={null} { "timestamp": 1777399660025, "trade_timestamp": 1777397315466 } ``` ## Conversion ```javascript JavaScript theme={null} const ts = 1777399660025; new Date(ts).toISOString(); // "2026-04-28T22:41:00.025Z" ``` ```python Python theme={null} from datetime import datetime, UTC ts = 1777399660025 datetime.fromtimestamp(ts / 1000, tz=UTC).isoformat() # '2026-04-28T22:41:00.025000+00:00' ``` ```go Go theme={null} package main import ( "fmt" "time" ) func main() { ts := int64(1777399660025) fmt.Println(time.UnixMilli(ts).UTC().Format(time.RFC3339Nano)) // 2026-04-28T22:41:00.025Z } ``` ```rust Rust theme={null} use chrono::{DateTime, Utc}; let ts: i64 = 1777399660025; let dt: DateTime = DateTime::from_timestamp_millis(ts).unwrap(); println!("{}", dt.to_rfc3339()); // 2026-04-28T22:41:00.025+00:00 ``` ## Sending timestamps in requests Query parameters that accept a timestamp (e.g. `start_time`, `end_time` on `/historical_trades`) also expect **milliseconds**: ```bash theme={null} curl "https://internal-api.binibit.com/api/marketdata/getcoingecko/historical_trades?ticker_id=TRX_USDT&start_time=1777380000000&end_time=1777400000000" ``` ## Server time Server clock is synced via NTP. Drift is typically under 100 ms. A dedicated `GET /time` endpoint is on the [roadmap](/introduction#roadmap) for v1.x. # Binibit Ecosystem Docs Source: https://docs.binibit.com/index Centralized exchange, EVM L1, agent-managed DEX, launchpad, hive, mini-app, and BINI token — all in one place. ## Welcome Binibit is a centralized exchange, an EVM Layer 1 chain (**BiniChain**), an agent-managed DEX (**BaiDEX**), an agent hierarchy (**Agent Hive**), an Agent Token launchpad (**AgentT Launchpad**), a Telegram mini-app (**Bini App**), and a native token (**BINI**) — all sharing one economic model. ```mermaid theme={null} flowchart TB User((USER)) subgraph BC["BiniChain · EVM L1 · BINI native gas"] BaiDEX["BaiDEX
Agent-managed AMM"] Launchpad["AgentT Launchpad
Spawn Agent Tokens"] Hive["Agent Hive
Queens · Scouts · Workers"] end BiniApp["Bini App (TG mini)
Mine CRS · Lessons · Bridges"] Exchange["Binibit Exchange
BINI/USDT · Staking 160%"] Token["BINI Token
1B fixed supply"] Tokenomics["Tokenomics
BINI · wBINI · USBI · CRS"] User --> BiniApp User --> Exchange User --> BaiDEX BiniApp -- bridges --> BaiDEX BaiDEX -- swaps --> Exchange Token -- gas --> BC Tokenomics -.- BC Tokenomics -.- BiniApp Tokenomics -.- Token Launchpad --> Hive classDef chain fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef product fill:#dcfce7,stroke:#16a34a,color:#14532d classDef hub fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef user fill:#fce7f3,stroke:#db2777,color:#831843 class BaiDEX,Launchpad,Hive chain class BiniApp,Exchange,Token product class Tokenomics hub class User user ``` Pick a product to dive into. ## Products Public Spot Market API for the Binibit centralized exchange. CoinGecko-compatible. EVM Layer 1 with BINI as native gas. Agent-managed AMM. Every token has an agent brain. Spawn an Agent Token. The Hive picks it up automatically. Queens, Scouts, Workers — hierarchical agent system. Telegram mini-app: mine, learn, level up, earn. Native token: gas, staking, sinks, rewards. The shared economic model. Start here for full context. REST endpoints for the Spot Market API. ## Quick start Fetch the latest ticker for `ETH_BTC` from the Spot Market API: ```bash theme={null} curl "https://public-api.binibit.com/api/tickers?currencyPairCode=ETH_BTC" ``` ## What's documented All v1 products and reference materials are live. Specific TBD values (chain ID, spawn cost, welcome grant) are clearly marked on the relevant pages. | Product | Status | | -------------------------- | ------------- | | Exchange + Spot Market API | ✅ Live (v1.0) | | BiniChain | ✅ Live (v1.0) | | BaiDEX | ✅ Live (v1.0) | | AgentT Launchpad | ✅ Live (v1.0) | | Agent Hive | ✅ Live (v1.0) | | Bini App | ✅ Live (v1.0) | | BINI Token | ✅ Live (v1.0) | | Tokenomics | ✅ Live (v1.0) | See the [Changelog](/changelog) for the latest updates and the v2.0 trading-API roadmap. ## Highlights * **Public.** Market data has no authentication, no API key. * **REST + JSON.** Standard HTTP, predictable schemas. * **Real-time.** Tickers refresh every few seconds. * **One ecosystem, one economy.** BINI, wBINI, USBI, and CRS share a single model — see [Tokenomics](/tokenomics/ecosystem-overview). * **Rate-limited fairly.** Aggregators and integrators get whitelisted on request. ## Status Live trading interface Source for these docs and other open-source repos # Introduction Source: https://docs.binibit.com/introduction Overview of the Binibit ecosystem and its public APIs. ## What is Binibit? Binibit is a multi-product crypto ecosystem built around a single token (**BINI**) and a shared economic model: | Product | Role | | -------------------- | --------------------------------------------------------------------------------------------------------- | | **Binibit Exchange** | Centralized spot exchange. Hosts BINI/USDT and other pairs. Has staking with referral levels R0–R8. | | **BiniChain** | EVM Layer 1. Native gas = BINI. Hosts BaiDEX, AgentT Launchpad, the Agent Hive, and the bridges. | | **BaiDEX** | Agent-managed Uniswap V3-style AMM on BiniChain. Every Agent Token gets an agent brain managing its pool. | | **AgentT Launchpad** | Spawn an Agent Token in one tap. Worker assigned automatically, Agent Pool listed automatically. | | **Agent Hive** | Hierarchy of agents — Queens (3), Scouts (2), Workers (N). The Swarm = active runtime subset. | | **Bini App** | Telegram mini-app. Users mine **Crystals (CRS)**, level up via **30 lessons**, bridge into BaiDEX. | | **BINI Token** | Native token. Gas, staking, lottery, spawn fees, referrals. Fixed 1B supply, 4-year emission. | ## Where to start | Goal | Page | | --------------------------------- | ----------------------------------------------------------------- | | Build against the Spot Market API | [API Reference](/api-reference/introduction) | | Understand the economic model | [Tokenomics → Ecosystem Overview](/tokenomics/ecosystem-overview) | | Use BiniChain RPC | [BiniChain → Overview](/binichain/overview) | | Trade on BaiDEX | [BaiDEX → Overview](/baidex/overview) | | Spawn an Agent Token | [AgentT Launchpad](/agentt-launchpad/overview) | | Understand the agent hierarchy | [Agent Hive](/agent-hive/overview) | | User the Bini App | [Bini App](/bini-app/overview) | | Buy / hold / stake BINI | [BINI Token](/bini-token/overview) | ## Public APIs | API | Host | Auth | | ---------------------------------- | ------------------------------------------- | ---------------------------- | | **Spot Market API (primary)** | `public-api.binibit.com` | No auth for market data | | **Aggregator-spec namespace** | `internal-api.binibit.com/.../getcoingecko` | No auth | | **BiniChain RPC** | `rpc.binibit.com` | Standard JSON-RPC | | **BiniChain Explorer API** | `scan.binibit.com` | Standard Blockscout | | **BaiDEX / Launchpad / Hive APIs** | See per-tab references | Public + L20+ for governance | ## API stability The Spot Market API is **v1.1**. Breaking changes are announced 30 days in advance via the [Changelog](/changelog) and the GitHub repo. ## Documentation versions | Version | Scope | | ------------------ | ----------------------------------------------------------------------------------------------------------- | | **v1.0** (live) | Full ecosystem: Exchange, BiniChain, BaiDEX, AgentT Launchpad, Agent Hive, Bini App, BINI Token, Tokenomics | | **v1.x** (planned) | Status page, OpenAPI playground per endpoint, additional walkthroughs | | **v2.0** (planned) | Authenticated trading API + WebSocket streams | ## Need higher rate limits? Market makers, aggregators, and high-volume integrators can request elevated rate limits and IP whitelisting. Email [api@binibit.com](mailto:api@binibit.com). ## Related The shared economic model REST endpoints Versioned changes # Supported Assets Source: https://docs.binibit.com/reference/supported-assets Cryptoassets listed on Binibit and their metadata. ## Live list The authoritative list is the [`/api/currencies`](/api-reference/market-data/currencies) endpoint: ```bash theme={null} curl https://public-api.binibit.com/api/currencies | jq ``` ## Snapshot | Symbol | Name | Deposit | Withdraw | | ------ | ----------------------- | ------- | -------- | | AAVE | Aave | ✅ | ✅ | | ARB | Arbitrum | ✅ | ✅ | | ASTER | Aster | ✅ | ✅ | | BINI | Binibit | ✅ | ✅ | | BNB | BNB | ✅ | ✅ | | BTC | Bitcoin | ✅ | ✅ | | CRO | Cronos | ✅ | ✅ | | CRV | Curve DAO | ✅ | ✅ | | DAI | Dai | ✅ | ✅ | | ENA | Ethena | ✅ | ✅ | | ETH | Ethereum | ✅ | ✅ | | FET | Fetch.ai | ✅ | ✅ | | IMX | Immutable | ✅ | ✅ | | LDO | Lido DAO | ✅ | ✅ | | LINK | Chainlink | ✅ | ✅ | | MORPHO | Morpho | ✅ | ✅ | | ONDO | Ondo | ✅ | ✅ | | OKB | OKB | ✅ | ✅ | | PEPE | Pepe | ✅ | ✅ | | POL | Polygon Ecosystem Token | ✅ | ✅ | | SHIB | Shiba Inu | ✅ | ✅ | | SKY | Sky | ✅ | ✅ | | TON | Toncoin | ✅ | ✅ | | TRX | Tron | ✅ | ✅ | | TWT | Trust Wallet Token | ✅ | ✅ | | UNI | Uniswap | ✅ | ✅ | | USDT | Tether | ✅ | ✅ | | WLD | Worldcoin | ✅ | ✅ | | WLFI | World Liberty Financial | ✅ | ✅ | | XAUT | Tether Gold | ✅ | ✅ | | ZRO | LayerZero | ✅ | ✅ | Deposit and withdrawal status can change in real time. Always verify current status before initiating a transfer. ## Listing requests For new asset listings, see the [listings page on binibit.com](https://binibit.com/listings). # ticker_id format Source: https://docs.binibit.com/reference/ticker-id-format Trading pair identifier convention used across the API. ## Format ``` {BASE}_{TARGET} ``` * `BASE` and `TARGET` are uppercase asset symbols (`BTC`, `USDT`, `AAVE`, `TRX` ...) * They are joined by a single underscore `_` * The order matters: **left side is the base asset**, **right side is the target (quote) asset** ## What ticker\_id tells you For any pair `X_Y`: * `last_price = N` means **1 X = N Y** * `base_volume` is denominated in **X** * `target_volume` is denominated in **Y** * Order book `bids[i] = [price, qty]` — `price` is in `Y`, `qty` is in `X` ## Examples | ticker\_id | base | target | Reading | | ----------- | ---- | ------ | -------------------------- | | `BTC_USDT` | BTC | USDT | "Bitcoin priced in Tether" | | `ETH_BTC` | ETH | BTC | "Ether priced in Bitcoin" | | `AAVE_USDT` | AAVE | USDT | "AAVE priced in Tether" | | `TRX_USDT` | TRX | USDT | "Tron priced in Tether" | ## Naming clashes `BTC_USDT` and `USDT_BTC` are **not** the same market — they are different tickers and reflect different conventions for which side is base. Binibit uses the conventional direction (e.g. `BTC_USDT`, not `USDT_BTC`). ## Cross-pairs Pairs that don't have a stablecoin on either side use the same convention: | ticker\_id | Reading | | ---------- | -------------------- | | `ETH_BTC` | 1 ETH priced in BTC | | `BNB_ETH` | 1 BNB priced in ETH | | `LINK_BTC` | 1 LINK priced in BTC | ## Listing live pairs See [Trading Pairs](/reference/trading-pairs) for the live list of supported `ticker_id` values. # Trading Pairs Source: https://docs.binibit.com/reference/trading-pairs List of all active markets on Binibit. ## Live list The authoritative list of active pairs is the [`/tickers`](/api-reference/tickers) endpoint: ```bash theme={null} curl https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers | jq -r '.[].ticker_id' ``` ## Active pairs (snapshot) Below is a snapshot of pairs that were active at the time this page was last updated. For real-time data, use the [`/tickers`](/api-reference/tickers) endpoint or the [Verification](/verification) page. | ticker\_id | base | target | Status | | ----------- | ---- | ------ | ------ | | `AAVE_USDT` | AAVE | USDT | Active | | `BINI_USDT` | BINI | USDT | Active | | `BTC_USDT` | BTC | USDT | Active | | `CRO_USDT` | CRO | USDT | Active | | `ETH_BTC` | ETH | BTC | Active | | `ETH_USDT` | ETH | USDT | Active | | `LINK_USDT` | LINK | USDT | Active | | `OKB_USDT` | OKB | USDT | Active | | `PEPE_USDT` | PEPE | USDT | Active | | `SHIB_USDT` | SHIB | USDT | Active | | `TON_USDT` | TON | USDT | Active | | `TRX_USDT` | TRX | USDT | Active | | `UNI_USDT` | UNI | USDT | Active | | `XAUT_USDT` | XAUT | USDT | Active | This snapshot is informational. Use the live API for the up-to-date list. ## Listing requests To request a new pair listing on Binibit, see the [listings page on binibit.com](https://binibit.com/listings). # Support Source: https://docs.binibit.com/support Get in touch with the Binibit API team. ## General API support [api@binibit.com](mailto:api@binibit.com) Bug reports and documentation suggestions ## For data aggregators If you are integrating Binibit into a data aggregator (CoinGecko, CoinMarketCap, DefiLlama, CryptoCompare, Kaiko, etc.): * Email [api@binibit.com](mailto:api@binibit.com) with subject `[Aggregator: ]` * Include your IP range or CIDR for whitelisting * Mention expected request volume We can provide: * Unlimited or very high rate limits via static IP whitelist * Direct access to the data engineering team * Pre-release notice on schema changes ## Channels by topic | Topic | Channel | | ---------------------------------- | ------------------------------------------------------- | | API bugs / data inconsistencies | [api@binibit.com](mailto:api@binibit.com) | | Rate-limit increase request | [api@binibit.com](mailto:api@binibit.com) | | Aggregator integration | [api@binibit.com](mailto:api@binibit.com) | | Documentation typos / improvements | [GitHub Issues](https://github.com/Binibit/docs/issues) | | Exchange listing requests | [binibit.com/listings](https://binibit.com/listings) | | Account / trading / KYC support | [binibit.com/support](https://binibit.com/support) | ## Response time | Channel | SLA | | -------------------- | -------------------------------------------- | | `api@binibit.com` | Best effort, typically within 1 business day | | Aggregator inquiries | Within 1 business day | | GitHub Issues | Triaged weekly | # Agent Token Sinks Source: https://docs.binibit.com/tokenomics/agent-token-sinks BINI consumed when spawning Agent Tokens, boosting visibility, and trading on Agent Pools. Agent Tokens (AT) created via [AgentT Launchpad](/agentt-launchpad/overview) flow through three BINI-consuming sinks. These sinks scale with Launchpad adoption and add deflationary pressure independent of general BaiDEX activity. ## The three Agent Token sinks | Sink | Mechanism | Burn? | | ----------------------- | ------------------------------------------------- | --------------------------- | | **Spawn cost** | Fixed BINI fee paid at spawn | **Yes** (100% burn) | | **Boost / promotion** | BINI spent to surface a token to Scouts and users | Partial — fee structure TBD | | **Trade burn (BaiDEX)** | 0.25% of every Agent Pool swap is burned | **Yes** (100% burn) | ## Spawn cost When a user spawns an Agent Token via AgentT Launchpad, they pay a **fixed BINI fee** that is **fully burned**. This is the primary entry sink. The exact spawn cost is being finalized by the team. It will be set high enough to deter spam but low enough that genuine creators can spawn. The spawn fee scales with Launchpad usage: ``` Daily BINI burned = (spawns per day) × (spawn cost in BINI) ``` If Launchpad sees 100 spawns/day at a hypothetical 100 BINI/spawn, that's 10,000 BINI/day burned (\~$1,200/day at $0.12 reference) just from the spawn flow. ## Boost / promotion After spawn, creators can **boost** their Agent Token to: * Increase visibility in the AgentT Launchpad explorer * Trigger Scout attention sooner * Get featured on BaiDEX as a highlighted Agent Pool Boost is paid in BINI. The fee is partly burned and partly retained for platform operations — exact split TBD. ## Trade burn (Agent Pool swaps) Every swap on an Agent Pool incurs the standard BaiDEX fee: ``` Agent Pool swap fee: 1.00% (100 BPS) ├── 0.50% LP providers ├── 0.25% Burned ← Agent Token sink (effectively burns wBINI/USBI proportionally) └── 0.25% Referrer ``` The 0.25% burn line burns the **input asset of the swap** (wBINI, USBI, or Agent Token). Only the wBINI portion contributes directly to BINI supply reduction; USBI and Agent Token burns shrink their own circulating supply but don't burn BINI directly. For Agent Pools paired with **wBINI**, the trade burn is a direct BINI sink. For Agent Pools paired with **USBI**, the burn is a USBI sink (and indirectly a downstream BINI sink as USBI is sandbox-bounded). See [BaiDEX Fees](/baidex/overview). ## Why these sinks matter The Launchpad creates a positive feedback loop: ```mermaid theme={null} flowchart LR Spawn["User spawns Agent Token"] --> SpawnBurn["Burns BINI
(spawn cost)"] SpawnBurn --> Auto["Worker assigned
Pool listed"] Auto --> Swaps["Pool generates swaps"] Swaps --> SwapBurn["More BINI burned per swap"] SwapBurn --> Float["Reduces BINI float"] Float --> Price["Raises BINI price
(ceteris paribus)"] Price --> Spawn classDef burn fill:#fef2f2,stroke:#ef4444,color:#7f1d1d classDef neutral fill:#f1f5f9,stroke:#64748b,color:#0f172a class SpawnBurn,SwapBurn burn class Spawn,Auto,Swaps,Float,Price neutral ``` The combination of **per-spawn flat burn** + **per-trade volume-scaled burn** means both quantity and quality of Launchpad adoption translate into deflationary pressure. ## Anti-spam considerations Spam-spawning to farm Worker assignments or game the Hive is mitigated by: 1. **Fixed spawn cost in BINI** — non-trivial to spam 2. **L7+ user gate** to use Bridge B (so spawn-fee BINI must come from earned rewards or open market) 3. **Anti-spam policies on Launchpad** — cooldowns, allowlists, deposit forfeit (TBD) See [AgentT Launchpad](/agentt-launchpad/overview) for the full anti-spam design. ## Related Spawn flow and Agent Token mechanics All eight BINI sinks in the ecosystem 1.00% (50/25/25 BPS) split Workers that manage Agent Pools # Asset Model Source: https://docs.binibit.com/tokenomics/asset-model BINI, wBINI, USBI, and CRS — the four assets in the Binibit ecosystem. The Binibit ecosystem uses **four assets**, each with a distinct role and value type. Understanding which asset is real, which is virtual, and how they convert is the foundation of everything else. ## The four assets | Asset | Type | Real value? | Where used | | ------------------ | ------------------------------ | -------------------------------------- | ------------------------------------------------------------------ | | **BINI** | Native chain token | **Yes** (\$0.12 reference) | Gas on BiniChain, staking on Binibit Exchange, lottery, spawn fees | | **wBINI** | ERC-20 wrap of BINI | Yes (1:1 with BINI) | BaiDEX pools | | **USBI** | ERC-20 stablecoin (testnet \$) | Sandbox (1 USBI = \$1 simulation unit) | BaiDEX pools, USBI bridge entitlement | | **CRS (Crystals)** | Off-chain game points | **No** (virtual) | Bini App: lessons, claims, sinks, bridge to USBI | ## Conversion summary ``` CRS ──── Bridge A (10,000 : 1) ────▶ USBI BINI ──── wrap (1 : 1) ─────────────▶ wBINI BINI ──── Bridge B (1 : 1) ─────────▶ BINI native (BiniChain) ``` ## What each asset is for ### BINI — the real money BINI is the only asset with external market value. Total fixed supply 1,000,000,000. It is the **gas token** on BiniChain, the **trading reference** on Binibit Exchange (BINI/USDT pair), and the **fee currency** for spawn (Launchpad), lottery tickets, and DEX referrer rewards. Public listings: * [Binibit Exchange (BINI/USDT)](https://binibit.com/en/exchange?symbol=BINI_USDT) * [Azbit (BINI/USDT)](https://azbit.com/exchange/BINI_USDT) * [Blynex (BINI/USDT)](https://blynex.com/spot/BINI_USDT) See [BINI Token](/bini-token/overview) for full token mechanics. ### wBINI — BINI for the DEX wBINI is a 1:1 wrapped representation of BINI as an ERC-20, used as the BaiDEX trading asset. Every wBINI is backed by one BINI in the wrap contract. When liquidity providers seed wBINI/USBI or wBINI/Agent Token pools, they deposit wBINI. Wrap and unwrap happen via BaiDEX UI. See [BaiDEX](/baidex/overview). ### USBI — the sandbox stablecoin USBI is an ERC-20 stablecoin **inside the Binibit sandbox economy**. 1 USBI = \$1 simulation unit. USBI is **not** an externally redeemable stablecoin. It does not peg to the US dollar via reserves. It is the unit of liquidity and entitlement inside Binibit during the sandbox phase. Users earn USBI entitlement through XP — see [USBI Formula](/tokenomics/usbi-formula) and [USBI Bridge](/tokenomics/usbi-bridge). ### CRS (Crystals) — the off-chain game currency CRS is the in-app currency of the **Bini App**. Earned by mining (background claim every 4 hours), referrals, lessons, and tasks. Fully off-chain — does not touch BiniChain. Spend CRS on: * Lesson upgrades (boost mining rate) * Bridge A → convert to USBI * Skins, lottery, promotion (Phase 2) CRS spent = XP earned. See [XP Formula](/tokenomics/xp-formula). ## Asset comparison | | BINI | wBINI | USBI | CRS | | --------------------- | ---------------------- | ------ | --------------- | ---------------- | | **Real market value** | Yes | Yes | No | No | | **External listings** | Yes | No | No | No | | **On BiniChain** | Native | ERC-20 | ERC-20 | — | | **In Bini App** | Bridge B reward | — | Bridge A reward | Mining + bridges | | **In BaiDEX pools** | wBINI form | Yes | Yes | — | | **Used for staking** | Yes (Binibit Exchange) | No | No | No | | **Used for gas** | Yes (BiniChain) | No | No | No | ## Related Allocation, emission, vesting, sinks How users accrue USBI from XP Bridge A: CRS → USBI at 10,000:1 Where wBINI and USBI provide liquidity # BINI Bridge (Bridge B) Source: https://docs.binibit.com/tokenomics/bini-bridge Move BINI from off-chain rewards to BINI native on BiniChain at 1:1, gated at Level 7. **Bridge B** converts off-chain BINI (earned via Bini App quests, lottery winnings, or other rewards) into BINI native on BiniChain at a 1:1 ratio. ## Conversion rate ``` 1 BINI off-chain = 1 BINI native ``` Fixed 1:1, no fee on the bridge itself. ## Level gate Bridge B unlocks at **Level 7** (105,000,000 XP). The Level 7 gate is two levels higher than Bridge A (USBI bridge at L5) because BINI is real-value. The extra gating reduces sybil and farm-account risk against the rewards pool. ## How it differs from Bridge A | | Bridge A (USBI) | Bridge B (BINI) | | ------------------- | ---------------------- | ----------------------------------------- | | Source asset | CRS (off-chain points) | BINI (off-chain rewards) | | Target asset | USBI (ERC-20) | BINI native (gas) | | Ratio | 10,000 : 1 | 1 : 1 | | Real value? | Sandbox \$ | Real \$ | | Level gate | 5 | 7 | | Tied to entitlement | Yes (USBI cap) | No (limited by earned BINI) | | Counts as XP? | Yes (CRS spend) | Bridge action itself does not generate XP | ## Once on-chain Native BINI on BiniChain can: * Pay gas for any BiniChain transaction * Wrap into wBINI for [BaiDEX](/baidex/overview) liquidity provision * Be staked on Binibit Exchange (160% APR — see [BINI Token / Staking](/bini-token/overview)) * Pay [Agent Token spawn cost](/agentt-launchpad/overview) on AgentT Launchpad * Buy lottery tickets in the Bini App * Be sent to other addresses ## Anti-sybil The Level 7 gate plus monthly claim caps (subject to product confirmation) bound how much BINI flows out of the rewards pool through Bridge B. The rewards pool itself is bounded by the [BINI emission schedule](/tokenomics/bini-emission) — 600M BINI over 4 years, then zero. ## Sandbox vs Mainnet In the sandbox phase, off-chain BINI represents accrued rewards. Mainnet rules tighten: * Stronger anti-sybil (KYC, IP analysis, behavioral signals) * Possibly different gating logic (e.g. activity-based not just level-based) * Real BINI farming via on-chain staking and LP incentives See [Sandbox vs Mainnet rules](/tokenomics/ecosystem-overview). ## Related Bridge A: CRS → USBI Where bridge-out BINI comes from Where on-chain BINI flows back out Full token mechanics # BINI Emission & Vesting Source: https://docs.binibit.com/tokenomics/bini-emission 1B fixed supply. 60% rewards over 4 years, then zero new emission. BINI is a **fixed-supply** native token. **No mint after genesis.** All 1,000,000,000 BINI exist from day one and are released according to the schedule below. ## Allocation | Pool | BINI | % | Unlock | | --------------------- | ------------: | ---: | -------------------------------- | | **Rewards** | 600,000,000 | 60% | 4-year monthly emission | | **Team & Founders** | 150,000,000 | 15% | 1 year cliff + 3 years linear | | **Marketing** | 100,000,000 | 10% | 5% TGE + milestone-based | | **Ecosystem Reserve** | 100,000,000 | 10% | 6 month cliff + 48 months linear | | **DEX Liquidity** | 50,000,000 | 5% | 100% TGE | | **Total** | 1,000,000,000 | 100% | | ## Rewards emission schedule The 600M Rewards pool releases over 4 years, decaying. After year 4, **no more emission**. | Year | Monthly emission | Annual | Cumulative | | ---- | ---------------: | ----------: | ----------: | | 1 | 17,500,000 | 210,000,000 | 210M | | 2 | 15,000,000 | 180,000,000 | 390M | | 3 | 10,000,000 | 120,000,000 | 510M | | 4 | 7,500,000 | 90,000,000 | 600M | | 5+ | 0 | 0 | 600M (done) | Total Year 1 emission ≈ 21% of total supply. Year 4 is half of Year 1 — the curve is front-loaded to reward early adopters but tapers down to keep year-over-year inflation manageable. ## Where Rewards pool goes The 600M Rewards pool feeds: * **Bini App** — claims, lessons, daily calendar, referrals * **Bridge B** — off-chain BINI rewards becoming on-chain * **Agent Hive** — Worker incentives, action-log gas reimbursement * **Lottery** — jackpots * **DEX LP incentives** — wBINI side seeding new pools The exact split between these is a per-month policy decision logged on-chain. ## Vesting curves ### Team & Founders (15% / 150M) ``` Cliff: 12 months from TGE (no unlock) Vesting: 36 months linear after cliff End: Month 48 ``` Designed to align team with long-term ecosystem health, not short-term price. ### Marketing (10% / 100M) ``` TGE: 5% unlocked at TGE (5,000,000 BINI) Milestones: Remaining 95M tied to listings, partnerships, growth KPIs ``` Marketing unlocks are **milestone-driven**, not time-driven. The team controls the trigger but each unlock is announced in advance. ### Ecosystem Reserve (10% / 100M) ``` Cliff: 6 months from TGE Vesting: 48 months linear after cliff End: Month 54 ``` Funds future grants, bounties, partnerships, and unforeseen ecosystem needs. ### DEX Liquidity (5% / 50M) ``` TGE: 100% unlocked ``` Used as the wBINI side of initial BaiDEX pools. The 50M cap × $0.12 reference price = $6M ceiling on wBINI-side pool TVL — see [wBINI Cap Rule](/tokenomics/wbini-cap). ## What this means in practice * **No surprise dilution.** All future emission is on the schedule above. * **Long team alignment.** Team has 1 year cliff before any unlock. * **Marketing can scale with traction.** Milestone-based marketing keeps unlocks tied to outcomes. * **Hard ceiling.** After year 4, total circulating supply is capped at 1B. ## Year-over-year inflation | Year | Year-start supply | Year-end supply | Inflation | | ---- | ---------------------------------------: | ------------------------------------------: | --------: | | 1 | varies (depends on Marketing milestones) | + 210M Rewards + Team/Eco/Marketing unlocks | High | | 2 | + 180M Rewards | | Moderate | | 3 | + 120M Rewards | | Low | | 4 | + 90M Rewards | All emission complete | Low | | 5+ | No new BINI | | 0% | Year-1 inflation is the most aggressive — Year-1 holders take the brunt. After Year-4 the ecosystem is fully diluted and BINI is a true fixed-supply asset. ## Related Where BINI flows back out (burns, fees, etc.) Allocation, utility, where to buy 50M DEX liquidity → \$240M implied MC ceiling Off-chain BINI rewards → on-chain # BINI Sinks Source: https://docs.binibit.com/tokenomics/bini-sinks Eight mechanisms that remove BINI from circulation or lock it long-term. The Binibit ecosystem has **eight BINI sinks** that consume, burn, or lock BINI. Combined with the [fixed 4-year emission schedule](/tokenomics/bini-emission), they keep the long-term supply curve sustainable. ## The eight sinks | # | Sink | Mechanism | Permanent? | | - | --------------- | --------------------------------------------------------------------------------------- | ------------- | | 1 | Gas | BiniChain transactions burn BINI as gas (or pay validators, depending on chain config) | Yes / partial | | 2 | Staking | BINI locked in staking packages on Binibit Exchange (160% APR, 30/90/180/360-day tiers) | Locked | | 3 | DEX trade burn | 0.25% of every BaiDEX swap is burned permanently | **Yes** | | 4 | Lottery burn | 20% of every BINI lottery ticket is burned permanently | **Yes** | | 5 | Spawn fee | Agent Token spawn cost is paid in BINI and burned | **Yes** | | 6 | Premium / boost | Token visibility boosts on AgentT Launchpad consume BINI | Yes / partial | | 7 | Bridge gas | Bridges A and B execute on BiniChain → consume BINI gas | Yes / partial | | 8 | LP locking | wBINI side of BaiDEX pools is locked while LP position is open | Locked | ## Permanent burns Three sinks are explicitly permanent — BINI is sent to a burn address with no recovery: ``` BaiDEX swap burn: 0.25% × swap volume Lottery burn: 20% × ticket revenue Spawn fee burn: 100% × spawn cost (per Agent Token) ``` These three together create the deflationary pressure that offsets the emission schedule. ## BaiDEX swap burn (sink #3) Every swap on BaiDEX charges a **1.00% total fee**, split: ``` Total fee: 1.00% (100 BPS) ├── 0.50% LP providers (50 BPS) ├── 0.25% Burned (25 BPS) — permanent burn └── 0.25% Referrer (25 BPS) — or treasury if no referrer ``` The 0.25% burn applies to **every swap**, regardless of pool type or token traded. As DEX volume grows, burn rate scales linearly with volume. See [BaiDEX → Fees](/baidex/overview). ## Lottery burn (sink #4) The Bini App lottery distributes ticket revenue: ``` Ticket bought with BINI: ├── 60% Jackpot (winners) ├── 20% Burned permanently ├── 10% Referral commissions └── 10% Platform operations ``` Lottery launches in Phase 2 of the Bini App rollout. See [Bini App / Lottery](/bini-app/overview). ## Spawn fee burn (sink #5) Every Agent Token spawned via AgentT Launchpad pays a **fixed BINI fee**, fully burned. The exact spawn cost is being finalized by the team. This sink scales with Launchpad adoption — more Agent Tokens spawned means more BINI burned. See [AgentT Launchpad](/agentt-launchpad/overview). ## Locked vs burned | Type | What happens to BINI | | ---------- | ---------------------------------------------------------------------------------------------- | | **Burned** | Sent to burn address. Gone forever. Reduces circulating supply permanently. | | **Locked** | Held in a contract (staking, LP). Cannot trade or move. Returns to circulation when withdrawn. | Locked BINI reduces effective float (sell pressure) but does not reduce total supply. Burned BINI does both. ## Long-term supply trajectory Combining emission and sinks: ``` Year 1-4: +210M, +180M, +120M, +90M (emission) Year 1-∞: -X% per year (cumulative burns) Year 5+: 0 emission, only burns ``` After year 4, the supply curve is **monotonically decreasing**. The exact rate depends on DEX volume, lottery activity, and Launchpad spawn count — all of which scale with usage. ## Anti-farming protections Sinks pair with [Bridge B Level 7 gate](/tokenomics/bini-bridge) and monthly claim caps to prevent over-extraction from the rewards pool. The combination — **gated source + multiple sinks** — is what makes the long-term economy work. ## Related The supply side: 4-year emission schedule Where the 0.25% burn comes from Where the 20% lottery burn comes from Spawn cost and boost fees # Ecosystem Overview Source: https://docs.binibit.com/tokenomics/ecosystem-overview How the Binibit products connect: token flows, bridges, agents. This is the central hub of the Binibit ecosystem documentation. Each product page links back here for the full economic context. Each section connects to the relevant product page. See the cards below for the full Tokenomics index. ## What you are looking at Binibit is **a centralized exchange + an L1 chain + a DEX + an agent layer + a Telegram mini-app**, sharing one economic model. ```mermaid theme={null} flowchart TB subgraph BC["BiniChain — EVM L1 · BINI native gas"] direction TB BaiDEX["BaiDEX
V3 AMM + agents

Pools: wBINI/USBI/AT"] Launchpad["AgentT Launchpad
Spawn Agent Token
Worker created
Pool auto-listed"] Hive["Agent Hive
Queens (3)
Scouts (2)
Workers (N)
Swarm (live)"] wBINI["wBINI
(1:1 from BINI native)"] USBI["USBI
(ERC-20)"] BINInative["BINI native
(gas)"] Launchpad -- spawns --> BaiDEX Launchpad -- assigns Worker --> Hive wBINI -- LP side --> BaiDEX USBI -- LP side --> BaiDEX end CRS["Crystals (CRS)
off-chain"] BINIoff["BINI off-chain
quest rewards"] BiniApp["Bini App (TG mini)
30 levels · 30 lessons
mine CRS · referrals
lottery · franchise"] CEX["Exchanges

Binibit · Azbit · Blynex

Staking 160% APR · R0-R8"] User((USER)) CRS -- "Bridge A · 10,000:1" --> USBI BINIoff -- "Bridge B · 1:1" --> BINInative BiniApp --> CRS BiniApp --> BINIoff User -- earns CRS --> BiniApp User -- trade / withdraw --> CEX CEX -- BINI --> BINInative classDef chain fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef asset fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef product fill:#dcfce7,stroke:#16a34a,color:#14532d classDef user fill:#fce7f3,stroke:#db2777,color:#831843 class BaiDEX,Launchpad,Hive,wBINI,USBI,BINInative chain class CRS,BINIoff asset class BiniApp,CEX product class User user ``` ## Assets | Asset | Type | Value | | ------------------ | ------------------------------ | --------------------------------------- | | **BINI** | Native chain token | Real, \$0.12 reference, 1B fixed supply | | **wBINI** | ERC-20 wrap of BINI | 1:1 with BINI, used in BaiDEX pools | | **USBI** | ERC-20 stablecoin (testnet \$) | 1 USBI = \$1 simulation unit | | **CRS (Crystals)** | Off-chain game points | Virtual, earned in Bini App | ## Bridges * **Bridge A** — Crystals (CRS) ↔ USBI at **10,000 : 1**, Level 5 gate * **Bridge B** — BINI off-chain ↔ BINI native at **1 : 1**, Level 7 gate ## Fee structure (BaiDEX) ``` Total swap fee: 1.00% (100 BPS) ├── 0.50% LP providers (50 BPS) ├── 0.25% Burned (25 BPS) — deflationary └── 0.25% Referrer (25 BPS) — or treasury if none ``` ## Lottery split (Bini App, Phase 2) ``` Ticket purchased with BINI: ├── 60% Jackpot (winners) ├── 20% Burned permanently ├── 10% Referral commissions └── 10% Platform operations ``` ## What will be documented * Asset model details * User levels & XP curve (30 levels) * XP formula (CRS spent = XP) * USBI formula (`floor(XP / 10,000)`, cap 100,000) * Lessons (cost & bonus formulas) * USBI bridge (Bridge A) details * BINI bridge (Bridge B) details * BINI emission & vesting * BINI sinks (8 mechanisms) * wBINI cap rule * Agent Token sinks * Staking & referral economics * Simulation & cohort projections * Glossary ## Related Where users earn CRS and unlock USBI/BINI Allocation, emission, staking Trading: pools, fees, agents The hierarchy that runs the DEX agent layer # Glossary Source: https://docs.binibit.com/tokenomics/glossary Every term in the Binibit ecosystem, in alphabetical order. ## A ### Active referral A referred user who has been active within the recent reward window. Used in the Bini App referral CRS calculation. ### Agent Hive The full registry of all agents and all pools. The system that runs the [agent layer](/agent-hive/overview) on top of BaiDEX. ### Agent Pool A V3 pool on [BaiDEX](/baidex/overview) where an Agent Token trades. Auto-created when the Agent Token is spawned. ### Agent Queen Strategic-layer agent role. 3 Queens coordinate ecosystem-wide signals, cross-pool liquidity, and risk control. Override Scouts and Workers. ### Agent Scout Tactical-layer agent role. 2 Scouts perform token analysis, risk scoring, rug detection, and signal generation. Override Workers. ### Agent Swarm The active runtime subset of [Agent Hive](#agent-hive) — the Workers currently deployed and processing in the field. Swarm ⊆ Hive. ### Agent Token (AT) ERC-20 token spawned via [AgentT Launchpad](/agentt-launchpad/overview). Each AT gets an [Agent Worker](#agent-worker) and an [Agent Pool](#agent-pool) automatically. ### Agent Worker Execution-layer agent role. One Worker per Agent Token. Manages the Agent Pool's liquidity, monitors trades, distributes incentives. ### AgentT Launchpad User-facing product where users [spawn](#spawn) Agent Tokens. See [AgentT Launchpad / Overview](/agentt-launchpad/overview). ### AMM Automated Market Maker. The class of DEX that uses liquidity pools instead of an order book. BaiDEX is a Uniswap V3-compatible AMM. ## B ### BaiDEX The agent-managed DEX on BiniChain. Uniswap V3 AMM with custom fee router (1.00% = 50/25/25 BPS) and an agent layer managing every Agent Pool. See [BaiDEX](/baidex/overview). ### BiniChain EVM Layer 1 chain hosting BaiDEX, AgentT Launchpad, and the Agent Hive. BINI is its native gas token. See [BiniChain](/binichain/overview). ### BINI Native token of the Binibit ecosystem. 1B fixed supply. Real market value (\$0.12 reference). Gas on BiniChain, staking on Binibit Exchange. See [BINI Token](/bini-token/overview). ### Bini App Telegram mini-app where users mine [Crystals](#crs), level up via [lessons](#lessons), and bridge into BaiDEX. 30 levels, 30 lessons. See [Bini App](/bini-app/overview). ### Bonus BINI The portion of staking rewards subject to additional vesting / reduced liquidity. Contrasts with [Spot BINI](#spot-bini). ### Bridge A The bridge that converts off-chain Crystals (CRS) into ERC-20 USBI on BiniChain. Ratio: **10,000 CRS = 1 USBI**. Level 5 gate. See [USBI Bridge](/tokenomics/usbi-bridge). ### Bridge B The bridge that converts off-chain BINI rewards into native BINI on BiniChain. Ratio: **1:1**. Level 7 gate. See [BINI Bridge](/tokenomics/bini-bridge). ## C ### Claim The Bini App action to harvest accumulated mined Crystals. Once every 4 hours. Base reward 40,000 CRS plus lesson bonuses. ### Claim window The 4-hour cycle between consecutive claims. Mining accumulates during the window; the user must claim to capture it. ### CRS (Crystals) Off-chain game points earned in the Bini App. Virtual — no external value. Spent on lessons, USBI bridge, skins, etc. CRS spent = XP earned. ## D ### DEX Decentralized exchange. In the Binibit ecosystem, this is [BaiDEX](#baidex). ### Daily calendar A 30-day rotating CRS reward calendar. Claiming consecutive days yields bonuses. ## E ### Emission schedule The 4-year monthly BINI release from the Rewards pool. Year 1: 17.5M/month; Year 4: 7.5M/month; Year 5+: 0. See [BINI Emission](/tokenomics/bini-emission). ### Entitlement The maximum USBI a user is allowed to claim or bridge. Derived from XP via `floor(XP / 10K) + 1,000` welcome grant. See [USBI Formula](/tokenomics/usbi-formula). ### EVM Ethereum Virtual Machine. Smart contract execution environment used by Ethereum and EVM-compatible chains like BiniChain. ## F ### Fee router The custom contract on BaiDEX that splits the 1.00% swap fee into 0.50% LP / 0.25% burn / 0.25% referrer. ### Franchise Bini App user status tied to cumulative CRS engagement. Tiers: Member → Builder → Manager → Director → Partner. ## G ### Gas The transaction fee paid in BINI to execute a transaction on BiniChain. ### Genesis Bini App Level 30 — the maximum level. Total USBI entitlement: 101,000. ## H ### Hive principle The architectural pattern of the [Agent Hive](#agent-hive): hierarchical roles (Queens/Scouts/Workers) with automatic coordination, modeled after biological hives. ## L ### Lesson A Bini App upgrade card. Spending CRS on a lesson level increases the per-hour CRS mining bonus. 30 lessons × 10 levels = 300 upgrades. See [Lessons](/tokenomics/lessons). ### Level 1 of 30 user tiers in the Bini App. Each level requires a cumulative XP threshold and unlocks higher USBI entitlement. Level 30 = Genesis. See [User Levels](/tokenomics/user-levels). ### LP Liquidity Provider. A user who deposits both sides of a BaiDEX pool to earn the 0.50% LP fee on swaps. ### Lottery Bini App game mechanic. Tickets bought in BINI. Ticket revenue split: 60% jackpot / 20% burn / 10% referral / 10% platform. ## M ### Mainnet The production deployment of BiniChain (and the wider ecosystem) following the sandbox/testnet phase. ### Mining The continuous accrual of CRS in the Bini App. Base rate 10,000 CRS/hour, plus lesson bonuses. ## R ### Referral A user invited via referral link. The Bini App has a 3-level referral system on CRS mining (20% / 10% / 5%). Binibit Exchange has a 9-level referral system (R0–R8) on staking rewards. ### Rewards pool The 600M BINI allocation reserved for ecosystem rewards. Released over 4 years per the emission schedule. ### RPC Remote Procedure Call. The endpoint at `rpc.binibit.com` for BiniChain JSON-RPC traffic. ## S ### Sandbox The current pre-mainnet phase where USBI is a sandbox stablecoin and Hive runs in non-audited mode. See [Sandbox vs Mainnet rules](/tokenomics/ecosystem-overview). ### Sink A mechanism that consumes BINI from circulation. Eight sinks total — see [BINI Sinks](/tokenomics/bini-sinks). ### Spawn The user action to create a new Agent Token via [AgentT Launchpad](/agentt-launchpad/overview). Pays a BINI fee, triggers Worker assignment, lists an Agent Pool on BaiDEX. ### Spot BINI The portion of staking rewards immediately tradable. Contrasts with [Bonus BINI](#bonus-bini). ### Staking Locking BINI on Binibit Exchange for 30 / 90 / 180 / 360 days at 160% APR. See [Staking](/tokenomics/staking). ### Swarm See [Agent Swarm](#agent-swarm). ### Swap A trade on BaiDEX that exchanges one asset for another via an [AMM](#amm) pool. ## T ### TGE Token Generation Event. The day BINI was first issued. ### Ticker A trading pair identifier in `{base}_{target}` format. Example: `BTC_USDT`. ### Trust score A CoinGecko-style metric assessing exchange data quality. Influenced by API coverage, uptime, listed pair quality. ## U ### USBI Sandbox stablecoin (ERC-20) on BiniChain. 1 USBI = \$1 simulation unit. Not externally redeemable. Earned via Bridge A from CRS, used as LP side in BaiDEX pools. ## V ### Vesting Time-based release of allocated BINI. Team: 1 year cliff + 3 years linear. Ecosystem Reserve: 6 month cliff + 48 months linear. See [BINI Emission](/tokenomics/bini-emission). ## W ### wBINI Wrapped BINI as ERC-20. 1:1 backed. Used in BaiDEX pools. ### Welcome grant The initial USBI given to every new Bini App user. The welcome grant amount is being finalized. Two values are in flight: 1,000 USBI (canonical economy v3.1) versus 5 USBI + 0.1 BINI (production simulation v3.0). See [USBI Formula](/tokenomics/usbi-formula). ## X ### XP Experience Points. The single progression metric for user levels and USBI entitlement. **1 CRS spent = 1 XP earned**. Capped at 1B for level system. See [XP Formula](/tokenomics/xp-formula). ## Related Start here for ecosystem context BINI, wBINI, USBI, CRS deep dive # Lessons Source: https://docs.binibit.com/tokenomics/lessons 30 lessons × 10 levels = 300 upgrade actions. Cost and bonus formulas. Lessons are the **income engine** of the Bini App. Each lesson upgrade increases your CRS-per-hour mining rate. ## Structure ``` 30 lessons × 10 levels = 300 upgrade actions ``` Maxing all 30 lessons to L10 costs exactly **230,000,000 CRS** and brings you to **Level 10 / 24,000 USBI** (including welcome grant). Maxing all lessons does **not** max your user profile — see [User Levels](/tokenomics/user-levels) for the full XP curve. ## Cost formula ``` lesson_upgrade_cost = baseCost × 1.217595 × 2^(lessonLevel - 1) ``` `baseCost` is per-lesson and varies. `1.217595` is the global multiplier chosen so the sum of all 300 upgrades equals 230M CRS exactly. ## Bonus formula ``` lesson_bonus_per_hour = baseBonus × lessonLevel ``` Each level of a lesson adds `baseBonus` CRS/hour. So a lesson at L10 produces 10× the per-hour bonus of the same lesson at L1. Total mining rate at all-lessons-L10 = **184,650 CRS/hour bonus** on top of the base 10,000 CRS/hour. ## Aggregate milestones | Lesson milestone | Cumulative CRS cost | Total bonus/hour | Reward per 4h claim | 2 claims/day | Total USBI (incl. welcome) | | ---------------- | ------------------: | ---------------: | ------------------: | -----------: | -------------------------: | | All lessons L1 | 224,829 | 18,465 | 113,860 | 227,720 | 1,022 | | All lessons L3 | 1,573,803 | 55,395 | 261,580 | 523,160 | 1,157 | | All lessons L5 | 6,969,697 | 92,325 | 409,300 | 818,600 | 1,696 | | All lessons L7 | 28,553,275 | 129,255 | 557,020 | 1,114,040 | 3,855 | | All lessons L10 | 230,000,000 | 184,650 | 778,600 | 1,557,200 | 24,000 | ## How to read the table * **Cumulative CRS cost** — total CRS spent to reach this state from L1 * **Total bonus/hour** — extra CRS/hour from all lessons combined (added to base 10K/hour) * **Reward per 4h claim** — `4 × (10,000 + bonus_per_hour)` — what one full claim returns * **2 claims/day** — total daily mining if you claim twice * **Total USBI** — your entitlement (welcome grant + `floor(XP/10K)`) ## Validation | Check | Value | How | | ---------------------- | ----------: | -------------------------- | | Lesson cost multiplier | 1.217595 | `230M / (184,650 × 1,023)` | | All-lessons-L10 cost | 230,000,000 | Target = 230M CRS | | Max lesson bonus/hour | 184,650 | `18,465 × 10` | | Max 4h claim | 778,600 | `4 × (10,000 + 184,650)` | ## Related 1 CRS spent on lesson = 1 XP XP → USBI entitlement All-lessons-L10 puts you at L10 The 30 lessons in the app # Simulation & Cohort Projections Source: https://docs.binibit.com/tokenomics/simulation Day-to-Level-30 scenarios, USBI supply growth, and DEX TVL projections. The economy model has been simulated under multiple scenarios. This page shows the key outputs. ## Single-user progression scenarios Solo users with no skin/lottery spend, varying claim cadence and referral count: | Scenario | Active refs | Referral CRS/day | Lessons max day | Level 30 day | Level @ d120 | XP @ d120 | USBI @ d120 | | ------------------------------- | ----------: | ---------------: | --------------: | -----------: | -----------: | --------: | ----------: | | Solo 2 claims/day | 0 | 0 | 109 | 352 | 11 | 289.82M | 29,981 | | Solo 3 claims/day | 0 | 0 | 91 | 292 | 13 | 348.56M | 35,856 | | 2 claims + 50 invited | 10 | 160,000 | 99 | 329 | 12 | 315.49M | 32,549 | | 2 claims + 100 invited | 20 | 320,000 | 90 | 316 | 13 | 339.96M | 34,996 | | 2 claims + 500 invited (capped) | 100 | 500,000 | 88 | 297 | 14 | 367.37M | 37,736 | The 500K CRS/day referral cap (kicks in at \~250 active referrals at the 20% active-rate assumption) prevents runaway farming. ## Checkpoint snapshots Detailed state at day boundaries for the 2-claim and 3-claim scenarios: ### 2 claims/day | Day | Level | Lesson upgrades | XP | Bonus/hour | Mining/day (excl. calendar) | Total USBI | | --- | ----: | --------------: | ------: | ---------: | --------------------------: | ---------: | | 30 | 5 | 199 | 50.38M | 42,850 | 422,800 | 6,038 | | 60 | 7 | 258 | 116.64M | 101,350 | 890,800 | 12,663 | | 90 | 9 | 289 | 185.77M | 157,550 | 1,340,400 | 19,576 | | 120 | 11 | 300 | 289.82M | 184,650 | 1,557,200 | 29,981 | | 180 | 17 | 300 | 480.31M | 184,650 | 1,557,200 | 49,030 | | 240 | 21 | 300 | 670.79M | 184,650 | 1,557,200 | 68,079 | | 300 | 26 | 300 | 861.28M | 184,650 | 1,557,200 | 87,127 | | 360 | 30 | 300 | 1.05B | 184,650 | 1,557,200 | 101,000 | ### 3 claims/day | Day | Level | Lesson upgrades | XP | Bonus/hour | Mining/day | Total USBI | | --- | ----: | --------------: | ------: | ---------: | ---------: | ---------: | | 30 | 5 | 206 | 54.66M | 47,650 | 691,800 | 6,465 | | 60 | 7 | 259 | 121.00M | 102,750 | 1,353,000 | 13,100 | | 90 | 9 | 299 | 214.41M | 182,150 | 2,305,800 | 22,441 | | 120 | 13 | 300 | 348.56M | 184,650 | 2,335,800 | 35,856 | | 180 | 19 | 300 | 585.76M | 184,650 | 2,335,800 | 59,576 | | 240 | 25 | 300 | 822.97M | 184,650 | 2,335,800 | 83,296 | | 300 | 30 | 300 | 1.06B | 184,650 | 2,335,800 | 101,000 | | 360 | 30 | 300 | 1.30B | 184,650 | 2,335,800 | 101,000 | By day 300 the 3-claim user has hit the maximum (Level 30, 101K USBI). XP continues accruing past the 1B cap but no longer affects level or entitlement. ## Cohort USBI supply Total virtual USBI supply by user count and stage: | Users | At launch | Lessons maxed (L10) | Level 20 | Level 30 | | ------ | ---------: | ------------------: | ------------: | ------------: | | 500 | 500,000 | 12,000,000 | 30,500,000 | 50,500,000 | | 1,000 | 1,000,000 | 24,000,000 | 61,000,000 | 101,000,000 | | 10,000 | 10,000,000 | 240,000,000 | 610,000,000 | 1,010,000,000 | | 50,000 | 50,000,000 | 1,200,000,000 | 3,050,000,000 | 5,050,000,000 | These are virtual-supply ceilings, not hard mints. Actual circulating USBI depends on user behavior (claim, bridge, hold). ## DEX liquidity simulation Assuming **10% of USBI** flows to LP and the LP-to-MC ratio is 5%: | Users | Stage | Total USBI | 10% LP USBI | Matched wBINI | Pool TVL | Implied MC | | ------ | ------------: | ------------: | ----------: | ------------: | ----------: | ------------: | | 500 | At launch | 500,000 | 50,000 | 416,667 | 100,000 | 2,000,000 | | 500 | Lessons maxed | 12,000,000 | 1,200,000 | 10,000,000 | 2,400,000 | 48,000,000 | | 1,000 | At launch | 1,000,000 | 100,000 | 833,333 | 200,000 | 4,000,000 | | 1,000 | Lessons maxed | 24,000,000 | 2,400,000 | 20,000,000 | 4,800,000 | 96,000,000 | | 10,000 | At launch | 10,000,000 | 1,000,000 | 8,333,333 | 2,000,000 | 40,000,000 | | 10,000 | Lessons maxed | 240,000,000 | 24,000,000 | 200,000,000 | 48,000,000 | 960,000,000 | | 50,000 | Lessons maxed | 1,200,000,000 | 120,000,000 | 1,000,000,000 | 240,000,000 | 4,800,000,000 | At 10K users with all lessons maxed, the implied MC of $960M is already approaching the [wBINI cap](/tokenomics/wbini-cap) ceiling of $240M. This is why the design pushes most activity into [USBI/Agent Token pools](/baidex/overview), where the wBINI cap doesn't apply. ## Interpretation * **Solo 2-claim users reach Level 30 around day 352.** Acceptable but slow — this is the lower bound for casual users. * **Solo 3-claim users reach Level 30 around day 292.** Reasonable for engaged users. * **Referrals shave \~50–60 days off the path to Level 30**, but the 500K CRS/day cap caps that benefit. Spam-inviting beyond \~250 active refs adds nothing. * **At 10K users, virtual USBI hits \$1B.** Liquidity must distribute across many pools — the wBINI/USBI anchor pool alone cannot absorb it. ## Related XP curve and stage table Cost/bonus formulas behind these numbers floor(XP / 10K), capped at 100K Why pools must distribute # Staking & Referral Economics Source: https://docs.binibit.com/tokenomics/staking 160% APR packages on Binibit Exchange + nine-level referral system R0–R8. BINI holders can stake on **Binibit Exchange** to earn yield while building a multi-level referral team. The combination is a primary BINI sink (locks BINI long-term) and a primary user-acquisition flywheel. ## Staking packages Available at [binibit.com/en/staking](https://binibit.com/en/staking). | Tier | Duration | APR | Notes | | ------ | -------- | ---: | ------------------------------------- | | Tier 1 | 30 days | 160% | Shortest lock, lowest amount required | | Tier 2 | 90 days | 160% | | | Tier 3 | 180 days | 160% | | | Tier 4 | 360 days | 160% | Longest lock | The 160% APR is **base rate**. Bonus / Spot split varies by duration — longer locks return a higher proportion of Spot BINI (immediately tradable) versus Bonus BINI (subject to additional conditions). Daily accrual. Withdrawal at maturity. ## Referral levels — R0 to R8 Stakers automatically participate in a **9-level referral system** (R0 through R8). Your level depends on: * Your own staked BINI (in USDT-equivalent at current price) * Number of qualifying direct referrals * Cumulative team volume (sum of team's staked BINI) Higher levels unlock larger commission percentages on team staking rewards. | Level | Self-stake | Direct referrals | Team volume | Commission rate | | ----- | ---------------- | ---------------- | ----------- | --------------- | | R0 | Any active stake | 0 | 0 | Base | | R1 | Threshold | + | + | + | | R2 | Threshold | + | + | + | | R3 | Threshold | + | + | + | | R4 | Threshold | + | + | + | | R5 | Threshold | + | + | + | | R6 | Threshold | + | + | + | | R7 | Threshold | + | + | + | | R8 | Threshold | + | + | Maximum | Exact thresholds and percentages: see [binibit.com/en/staking](https://binibit.com/en/staking). They are the canonical source — this docs page is a roadmap, not a quote. ## Level-difference formula When a downline earns staking rewards, your commission depends on the **level difference** between you and the downline: ``` Same or higher level than you: base commission (e.g. 15%) Lower level than you: higher commission per level gap ``` This rewards being one or more tiers above your direct team. The exact base rate and per-tier increment are defined on the staking conditions page. ## Dynamic level threshold Staking thresholds are set in **USDT terms**, not BINI terms. As BINI price moves, the BINI required to maintain a given level moves inversely: ``` required_bini = required_usdt / current_bini_price ``` If BINI rises, you need less BINI to maintain your level. If BINI falls, you need more. This protects the level system against price volatility. ## Why these mechanics matter (tokenomics view) | Mechanic | BINI tokenomics impact | | ---------------------------- | ----------------------------------------------------------------------------------------------- | | Locked staking principal | Reduces effective float during stake duration (sink #2 in [BINI Sinks](/tokenomics/bini-sinks)) | | 160% APR rewards | Paid from the Rewards pool emission — see [BINI Emission](/tokenomics/bini-emission) | | Bonus BINI proportion | Often subject to vesting / reduced liquidity, lowers immediate sell pressure | | Multi-level referrals | User acquisition without paid marketing spend | | USDT-pegged level thresholds | Stable level meaning even with BINI price volatility | ## Related Staking is sink #2 — locked BINI Where staking rewards come from Token utility, where to buy Canonical staking conditions # USBI Bridge (Bridge A) Source: https://docs.binibit.com/tokenomics/usbi-bridge Convert Crystals (CRS) to USBI at 10,000 : 1, gated at Level 5. **Bridge A** converts off-chain Crystals (CRS) into on-chain USBI on BiniChain. ## Conversion rate ``` 10,000 CRS = 1 USBI ``` Fixed rate. No oracle, no slippage, no fee on the bridge itself. ## Level gate Bridge A unlocks at **Level 5** (50,000,000 XP). Below Level 5, users earn USBI entitlement but cannot bridge it on-chain. This gate exists to ensure users have engaged with the app before flowing into BaiDEX, reducing thin-account spam. ## How it interacts with USBI entitlement The bridge consumes: * The user's [USBI entitlement headroom](/tokenomics/usbi-formula) * The CRS being burned Bridging does **not** create new USBI entitlement on its own — but the CRS spent during the bridge **does** count as XP, which raises your entitlement. So bridging is itself slightly self-funding. Walk-through: 1. User has 10,000,000 CRS spent on lessons → 10,000,000 XP → 1,000 USBI entitlement 2. User wants to bridge 5,000,000 CRS into 500 USBI 3. Bridge action burns 5,000,000 CRS, mints 500 USBI on BiniChain 4. CRS spent during bridge counts as XP → total XP becomes 15,000,000 → entitlement becomes 1,500 USBI 5. User now has 500 USBI on-chain and 1,000 USBI of remaining entitlement ## Cap USBI bridged on-chain is bounded by total USBI entitlement (welcome grant + XP-derived). A user cannot bridge more USBI than they are entitled to. ## Gas The user pays BiniChain gas in **BINI** to execute the bridge transaction. See [BINI Bridge](/tokenomics/bini-bridge) for getting BINI native if needed. ## Sandbox vs Mainnet USBI is a sandbox stablecoin — it is not externally redeemable. Bridge A operates inside the sandbox/testnet phase. The mainnet evolution of USBI (or its replacement) is on the roadmap. See [BINI Token / Roadmap](/bini-token/overview). ## Formula in code ```javascript theme={null} const RATIO = 10_000; function usbiFromCrs(crsBurned) { return Math.floor(crsBurned / RATIO); } function crsRequiredFor(usbiTarget) { return usbiTarget * RATIO; } ``` ## Related The entitlement headroom Bridge B: BINI off → BINI native User-facing bridge UI Where USBI provides liquidity # USBI Formula Source: https://docs.binibit.com/tokenomics/usbi-formula USBI entitlement = floor(XP / 10,000), plus a 1,000 USBI welcome grant. USBI entitlement is the amount of USBI a user is allowed to claim or bridge into BaiDEX. It is **derived from total XP**, not granted per action. ## Core formula ``` usbi_entitlement = floor(total_xp / 10,000) total_usbi_available = 1,000 + usbi_entitlement claimable_usbi = total_usbi_available - already_claimed_usbi ``` ```mermaid theme={null} flowchart LR CRS[CRS spent] --> XP[XP +1 per CRS] XP -- "÷ 10,000
(floor, capped at 100K)" --> Entitlement[USBI entitlement] Welcome[Welcome grant
1,000 USBI] --> Total[Total USBI
available] Entitlement --> Total Already[Already claimed] -. "subtracted from" .-> Claimable Total --> Claimable[Claimable USBI
can bridge / use on DEX] classDef input fill:#fef9c3,stroke:#ca8a04,color:#713f12 classDef calc fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef output fill:#dcfce7,stroke:#16a34a,color:#14532d class CRS,Welcome,Already input class XP,Entitlement,Total calc class Claimable output ``` ## Caps ``` max_xp = 1,000,000,000 max_usbi_entitlement = 100,000 welcome_grant = 1,000 max_total_usbi_per_user = 101,000 ``` A Level 30 user with 1B XP has 100,000 USBI of entitlement plus the 1,000 USBI welcome grant = **101,000 USBI maximum** lifetime. ## What entitlement means Entitlement is a **soft ceiling**. You can: * Claim USBI on demand from your entitlement pool (subject to cooldown if applicable) * Bridge USBI into BaiDEX as LP * Hold USBI in your wallet You cannot exceed entitlement at any time. If you spend USBI on the DEX and your entitlement grows later, the new headroom unlocks fresh claimable USBI. ## Why this design * **Bound the sandbox supply.** USBI is virtual. A formula tied to XP keeps total supply predictable and prevents free minting. * **Reward engagement.** USBI grows with CRS spend, not with hoarding. * **Make every level meaningful.** Every level boundary unlocks measurably more USBI capacity. ## Cohort supply projection Per-user maximum is 101,000 USBI. Total ecosystem USBI scales linearly with active users: | Users | At launch | Lessons maxed (L10) | Level 20 | Level 30 | | ------ | ---------: | ------------------: | ------------: | ------------: | | 500 | 500,000 | 12,000,000 | 30,500,000 | 50,500,000 | | 1,000 | 1,000,000 | 24,000,000 | 61,000,000 | 101,000,000 | | 10,000 | 10,000,000 | 240,000,000 | 610,000,000 | 1,010,000,000 | | 50,000 | 50,000,000 | 1,200,000,000 | 3,050,000,000 | 5,050,000,000 | These are virtual-supply ceilings, not hard mints. Actual circulating USBI depends on how much users have claimed. ## Welcome grant The welcome grant is currently being finalized between two values: **1,000 USBI** (canonical economy v3.1) versus **5 USBI + 0.1 BINI** (production simulation v3.0). This page reflects the canonical 1,000 USBI value. The production value will be confirmed in the [Bini App / Onboarding](/bini-app/overview) page when set. ## Formula in code ```javascript theme={null} const WELCOME_GRANT = 1_000; const RATIO = 10_000; const MAX_ENTITLEMENT = 100_000; function usbiEntitlement(totalXp) { return Math.min(Math.floor(totalXp / RATIO), MAX_ENTITLEMENT); } function claimableUsbi(totalXp, alreadyClaimed) { const entitlement = usbiEntitlement(totalXp); return WELCOME_GRANT + entitlement - alreadyClaimed; } ``` ## Related The input to USBI entitlement Bridge A: how CRS becomes USBI USBI entitlement at each level Where USBI provides liquidity # User Levels & XP Curve Source: https://docs.binibit.com/tokenomics/user-levels 30 levels from Seed to Genesis, with required XP and USBI entitlement at each tier. The Bini App has **30 user levels**. Each level requires a cumulative XP threshold and unlocks a higher USBI entitlement. ## Level table | Level | XP required | USBI entitlement | Total USBI (incl. welcome grant) | Stage | | ----- | ------------: | ---------------: | -------------------------------: | --------------- | | 1 | 0 | 0 | 1,000 | Start | | 2 | 2,000,000 | 200 | 1,200 | | | 3 | 7,000,000 | 700 | 1,700 | | | 4 | 18,000,000 | 1,800 | 2,800 | | | 5 | 50,000,000 | 5,000 | 6,000 | Early active | | 6 | 75,000,000 | 7,500 | 8,500 | | | 7 | 105,000,000 | 10,500 | 11,500 | | | 8 | 140,000,000 | 14,000 | 15,000 | | | 9 | 180,000,000 | 18,000 | 19,000 | | | 10 | 230,000,000 | 23,000 | 24,000 | All lessons max | | 11 | 264,000,000 | 26,400 | 27,400 | | | 12 | 298,000,000 | 29,800 | 30,800 | | | 13 | 332,000,000 | 33,200 | 34,200 | | | 14 | 366,000,000 | 36,600 | 37,600 | | | 15 | 400,000,000 | 40,000 | 41,000 | DEX regular | | 16 | 440,000,000 | 44,000 | 45,000 | | | 17 | 480,000,000 | 48,000 | 49,000 | | | 18 | 520,000,000 | 52,000 | 53,000 | | | 19 | 560,000,000 | 56,000 | 57,000 | | | 20 | 600,000,000 | 60,000 | 61,000 | Strong active | | 21 | 640,000,000 | 64,000 | 65,000 | | | 22 | 680,000,000 | 68,000 | 69,000 | | | 23 | 720,000,000 | 72,000 | 73,000 | | | 24 | 760,000,000 | 76,000 | 77,000 | | | 25 | 800,000,000 | 80,000 | 81,000 | Power user | | 26 | 840,000,000 | 84,000 | 85,000 | | | 27 | 880,000,000 | 88,000 | 89,000 | | | 28 | 920,000,000 | 92,000 | 93,000 | | | 29 | 960,000,000 | 96,000 | 97,000 | | | 30 | 1,000,000,000 | 100,000 | 101,000 | Genesis (max) | ## How XP is earned ``` 1 CRS spent = 1 XP earned ``` Any CRS spend generates XP — lesson upgrades, USBI bridge, skins, lottery, spawn fees, boost. There is no exception. XP is cumulative and never decreases. See [XP Formula](/tokenomics/xp-formula). ## How USBI entitlement is derived ``` usbi_entitlement = floor(total_xp / 10,000) ``` Capped at **100,000 USBI** at Level 30 (1,000,000,000 XP). The "Total USBI" column adds the **1,000 USBI welcome grant** every user receives at signup. Maximum theoretical USBI per user = **101,000**. See [USBI Formula](/tokenomics/usbi-formula). ## Important — lessons alone don't max you Maxing all 30 lessons to L10 costs **230,000,000 CRS**, putting you at **Level 10** with **24,000 USBI**. To reach Level 30, you need to spend the remaining \~770M CRS through other sinks: bridges, skins, lottery, Agent Token spawn, boost. See [Lessons](/tokenomics/lessons) for the full lesson cost curve. ## Time to level — simulation Two passive scenarios with no skin/lottery spend: | Scenario | Lessons maxed | Reach Level 30 | | ------------------------------------------------------ | ------------: | -------------: | | 2 claims/day, no referrals | Day 109 | Day 352 | | 3 claims/day, no referrals | Day 91 | Day 292 | | 2 claims/day, 100 active refs | Day 90 | Day 316 | | 2 claims/day, 500 active refs (capped at 500K CRS/day) | Day 88 | Day 297 | See [Simulation](/tokenomics/simulation) for full cohort projections. ## Related 1 CRS spent = 1 XP earned floor(XP / 10,000), capped at 100,000 Cost & bonus curves for the 30 lessons Level 30 milestones from Seed to Genesis # wBINI Cap Rule Source: https://docs.binibit.com/tokenomics/wbini-cap DEX Liquidity allocation creates a $240M implied market cap ceiling at 5% LP. The DEX Liquidity allocation is **50,000,000 BINI (5% of total supply)**. This sets a hard ceiling on how much liquidity the wBINI side of BaiDEX pools can carry. ## The math | Parameter | Value | | ------------------------------------- | ----------------: | | DEX Liquidity allocation | 50,000,000 BINI | | BINI reference price | \$0.12 | | **wBINI side value** | **\$6,000,000** | | Matched USBI side | \$6,000,000 USBI | | **Maximum wBINI/USBI pool TVL** | **\$12,000,000** | | **Maximum implied MC at 5% LP ratio** | **\$240,000,000** | ## Why this matters A pool's TVL implies a market capitalization. If you have $12M of liquidity (sum of both sides) at a 5% LP ratio against MC, the implied MC is $12M / 5% = \$240M. This is a **ceiling** for the canonical wBINI/USBI pool. Beyond this point: * Either organic BINI buying lifts the price (not the supply we control) * Or liquidity moves to many smaller USBI/Agent Token pools instead of one fat wBINI/USBI pool * Or future allocations (post-vesting, post-emission) supplement DEX liquidity ## Why most activity should be in USBI/Agent Token pools The wBINI cap forces a specific liquidity topology: **diverse pools, not one fat pool**. ```mermaid theme={null} flowchart TB Anchor["wBINI / USBI
Capped at \$12M TVL
(one pool)

Anchor pool"] Growth["USBI / Agent Token (×N)
No cap on USBI side
(scales with user XP entitlement)

Growth pools"] Premium["wBINI / Agent Token (×M)
Limited by remaining wBINI
outside the anchor pool

Premium pools"] Anchor -- trades clear here --> Growth Anchor -.- Premium classDef anchor fill:#dcfce7,stroke:#16a34a,color:#14532d classDef growth fill:#e0f2fe,stroke:#0284c7,color:#0c4a6e classDef premium fill:#fef9c3,stroke:#ca8a04,color:#713f12 class Anchor anchor class Growth growth class Premium premium ``` Most user activity should happen in **USBI/Agent Token** pools. These are uncapped on the USBI side because USBI is a sandbox stablecoin that scales linearly with user count and engagement. The wBINI/USBI anchor pool exists to give USBI a real-value reference, not to be the main trading venue. ## Future ceiling expansion The cap is conservative on purpose for the sandbox phase. Avenues to expand: * **Ecosystem Reserve unlocks** (10% / 100M BINI) can supplement DEX liquidity over time * **Marketing milestones** can fund liquidity bootstrapping for high-value pools * **Organic BINI accumulation** by the protocol (e.g., from sink-burns being partially routed to LP) can add wBINI without new emission * **Mainnet replacement** of USBI may change the entire liquidity model ## Sanity check | Check | Value | Formula | | --------------------------- | -----------------------: | -------------------------------- | | wBINI allocation cap | \$240,000,000 implied MC | `($6M + $6M) / 5%` | | Max wBINI in pools | 50,000,000 BINI | `5% × 1B total supply` | | wBINI/USBI pool TVL ceiling | \$12,000,000 | `$6M wBINI side + $6M USBI side` | ## Related Pool types: wBINI/USBI, USBI/AT, wBINI/AT Where the 50M DEX Liquidity comes from (TGE) BINI vs wBINI vs USBI relationships How spawn fees affect the pool topology # XP Formula Source: https://docs.binibit.com/tokenomics/xp-formula Total XP equals total CRS spent, capped at 1B for the level system. XP is the central progression metric. It feeds the [user level curve](/tokenomics/user-levels) and the [USBI entitlement formula](/tokenomics/usbi-formula). ## Core formula ``` total_xp = total_crs_spent ``` Every Crystal (CRS) you spend in the Bini App produces exactly **one XP**. There is no multiplier, no loss, no exception. ## Cap ``` max_xp = 1,000,000,000 (capped at Level 30) ``` Once you have spent 1B CRS, you are at Level 30 (Genesis) and your XP no longer counts for level progression. The cap exists so the level system has a clear endpoint and the maximum USBI entitlement is defined. ## What counts as CRS spend Every action that consumes CRS gives XP: | Action | Gives XP | | ------------------------------- | ----------------------------------------- | | Lesson upgrade | Yes | | USBI bridge (Bridge A) | Yes — 10,000 CRS spent = 10,000 XP earned | | Skins | Yes | | Lottery ticket (CRS-priced) | Yes | | Agent Token spawn (CRS portion) | Yes | | Token boost / promotion | Yes | | Other CRS sinks | Yes | Earning CRS (mining, claims, daily calendar, referrals) does **not** earn XP. Only spending does. ## Why "spend" not "earn" The model rewards **engagement and risk-taking**, not passive accumulation. Hoarding CRS doesn't level you up. You must commit your CRS to a sink for XP to flow. This also means there's no incentive to farm-and-hold — the optimal strategy is consistent spending into productive sinks (lessons first, bridges and other sinks later). ## Formula in code For implementers: ```javascript theme={null} function totalXp(totalCrsSpent) { return Math.min(totalCrsSpent, 1_000_000_000); } ``` ## Related XP → USBI entitlement XP thresholds for each of the 30 levels Lesson costs (largest XP source for new users) Where users earn the CRS they later spend # Data Verification Source: https://docs.binibit.com/verification Live snapshot for cross-checking API data against the trading interface. ## Purpose A side-by-side view: numbers pulled live from the public API next to links to the matching trading pages. Useful for: * Operations teams monitoring data integrity * Developers sanity-checking their integrations * Data aggregators (CoinGecko, CoinMarketCap, DefiLlama) verifying that Binibit API data matches the trading interface — a precondition for listing ## Live snapshot Compare values below to the trading view on binibit.com — they should match. | Pair | Last | 24h Volume (base) | 24h Volume (USD est.) | Bid | Ask | Spread % | Trading page | | ---------- | ------- | ----------------- | --------------------- | ------- | ------- | -------- | ------------------------------------------- | | AAVE\_USDT | 97.4408 | 471.47 AAVE | \$45,745 | 95.5644 | 97.4953 | 1.98% | [open](https://binibit.com/trade/AAVE-USDT) | | BTC\_USDT | (live) | (live) BTC | (live) | (live) | (live) | (live) | [open](https://binibit.com/trade/BTC-USDT) | | TRX\_USDT | 0.3238 | 9,900.94 TRX | \$3,214 | 0.3204 | 0.3261 | 1.78% | [open](https://binibit.com/trade/TRX-USDT) | | LINK\_USDT | 9.1935 | 432.94 LINK | \$4,005 | (live) | (live) | (live) | [open](https://binibit.com/trade/LINK-USDT) | Numeric snapshot above is illustrative — the canonical, real-time values are at the [`/tickers`](/api-reference/tickers) endpoint. A live auto-refreshing widget will replace the static table in the next docs release. ## Reproduce locally ```bash theme={null} curl -s https://internal-api.binibit.com/api/marketdata/getcoingecko/tickers \ | jq -r '.[] | [.ticker_id, .last_price, .base_volume, .target_volume, .bid, .ask] | @tsv' \ | column -t ``` ## For aggregator reviewers If you are reviewing Binibit for a third-party listing (CoinGecko, CoinMarketCap, DefiLlama, Kaiko, etc.): * The [`/tickers`](/api-reference/tickers) endpoint is the source of truth for last prices and 24h volumes * Click any "open" link above to verify the same numbers appear on the live trading interface * Email [api@binibit.com](mailto:api@binibit.com) for IP whitelisting and elevated rate limits during review ## Status & uptime Per-endpoint uptime, incident history, scheduled maintenance.