Developing Liquidity Bootstrapping Pool (LBP)
Project launches new token. Team wants fair launch: no sniper bots, no whale capture at start, no instant dump from early investors. Standard AMM pool doesn't work here—whoever added liquidity first set price. LBP solves this via dynamic weights, but implementation requires understanding Balancer V2 mechanics to level of internal invariants.
Why Standard IDO Breaks, LBP Doesn't
Mechanics of Attack on Regular Launch
Typical scheme: project creates Uniswap V2 pool, adds liquidity in 50/50 ETH/TOKEN ratio. In first block, MEV-bots via flashbots bundle capture maximum tokens at launch price, then immediately place sell orders 20-30% above. Real buyers already pay inflated price, bots lock profit. Project gets reputation damage in first minutes.
LBP works differently: startup TOKEN/USDC weight set, for example, 96/4. Token price artificially high, making immediate purchase uneconomical. Over 48-72 hours weights gradually shift to 50/50 or 20/80—price decreases on preset curve. Bot has no reason to buy at start: each next block offers token cheaper.
LBP Curve Mathematics
Balancer's weighing invariant based on weighted product:
∏(Bᵢ ^ Wᵢ) = k
where Bᵢ—each token balance, Wᵢ—its weight. When weights change over time, k recalculates and spot price changes without actual trades. Weight shift by 1% per hour—predictable price decline developer sets in pool config at deployment.
Critical parameter—swapFee. Too low commission (<1%) makes arbitrage cheap and dilutes curve. Too high (>5%) scares legitimate buyers. For most LBP, optimal range—1-3%.
What We Build Inside LBP Project
Pool on Balancer V2 Weighted Pool Factory
Deploy via WeightedPoolFactory with normalizedWeights and temporary weight controller. We don't use managed pool without good reason—it's more complex in audit and requires whitelist for each action. Standard weighted pool with updateWeightsGradually() closes 90% of LBP tasks.
// Example call via IWeightedPool
IWeightedPool(poolAddress).updateWeightsGradually(
startTime,
endTime,
endWeights // [endWeight_token, endWeight_collateral]
);
Rights to call updateWeightsGradually—only poolController, which we deploy with multisig (Gnosis Safe) or timelock. Direct project team access to this function—critical vulnerability: rug pull via instant weight shift.
Rights Management Contract
Separate LBPController.sol with role model via OpenZeppelin AccessControl:
-
OWNER_ROLE—team multisig, manages parameters -
PAUSER_ROLE—ability to emergency stop trading (Balancer vault allows) -
WITHDRAW_ROLE—liquidity withdrawal after LBP completion
Without explicit role separation in contract, control key becomes single point of failure. One private key compromise = loss of entire pool liquidity.
Supporting Infrastructure
Frontend Integration—via Balancer SDK (@balancer-labs/sdk) or directly via viem with Vault contract ABI. Show current weights, spot price and LBP remaining time in real-time.
Monitoring—Chainlink Automation (former Keeper) or custom off-chain bot for calling updateWeightsGradually by schedule if team wants manual curve control.
The Graph Subgraph—index WeightsUpdated, Swap, PoolBalanceChanged events for historical price and volume graph.
Typical Problems We Close in Advance
| Problem | Consequence | Solution |
|---|---|---|
| No max buy limit | Whale captures 30% supply | maxTokensOut per transaction in vault wrapper |
| Weight decline too fast | Price drops faster than expected, FUD | Curve simulation in Python before deploy |
| No whitelist at start | MEV-bots participate anyway | First 1-2 hours—whitelist only |
| Liquidity stuck after LBP | Team can't withdraw | Explicit exitPool function with timelock |
Whitelist mechanism at start—separate Merkle proof contract. Root loaded at deploy, addresses from list confirm participation via proof. Gas-efficient even for 10,000 addresses.
Workflow on LBP
Tokenomics Analysis (2-3 days). Break down: initial supply, allocations, insider cliff/vesting. If 40% tokens unlock at LBP day—curve won't save. Model scenarios in spreadsheet and align pool parameters.
Curve Design (1 day). Python script simulates price behavior at different startWeights, endWeights, duration, swapFee parameters. Client sees three curve options before development starts.
Contract Development (3-5 days). LBPController.sol, deployment scripts via Foundry, integration tests on mainnet fork Ethereum. Fork-test critical: check real Balancer Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8 interaction.
Frontend and Monitoring (3-5 days). Dashboard with live graph, timer, current price. Alerts in Discord/Telegram for anomalous swaps.
Audit and Deployment. Internal audit via Slither + manual review. Deploy on Goerli/Sepolia for real Balancer testing. After confirmation—mainnet via Gnosis Safe multisig.
Timeline Expectations
Basic LBP without whitelist and dashboard—1 week. Full package with whitelist mechanism, monitoring, subgraph and custom frontend—2-3 weeks. Timelines depend on tokenomics complexity and UI requirements.
Cost calculated after project parameter analysis and infrastructure requirements.