Docs

REBC 2.0 whitepaper

Mechanics, tokenomics, bonding-curve math, fees, and risk notes.On-chain figures and parameters follow the deployed contracts.

REBC 2.0 Whitepaper

Reversible Adaptive Hybrid Bonding Curve
A next-generation reversible hybrid bonding curve protocol

Token: REBC
Chain: BNB Chain (BSC)
Total token supply: 1,000,000,000,000 (1 trillion)
Initial supply: 0
Version: 1.0 (May 2026)
Core design: At 80% of max supply, marginal price is exactly 5000× the start · piecewise exponential curve · curve reserve vs LP-budget split · V4 ledger hook (secondary swaps reconcile against the curve) · governable parameters


Abstract

REBC 2.0 is a bonding curve + reversible redemption protocol on BNB Chain with on-chain referrals and a secondary market story we actually tell users: a V4 ledger hook (Curve Sync Hook) on a concentrated-liquidity pool — before each swap it compares “what the curve would mint for this BNB” vs “what the pool spot implies”, and moves the LP fee if the pool tries to be sweeter than the mint path.

Key innovations:

  • At 80% of supply (vs cap), marginal price vs the start is exactly 5000×
  • Piecewise exponential curve with a gentler slope after 80%
  • Curve reserve vs LP budget (lpNativeReserved, etc.) split; redemptions only touch curve-side reserves
  • Primary mint: buy handles tax, split, mint — no inlined pool creation. LP budget is withdrawLpBudget’d, then ops add liquidity on a DEX. ≥15% supply is a common “time to have a pool” ops milestone, not a forced on-chain tripwire
  • Secondary reconciliation: the hook only reads the curve; mint state stays untouched. Roadmap modules (milestone fee tiers, tiny skim to a multisig) ship only after their own contracts + audits + announcements
  • Governable knobs (tax tiers, LP budget ratio, etc.) align with a DAO direction
  • Referral anti-abuse + per-buy min/max; other guardrails follow whatever revision is deployed

1. Tokenomics

  • Total supply: 1,000,000,000,000 REBC
  • Initial supply: 0 (all circulation enters via the curve)
  • Minting: Pay BNB → mint REBC (supply increases)
  • Burning: Burn REBC → withdraw BNB from Curve reserve (supply decreases)
  • Per-buy bounds (defaults): 0.1 BNB ≤ single buy ≤ 5 BNB (MEV / large-trade mitigation)

2. Bonding curve math

REBC uses a Piecewise Exponential Reversible Bonding Curve.

Supply fraction (circulation vs the 1 trillion cap, computed on-chain with WAD precision): [ f = \frac{S}{10^{12}} \quad (0 \leq f < 1) ]

Adaptive curve formulas are written through the 99% milestone; at very high (f) the on-chain implementation safely clamps the exponential input (≈ 0.999) to avoid numerical edge cases, consistent with the 99% row in tables.

Marginal price (BNB per whole REBC): [ P(f) = \begin{cases} P_0 \cdot e^{k_1 \cdot f} & \text{if } f < 0.8 \ P_0 \cdot e^{k_1 \cdot 0.8 + k_2 \cdot (f - 0.8)} & \text{if } f \geq 0.8 \end{cases} ]

Parameters:

  • ( P_0 = 1 \times 10^{-10} ) BNB per REBC
  • ( k_1 = \dfrac{\ln(5000)}{0.8} \approx 10.646491 ) (segment 0–80%)
  • ( k_2 = 5.0 ) (segment after 80%)

Reserve integral (R(f)) (cumulative BNB owed to the curve side, consistent with theoreticalReserveWei):

  • When ( f \leq 0.8 ):
    [ R(f) = \dfrac{P_0 \times 10^{12}}{k_1} (e^{k_1 f} - 1) ]
  • When ( f > 0.8 ):
    [ R(f) = R(0.8) + \dfrac{P_0 \times 10^{12}}{k_2} \cdot e^{k_1 \cdot 0.8} \cdot (e^{k_2 (f-0.8)} - 1) ]

Key milestones (REBCMath model):

  • 80% supply: marginal price ≈ 5000× vs start
  • 99% supply: ≈ 12,929× (table / exponential extension)

3. Fees and fund flows

Mint (buy)

  • Dynamic mint tax (REBCMath.mintTaxBps(totalSupply()), (f=) circulating fraction of cap): (f<55%)450 bps (4.5%); (55%\leq f<75%)300 bps (3%); (f\geq75%)150 bps (1.5%). After tax: netWei = amount − tax.
  • Inside taxWei (REBCAdaptiveCurve.buy): anchor split 150:300:450 — referral pool cap taxWei × 300 / 450; actual refPay is min(referralPool, maxRefWei) with maxRefWei scaled from effectiveReferralBase (see contracts); teamTaxWei = taxWei − refPay to team first; Referral.payReferralTiered pays refPay with L1:L2 = 200:100 (L2 share falls back to team if ineligible).
  • Post-tax split (current on-chain buy): default 85% / 15% of netWei (lpBudgetBpsOfNet, default 1500 bps, DAO-governable with a cap)
    • 85%curveBnB to CurveReserve, sizing user mint via the curve integral;
    • 15%lpBnB, accrued as lpNativeReserved on the curve contract for DEX pool creation and liquidity adds.

