Executive Summary
IBITIcoin is a modular ecosystem on BNB Smart Chain built around the IBITI token and several utility modules: staking (time-based), NFTs (collectible + discount NFTs), a fee module, a DAO module, vesting and sale modules, a buyback manager, and a website purchase flow.
This paper describes what exists on-chain today. On-chain state is the source of truth.
Table of Contents
1) Goals & Design Principles
- Buy IBITI via PancakeSwap (market) or via Website (promo flow).
- Stake IBITI for fixed periods to earn known rewards.
- Use NFTs for discounts / special utilities.
- Everything visible on-chain (no “trust me, bro”).
- Clear contracts and addresses.
- Explicit money flow (USDT routing, inventory funding).
- Upgrade boundaries are documented (what is upgradeable, what is not).
- Risks stated plainly (liquidity, oracle/pair manipulation, admin power).
Why the two-buy model? Market swaps + Website promo flow
PancakeSwap is the open market. The website router is a controlled on-chain UX layer for promotions and referrals: it does not replace the market, it provides a transparent “cashflow + bonus” path with strict limits and on-chain rules.
2) On-chain Addresses (Mainnet)
Below are production addresses from project configuration. Use BscScan to verify code and inspect read functions.
| Component | Address |
|---|---|
| IBITI token | 0x47F2FFCb164b2EeCCfb7eC436Dfb3637a457B9bb |
| USDT (BSC) | 0x55d398326f99059fF775485246999027B3197955 |
| PancakeSwap V2 Router | 0x10ED43C718714eb63d5aA57B78B54704E256024E |
| IBITI/USDT Pair (price reference) | 0xADfb9F0f810311e9c01C27B380909A5FfC104Be0 (Primary price reference pair) |
| Website Cash Promo Router (UUPS) | |
| Proxy (public entrypoint) | 0xcDdACBc10ea1110079405c230b3FBB9B77B81840 |
| Implementation | 0x909bA32315daAEE82D5557E00F8817a8A3F10190 |
| Operational wallets | |
| Owner wallet | 0xC00dC8E3F4647AAa4791AE58901eDDFE6095adA5 |
| Reserve wallet | 0x9d8dd8b2cff7a17967fa0ef19ed5c0b3ebefde41 |
| Vesting wallet | 0x1841DE9b1c8bF5244675896b0F4FF96C9331596f |
| Burn address | 0x000000000000000000000000000000000000dEaD |
| Modules | |
| FeeManager | 0x34770ba3625437742e18C6827DFC893c42Eec956 |
| UserStatusManager | 0xf1C734156A2Ab62e1018D18f6347425623af611a |
| BridgeManager | 0x813d2d93a3EfDFe8B09513b09B7CbdE06B239113 |
| StakingModule | 0x9ad8D68F7a6C9f673bd1db8348734f8dA515113c |
| NFTDiscount (DiscountNFT) | 0x911f7153AA7554b3f936f2ad05318B8368c14668 |
| IBITINFT | 0xE14bfBB10180eda4bDC574f02700e0E2BC0A4667 |
| NFTSaleManager | 0x2c702A42966a939b6C5Da4828cd8D67890Db097E |
| PhasedTokenSale | 0x6A6eDc85f4690DBAB98d52CdF656ef849d28148e |
| TeamVesting | 0xae6fA65adede487e46ABCE1b3570063D02510d5d |
| DAOModule | 0xc0213d9d331Ea207717E38F5e0e995BA567fbd1F |
| BuybackManager | 0xdE7E16bbDe9076daF23DB25BA4E50d8FEeca5AC9 |
| IBITI Price Oracle | 0x09e28925487841f0400687FD9DC9cf1d14B85aF3 |
3) IBITI Token (What it is)
- Network: BNB Smart Chain
- Decimals: 8
- Max supply cap: 100,000,000 IBITI (with 8 decimals on-chain)
- Token address:
0x47F2...B9bb
- Medium of value inside IBITI ecosystem modules
- Staking collateral (time-based rewards)
- NFT purchase & discount mechanisms
- Governance participation via DAO module
Technical details (reviewer view)
- Initial supply is minted at deployment up to the cap.
- The system integrates modular contracts (fees, user status, bridge, staking, DAO, NFT discounts).
- Key security pattern: sensitive actions are owner-gated; emergency pausing exists where implemented.
3.1 Tokenomics & Supply Management
IBITI has a fixed maximum supply of 100,000,000 IBITI (8 decimals) on BNB Smart Chain. The supply is minted at deployment to the token contract itself (the on-chain Treasury), and then distributed via explicit treasury operations.
- Max supply cap: 100,000,000 IBITI
- Decimals: 8
- Token address:
0x47F2FFCb164b2EeCCfb7eC436Dfb3637a457B9bb
- Treasury = the IBITI token contract itself (minted supply is held here).
- Treasury is frozen for normal transfers (cannot be drained via standard transfer/transferFrom paths).
- Project can move IBITI out of Treasury only via an explicit admin function:
treasurySend(to, amount).
treasurySend can send to any address (owner-controlled).
The project policy is to use Treasury releases primarily to the Reserve Wallet to support liquidity,
promotions inventory, and future marketing operations. This policy is public and should be monitored on-chain.
Why mint to Treasury (contract) instead of minting gradually?
Minting everything at deployment with a hard cap removes “future mint surprise”. Users can always verify the total supply. Holding supply in the contract Treasury makes distribution operations auditable.
3.2 Initial Allocation (Genesis distribution)
At launch, 10,000,000 IBITI were allocated into the Team Vesting flow. The remaining 90,000,000 IBITI stayed in the on-chain Treasury to be released operationally to the Reserve wallet for liquidity support and ecosystem needs.
- Team vesting allocation: 10,000,000 IBITI
- Treasury operational inventory: 90,000,000 IBITI
Note: amounts are expressed in human units (IBITI). On-chain the token uses 8 decimals.
- Funding liquidity operations (via Reserve wallet)
- Funding promo inventories / reward pools when required
- Future ecosystem and marketing use (transparent transfers)
On-chain clarity — what reviewers can verify
- Treasury balance is visible on the token contract address.
- Any Treasury releases via
treasurySendare on-chain transactions and can be tracked publicly. - Team vesting schedule is enforced by the TeamVesting contract.
3.3 Team Vesting (on-chain schedule)
Team allocation is governed by the TeamVesting contract with a strict release schedule: 20% immediately after start, 30% after 6 months, and the remaining 50% linearly over 180 days after a 3-year cliff.
0xae6fA65adede487e46ABCE1b3570063D02510d5dSchedule breakdown (for 10,000,000 IBITI allocation)
| Milestone | Vested % | Amount (IBITI) | When |
|---|---|---|---|
| TGE / Start | 20% | 2,000,000 | Immediately at start timestamp |
| + 6 months | +30% | 3,000,000 | 180 days after start |
| After 3-year cliff | + up to 50% | up to 5,000,000 | Linear over 180 days after 3 years |
| Fully vested | 100% | 10,000,000 | ~3.5 years after start |
How release works (mechanics)
- Tokens must be deposited into the vesting contract (up to the allocation).
releasableAmount()shows what is currently unlocked.release()transfers unlocked tokens to the beneficiary.- Contract is pausable (emergency control) and nonReentrant-protected.
3.4 Treasury & Liquidity Policy
Liquidity is supported primarily through the Reserve Wallet. The Reserve wallet receives USDT from website purchases (forwarded in the same transaction by the Promo Router) and may also receive funds from direct PancakeSwap market activity.
0x9d8dd8b2cff7a17967fa0ef19ed5c0b3ebefde41- Receives USDT from website promo buys immediately.
- Used to add liquidity and support operational needs.
- When USDT arrives to Reserve, liquidity can be added promptly (policy: “as funds arrive”).
- Liquidity is also supported indirectly via open market trading on PancakeSwap.
- IBITI inventory for liquidity can be released from Treasury to Reserve when needed.
Website buy vs Pancake buy — what’s the difference?
- PancakeSwap buy: standard AMM swap, price determined by pool reserves, subject to slippage.
- Website promo buy: user pays USDT, USDT forwarded to Reserve, IBITI paid from router inventory plus promo bonus and optional referral reward.
- Both are on-chain and publicly verifiable. The website flow is an on-chain UX layer for promotions and referrals.
Liquidity risk note
Liquidity operations and reserve-based quoting depend on the depth of the IBITI/USDT pool.
Low liquidity increases slippage and makes reserve manipulation attacks cheaper.
The promo router includes limits and buyer-side slippage protection (minIbitiOut).
4) Market & Price Reference
IBITI has an open market via PancakeSwap. The website promo router uses the IBITI/USDT pair reserves as an on-chain price reference.
Reserve-based pricing is standard in AMMs, but it can be manipulated in low liquidity. That’s why the website router includes limits and slippage guards.
How reserve quoting usually works (AMM-style)
amountInWithFee = amountIn * (10000 - feeBps) amountOut = (amountInWithFee * reserveOut) / (reserveIn*10000 + amountInWithFee)
This is the typical UniswapV2/PancakeV2-style quote with fee. Slippage is naturally captured.
5) Website Cash Promo + Referral Router (UUPS)
IBITIcoin website purchases are executed by an on-chain smart contract (behind a UUPS proxy). The router enables promo bonuses and referrals while keeping the payment flow transparent and auditable.
5.1 Money flow (single purchase transaction)
User USDT ── transferFrom ─► Promo Router (UUPS Proxy) Promo Router ── transfer ─► Reserve Wallet (immediate forward) Promo Router ── transfer ─► Buyer: IBITI (base amount + promo bonus) Promo Router ── transfer ─► Referrer: IBITI (fixed reward, if eligible)
- USDT is not stored on the router after a buy (it is forwarded immediately).
- IBITI is paid from a pre-funded router inventory (bonus pool/inventory).
- All transfers are visible on-chain (token transfers per transaction hash).
5.2 What users see (MetaMask confirmations)
- Connect wallet → choose “Promo Buy” → enter USDT amount (and optional referrer)
- MetaMask may ask for 2 confirmations:
- 1) USDT Approve — one-time (or when allowance is insufficient). It grants the router permission to spend your USDT.
- 2) Purchase — the actual buy transaction. In this transaction USDT is forwarded to the Reserve Wallet and IBITI is delivered (base + bonus, and referral if eligible).
- After confirmation the website generates an IBITI Receipt (purchase check) with the tx hash and links to BscScan.
Note: the Approve is a separate transaction made by your wallet (allowance). Promo bonus/referral payouts are performed as token transfers during the purchase transaction.
IBITI Receipt (purchase check) — what it contains
After a successful on-chain purchase, the website shows an IBITI Receipt (receipt modal) with a human-friendly summary and direct links to verification sources.
- Network (Mainnet/Testnet) and timestamp
- Buyer address and transaction hash
- Paid (USDT)
- Market amount (IBITI) + Promo bonus (IBITI) + Total received (IBITI)
- Effective price (USDT per IBITI)
- Links: BscScan transaction + shareable receipt link
- Options to copy, save image, or print the receipt
Receipt values are derived from on-chain transfer logs and executed transaction data. The blockchain transaction is the ultimate source of truth.
5.3 How the router determines your IBITI amount (pricing & quote)
The router uses the IBITI/USDT PancakeSwap pair reserves as a market reference (AMM-style quoting).
A buyer-provided minIbitiOut works as a slippage guard: if the expected IBITI output is below that value,
the transaction reverts.
Reserve-based quote (AMM-style)
amountInWithFee = amountIn * (10000 - feeBps) amountOut = (amountInWithFee * reserveOut) / (reserveIn*10000 + amountInWithFee)
quoteMode and feeBps make the quoting rule explicit. The goal is transparent, on-chain pricing
aligned with the pool reserves, not a “manual price”.
5.4 Where your USDT goes after the buy (Reserve → Liquidity policy)
The promo router itself does not add liquidity. It forwards USDT to the Reserve Wallet immediately. Liquidity is added by the Reserve Wallet via PancakeSwap as a separate on-chain transaction.
- USDT is forwarded to the Reserve Wallet immediately.
- Router remains near 0 USDT after buys by design.
- Anyone can verify this in token transfer logs per transaction.
- Reserve Wallet can use received USDT to add liquidity to the IBITI/USDT pool on PancakeSwap.
- This happens as an additional on-chain action initiated by operations.
- Policy goal: add liquidity promptly “as funds arrive”, but it is not an automatic on-chain guarantee.
Why liquidity is not added inside the buy transaction
Liquidity operations require separate approvals, slippage settings, and timing decisions (pool state changes every block). Keeping the buy transaction focused (forward USDT + deliver IBITI) reduces complexity and failure modes, while still keeping liquidity additions fully traceable on-chain when performed by the Reserve Wallet.
5.5 Promo inventory (bonus pool) and accounting
IBITI payouts are limited by the router’s available IBITI inventory. The router maintains accounting counters so the website can show “remaining promo pool” transparently and so anyone can monitor promo spending on-chain.
Bonus pool accounting (why UI numbers match reality)
The router can track totals (e.g., pool total, spent counters) so the UI can display remaining promo inventory. Regardless of accounting variables, IBITI transfers are always limited by the router’s actual IBITI token balance.
5.6 Key on-chain parameters (read from proxy)
promoActive(on/off)promoEndTime(optional end)bonusBps(e.g. 1000 = 10%)refReward(fixed IBITI reward)
minPaymentAmount/maxPaymentAmountminIbitiOutprovided by buyer (slippage guard)quoteModeandfeeBpsminSpotPrice/maxSpotPrice(optional bounds)pause/unpause(emergency stop)
5.7 UUPS upgrade boundary (what can be upgraded)
The router is upgradeable via a UUPS proxy to patch critical issues. The proxy address stays the same, while the implementation can be upgraded by an authorized account. Upgrade transactions are visible on-chain and can be monitored.
Transparency checklist (quick verification)
- Open the transaction hash in BscScan and review token transfers.
- Confirm USDT moved to the Reserve Wallet in the same transaction.
- Confirm IBITI transfers to the buyer (and referrer if applicable).
- Confirm router USDT balance remains near 0 after the buy.
6) Staking (Periods, Rewards, Expiry Rules)
Staking in IBITI is intentionally simple: choose a duration (1–12 months) → lock tokens → claim later. Rewards and penalties are deterministic and known in advance.
- Duration range: 1–12 months
- Month length: 30 days
- Grace period after maturity: 180 days
If you do not claim within maturity + 180 days, your stake becomes expired and principal is transferred to the treasury (forfeited). This is an explicit on-chain rule.
6.1 Reward / Penalty Schedule
The same percentage ladder is used for on-time rewards and early-unstake penalties (in % of principal).
| Duration | Reward % (on time) | Penalty % (early) | Default NFT reward | Default NFT discount % |
|---|---|---|---|---|
| 1 month | 1% | 1% | 0 | 0% |
| 2 months | 3% | 3% | 0 | 0% |
| 3 months | 5% | 5% | 2 | 3% |
| 4 months | 7% | 7% | 0 | 0% |
| 5 months | 10% | 10% | 0 | 0% |
| 6 months | 12% | 12% | 2 | 5% |
| 7 months | 14% | 14% | 0 | 0% |
| 8 months | 18% | 18% | 0 | 0% |
| 9 months | 20% | 20% | 2 | 7% |
| 10 months | 22% | 22% | 0 | 0% |
| 11 months | 25% | 25% | 0 | 0% |
| 12 months | 30% | 30% | 2 | 10% |
Staking cashflow (what happens to your tokens)
- When staking, IBITI is transferred to the staking contract and recorded as a stake entry.
- When unstaking:
- Early: penalty is applied; payout is reduced.
- On-time (within grace): reward is applied; payout increases.
- Expired: principal is transferred to treasury and the stake is removed.
- If contract balance is insufficient for payout, it can auto-replenish by pulling from treasury
via
transferFrom(requires allowance).
NFT rewards from staking (3/6/9/12 months)
For selected durations, the contract mints “Jackpot” Discount NFTs via NFTDiscount’s mintJackpot.
Mint failures do not revert unstake (errors are caught), so users can still claim principal/reward.
7) NFTs (Two Layers)
- ERC-721 collection
- Purchase with IBITI or USDT (depending on configuration)
- Unique tokenURI enforced (anti-duplicate)
- Monthly price update logic exists (sales threshold + growth rate)
- ERC-721 discount NFTs
- Most are single-use: use → burn
- Many expire if unused (by level)
- Pandora has special rules (no expiry)
7.1 Discount NFT levels & expiry (on-chain)
| Level | Discount % mapping | Expiry if unused | Notes |
|---|---|---|---|
| Normal | 1% | 30 days | Use → burn |
| Rare | 3% / 5% / 7% | 90 days | Use → burn |
| Legendary | 10% / 15% / 25% | 180 days | Use → burn |
| Epic | 50% / 75% / 100% | 365 days | Use → burn |
| Jackpot | Custom (via mintJackpot) | 365 days | Non-transferable |
| Pandora | Special | No expiry | Usage-limited |
Pandora usage rules (important)
Pandora NFTs do not expire, but usage is limited: the contract enforces a maximum of 10 uses per 360 days. (This is a built-in anti-abuse throttle.)
Minting & payments
- Discount NFTs can be purchased using USDT or IBITI if payment token and price are configured.
- Owner can withdraw accumulated payments from the NFTDiscount contract.
- Staking contract is authorized to mint Jackpot rewards via NFTDiscount.
8) Fee System (FeeManager)
Fees are calculated by a dedicated FeeManager contract with configurable parameters and bounds. The goal is to keep fee logic auditable and adjustable without hiding behavior inside “mystery math”.
- Base buy/sell fees
- Holding-time discounts
- VIP discounts
- Staking discounts
- Whale/size impacts
- Volatility coefficient (tiers)
- NFT discount integration
- Fee clamped by min/max bounds
- Admin setters visible on-chain
- Audit helpers (parameter sanity)
- Pausable where implemented
Reality check — fees are a policy tool, not a miracle
Fees can support sustainability and discourage abuse, but they do not remove market risk. They must be tuned responsibly, and their impact should be monitored.
9) DAO Governance (DAOModule)
The DAO module provides on-chain proposals and voting. It is intentionally scoped to avoid “governance can rug itself”.
- Vote threshold: 100
- Max voters per proposal: 500
- Proposals have an end time and execution status
How governance is usually hardened (future direction)
Mature protocols often move admin powers into multisig + time-lock, and progressively expand DAO scope. IBITI follows the same “start safe, expand carefully” philosophy.
10) Sale & Vesting (PhasedTokenSale, TeamVesting)
These modules formalize structured sale phases and long-term team vesting. The goal is transparent schedules, not “backroom unlocks”.
- Phases with explicit rules and caps
- On-chain purchase logic
- Reward distribution mechanics (where configured)
- Long-term vesting schedule
- Withdraw rules enforced by contract
- Vesting wallet:
0x1841...596f
Why vesting matters to reviewers
Vesting is one of the simplest “anti-dump-by-design” tools: it makes large allocations move on a schedule, and it’s publicly verifiable.
11) Buyback (BuybackManager)
BuybackManager can be used to acquire IBITI on the market and optionally burn tokens by sending them to the burn address. This is an operational tool — not a guaranteed promise.
If buybacks are used, they should be executed with slippage protections and transparent reporting.
Burn is verifiable (tokens sent to 0x...dEaD).
12) Security, Admin Controls, Upgrade Boundaries
- Website Promo Router: UUPS proxy (upgradeable)
- Most modules are standard deployments (non-proxy), unless explicitly proxied
- Pausable patterns exist to stop interaction during critical events
- Reentrancy guards exist in sensitive functions
- Admin setters are visible on-chain and should be monitored
Trust model (honest version)
Some parameters are owner-controlled (promo bonus, limits, quote config, etc.). This is a trust assumption until governance/multisig hardening is implemented. The upside: bugs can be patched faster. The downside: admin power must be monitored.
13) Transparency & Monitoring
What anyone can verify
- Promo router buys: by watching the proxy events (e.g., PromoBuy).
- USDT routing: router should typically have ~0 USDT after buys (it forwards to reserve).
- Pool health: “remaining promo pool” can be read from on-chain counters/state.
- Upgrades: proxy upgrade transactions are visible on-chain.
After a website buy: reserve wallet USDT increases; router USDT balance stays near 0; router IBITI decreases by base+bonus+ref amounts.
14) Risks & Limitations (Read This)
Market & liquidity risk
- Low liquidity increases slippage and price volatility.
- Large trades can move reserves quickly.
Pair reserve manipulation risk
- Website quoting relies on pair reserves → manipulable in low liquidity.
- Mitigations exist: buy limits, buyer minOut, optional spot bounds.
Admin / upgrade risk
- UUPS promo router is upgradeable by authorized admin — visible, but still power.
- Parameter changes can affect behavior; monitoring is recommended.
Staking expiry risk
- If you ignore maturity + 180 days grace, stake expires and principal is forfeited to treasury.
- This is not hidden. It is explicit on-chain behavior.
15) FAQ
Why have a website buy flow if Pancake exists?
Pancake is the open market. The website flow is a transparent on-chain “promo + referral + reserve-forwarding” router with strict limits, designed for simple UX and promotions.
15) Where do my USDT go after buying on the website?
Your USDT is forwarded to the Reserve Wallet in the same transaction. The promo router is designed not to custody USDT, so after buys its USDT balance should remain near 0.
After the USDT reaches the Reserve Wallet, it can be used for liquidity operations (e.g., adding liquidity to the IBITI/USDT pool on PancakeSwap). This liquidity step is typically executed as a separate on-chain transaction from the Reserve Wallet and is fully traceable on-chain.
Receipt: after a successful purchase the website shows an IBITI Receipt (a “check”) with transaction hash, paid USDT, received IBITI (base + bonus), effective price, and direct links to BscScan.
What happens if I forget to unstake?
You have maturity + 180 days grace. After that, the stake is expired and principal is transferred to treasury. Put a reminder. Seriously.
Are Discount NFTs reusable?
Most discount NFTs are single-use (use → burn). Pandora is special: it does not expire but has a usage limit (10 per 360 days).
Nothing here is financial advice. On-chain state is the source of truth.