Protocol reference · Architecture

Four execution paths. One wallet boundary.

The frontend reads several providers, but every state-changing action resolves to a concrete router, pair, or staking contract before the wallet signs.

V2 AMMFarm accountingPrivileged parameters

System map


Connected wallet
  ├─ Swap ──────── quote engine ── selected router ── pair(s)
  ├─ Liquidity ─── BitBlocks Router ── Factory ── pair / LP token
  ├─ Earn ───────── MasterChef (many pools) or SmartChef (one pool)
  └─ Read-only ──── RPC + app API routes ── metrics / token context

BitBlocks V2 AMM

Router

The router is an immutable pair of factory and WETH addresses. It exposes standard V2 functions for exact-input and exact-output swaps, adding and removing liquidity, native BNB variants, permit-based removal, and fee-on-transfer supporting swap variants.

For every deadline-protected call, the ensure modifier rejects an expired timestamp. Slippage is enforced by amountOutMin, amountInMax, amountAMin, or amountBMin supplied by the caller.

Factory

The factory stores both token orders in getPair, appends each new pair to allPairs, and deploys deterministic pairs with CREATE2. Only the configured feeToSetter can change feeTo or transfer that setter role.

Pair invariant


amountInWithFee = amountIn × 9975
amountOut = amountInWithFee × reserveOut
            / (reserveIn × 10000 + amountInWithFee)

The pair’s swap check subtracts 25 basis points from each input balance before checking x × y ≥ k. That is the source-backed reason the frontend labels BitBlocks V2 hops with a 0.25% LP fee.

When feeTo is non-zero, the pair can mint protocol LP tokens from growth in sqrt(k) during mint or burn. The configured recipient and current activation state are live factory state.

Swap quote architecture

V2

The frontend generates direct and base-token candidate paths, batches getAmountsOut across BitBlocks and PancakeSwap V2 routers, and keeps the highest successful output. It reads pair reserves to derive a mid-price and price impact.

MasterChef

MasterChef stores an array of pool records and one user record per pool and address.


poolReward = blocks × bbkfiPerBlock × allocPoint / totalAllocPoint
pending = user.amount × accBBKFIPerShare / 1e12 − rewardDebt

During updatePool, the contract mints the calculated pool reward to itself and an additional poolReward / 10 to the developer address. A deposit first settles pending rewards, transfers the deposit token, applies any depositFeeBP, then updates reward debt. Withdraw follows the same accounting before returning principal.

Owner controls

add, set, and updateEmissionRate are onlyOwner. Pool weight and deposit fee can therefore change.

Role controls

The current developer address can rotate itself, and the current fee address can rotate itself.

Emergency exit

emergencyWithdraw returns deposited tokens, resets amount and reward debt, and does not pay pending rewards.

Mint dependency

Pool updates require MasterChef to retain authority to call BBKFI mint.

SmartChef

Each SmartChef is initialized once by its factory with stake token, reward token, rate, block window, optional user limit, and admin. Rewards are accumulated with a precision factor derived from reward-token decimals.

deposit and withdraw settle pending rewards before updating debt.
stopReward can move the end block to the current block.
updateRewardPerBlock and schedule updates are allowed only before a pool starts.
recoverWrongTokens rejects both the configured stake and reward token.
emergencyRewardWithdraw lets the owner withdraw reward tokens.

SmartChef rewards are pre-funded and the owner can stop or withdraw rewards. Treat the displayed end time and APR as current observations, not immutable promises.

Upgradeability and code changes

The mirrored BitBlocks Router, Factory/Pair, MasterChef, BBKFI, and SmartChef sources do not use proxy delegation or expose an upgrade function. Changing implementation logic requires a new deployment. That does not remove privileged configuration functions from the existing deployments.

This distinction matters: non-upgradeable code can still contain mutable parameters and admin roles.

Failure boundaries

RPC failures can prevent quotes or pool reads without changing contract state.
A provider returning no route is not equivalent to a protocol-wide liquidity failure.
A token that violates common ERC-20 expectations can break approval, transfer, reserve, or quote assumptions.
Slippage and deadline checks deliberately revert when state changes beyond the user’s limits.
External routes inherit the contract and provider risks of PancakeSwap or 1inch in addition to frontend risk.