Burn (sell)

  • Fee: 0.3% (protocol fee)
  • User receives: 99.7% (of gross redemption)

4. Dynamic mint tax

[ \text{Mint Tax}(f) = \begin{cases} 4.5% & f < 0.55 \ 3% & 0.55 \leq f < 0.75 \ 1.5% & f \geq 0.75 \end{cases} ]


5. Secondary market: V4 ledger hook (Curve Sync Hook)

5.1 One line

No matter how deep the pool looks, it still has to pass the curve smell test: same BNB notional, mint preview vs pool spot. If the pool is “too good to be true”, LP fee goes up on that swap. Not a back-office slider — it’s on the swap path.

5.2 Engineering

  • Pancake Infinity CL + dynamic LP fee + beforeSwap hook comparing previewBuyMintTokens vs a linear estimate from sqrtPriceX96, fed into CurveAnchoredFeeBps. REF_BNB example 1 BNB, DAO-governable.
  • Pool init must line up PoolKey.parameters with the hook’s permission bitmap or the chain rejects you.
  • Queued hard mode (off by default): milestone-based fee tiers; a razor-thin skim to a multisig.

6. Referral rewards

  • Referral funds: from refPay inside taxWei, with refPay \leq taxWei \times 300/450 and a cap via effectiveReferralBase / maxRefWei; any unused referral-pool headroom stays in teamTaxWei. payReferralTiered splits refPay L1:L2 = 200:100.
  • Anti-abuse: Referrer must have minted; one-time bind; maxSingleMintBNB and effectiveReferralBase cap the rewardable base per buy—see Referral + curve contracts.
  • First buy: If bindReferrerIfUnset succeeds in the same buy, or the wallet already bound a valid referrer via Referral.bindReferrer, the first mint can also route referral payouts to L1/L2 within the tax slice and base rules.
  • Binding wins: After bindReferrerIfUnset, if referrerOf(msg.sender) is non-zero, L1 is always that bound address; the buy referrer argument is used only when no binding exists yet (first bind + payout path), preventing later calldata from redirecting fees to a different address.

7. Security and operations

  • Automation: buy / sell run on-chain when dependencies are configured; LP budget is typically withdrawLpBudget then added off-chain. Curve Sync Hook adjusts dynamic fees per eligible swap when deployed with a valid pool config. If LM is enabled, its injection + cooldown path runs when invoked.
  • MEV mitigation: Per-buy bounds; LM path adds injection cooldown and TWAP deviation limits.
  • Solvency and transparency: Redemptions debit CurveReserve; on-chain theoretical reserve integral vs actual reserve balance (e.g. solvencyRatioWad) supports monitoring. “Solvency” means the economic design goal of curve reserve vs burn integral—actual ratios can move with injection refunds, mistaken BNB transfers, LP-path minting, etc.—not a guarantee of 100% at all times.
  • Engineering safety: OpenZeppelin building blocks, reentrancy guards, Solidity 0.8 overflow checks, etc.

8. Price simulation table (3% steps)

Marginal prices follow the same model as REBCMath.marginalPriceBnBWei / getCurrentPrice at each listed supply fraction (f). The “LP budget cumulative” column is an illustration: assuming reserve accumulation (\approx \int_0^S P(s),ds) and a constant post-tax path of 85% to reserve / 15% to LP budget, cumulative LP BNB (\approx \frac{15}{85}) times that integral (ignores tax-tier changes, integer rounding, and LP-minted supply feedback on marginal price—may differ slightly from on-chain lpNativeReserved). DEX depth depends on how that budget is deployed (Infinity + hook vs whatever legacy ops still run). Use on-chain reads as authoritative.

Supply %SupplyMarginal price (BNB/REBC)vs startLP budget cumulative (illustrative, BNB)
0%01.00×10⁻¹⁰1x0
15%150B4.94×10⁻¹⁰4.94x7
30%300B2.44×10⁻⁹24.4x39
60%600B5.95×10⁻⁸595x984
80%800B5.00×10⁻⁷5,000x8,286
90%900B8.24×10⁻⁷8,244x19,734
99%990B1.29×10⁻⁶12,929x36,269

Risk notice

  • Prices are set by markets and the curve—volatility and smart-contract risk exist.
  • This page explains mechanics only—not investment advice.
  • On-chain parameters and versions on deployed contracts and BscScan read interfaces are authoritative; governance may lag this document—follow official announcements or the open-source repo.

Welcome to REBC 2.0—see you at the 80% · 5000× milestone design.

Docs · Whitepaper · REBC 2.0