IBITIcoin Whitepaper
Made to satisfy humans and reviewers: plain language + deep technical details.
BNB Smart Chain • IBITI decimals: 8 • Website promo: UUPS proxy

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.

Key production feature: the website purchase contract (Cash Promo Router) forwards USDT to the reserve wallet immediately, then distributes IBITI rewards from a funded IBITI inventory. That means the router is designed to hold ~0 USDT after buys, and all rules are on-chain.
Token (IBITI): 0x47F2FFCb164b2EeCCfb7eC436Dfb3637a457B9bb
USDT (BSC): 0x55d398326f99059fF775485246999027B3197955
Promo Proxy: 0xcDdACBc10ea1110079405c230b3FBB9B77B81840
Promo Impl: 0x909bA32315daAEE82D5557E00F8817a8A3F10190

This paper describes what exists on-chain today. On-chain state is the source of truth.

Table of Contents

1) Goals & Design Principles

For normal users
  • 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”).
For reviewers (BSC / listing)
  • 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.

ComponentAddress
IBITI token0x47F2FFCb164b2EeCCfb7eC436Dfb3637a457B9bb
USDT (BSC)0x55d398326f99059fF775485246999027B3197955
PancakeSwap V2 Router0x10ED43C718714eb63d5aA57B78B54704E256024E
IBITI/USDT Pair (price reference)0xADfb9F0f810311e9c01C27B380909A5FfC104Be0 (Primary price reference pair)
Website Cash Promo Router (UUPS)
Proxy (public entrypoint)0xcDdACBc10ea1110079405c230b3FBB9B77B81840
Implementation0x909bA32315daAEE82D5557E00F8817a8A3F10190
Operational wallets
Owner wallet0xC00dC8E3F4647AAa4791AE58901eDDFE6095adA5
Reserve wallet0x9d8dd8b2cff7a17967fa0ef19ed5c0b3ebefde41
Vesting wallet0x1841DE9b1c8bF5244675896b0F4FF96C9331596f
Burn address0x000000000000000000000000000000000000dEaD
Modules
FeeManager0x34770ba3625437742e18C6827DFC893c42Eec956
UserStatusManager0xf1C734156A2Ab62e1018D18f6347425623af611a
BridgeManager0x813d2d93a3EfDFe8B09513b09B7CbdE06B239113
StakingModule0x9ad8D68F7a6C9f673bd1db8348734f8dA515113c
NFTDiscount (DiscountNFT)0x911f7153AA7554b3f936f2ad05318B8368c14668
IBITINFT0xE14bfBB10180eda4bDC574f02700e0E2BC0A4667
NFTSaleManager0x2c702A42966a939b6C5Da4828cd8D67890Db097E
PhasedTokenSale0x6A6eDc85f4690DBAB98d52CdF656ef849d28148e
TeamVesting0xae6fA65adede487e46ABCE1b3570063D02510d5d
DAOModule0xc0213d9d331Ea207717E38F5e0e995BA567fbd1F
BuybackManager0xdE7E16bbDe9076daF23DB25BA4E50d8FEeca5AC9
IBITI Price Oracle0x09e28925487841f0400687FD9DC9cf1d14B85aF3

3) IBITI Token (What it is)

Core properties
  • Network: BNB Smart Chain
  • Decimals: 8
  • Max supply cap: 100,000,000 IBITI (with 8 decimals on-chain)
  • Token address: 0x47F2...B9bb
What the token is for
  • 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.

Total Supply
  • Max supply cap: 100,000,000 IBITI
  • Decimals: 8
  • Token address: 0x47F2FFCb164b2EeCCfb7eC436Dfb3637a457B9bb
Where tokens are held (on-chain)
  • 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).
Policy note (important): technically, 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.

Genesis allocation (high level)
  • 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.

Operational role of the 90M Treasury inventory
  • 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 treasurySend are 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.

TeamVesting address
0xae6fA65adede487e46ABCE1b3570063D02510d5d

Schedule breakdown (for 10,000,000 IBITI allocation)

MilestoneVested %Amount (IBITI)When
TGE / Start20%2,000,000Immediately at start timestamp
+ 6 months+30%3,000,000180 days after start
After 3-year cliff+ up to 50%up to 5,000,000Linear over 180 days after 3 years
Fully vested100%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.

Reserve wallet (operations)
0x9d8dd8b2cff7a17967fa0ef19ed5c0b3ebefde41
  • Receives USDT from website promo buys immediately.
  • Used to add liquidity and support operational needs.
Liquidity approach (practical)
  • 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.

Important: “pair reserves” are not magic truth

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.

Promo is temporary: the website promo can be turned off on-chain (promoActive=false or promoEndTime reached). If promo is inactive, users can always buy IBITI directly on PancakeSwap.
Non-custodial USDT rule: when you buy on the website, your USDT is forwarded to the Reserve Wallet in the same transaction. The router is designed to end buys with ~0 USDT balance. IBITI payouts are delivered from the router’s funded IBITI inventory (promo pool / inventory).

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)
What this guarantees
  • 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.

Step A — Guaranteed (same 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.
Step B — Operational (separate 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)

Promo controls
  • promoActive (on/off)
  • promoEndTime (optional end)
  • bonusBps (e.g. 1000 = 10%)
  • refReward (fixed IBITI reward)
Safety controls
  • minPaymentAmount / maxPaymentAmount
  • minIbitiOut provided by buyer (slippage guard)
  • quoteMode and feeBps
  • minSpotPrice/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.

Time rules (from contract)
  • Duration range: 1–12 months
  • Month length: 30 days
  • Grace period after maturity: 180 days
Expiry rule (VERY important)

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 month1%1%00%
2 months3%3%00%
3 months5%5%23%
4 months7%7%00%
5 months10%10%00%
6 months12%12%25%
7 months14%14%00%
8 months18%18%00%
9 months20%20%27%
10 months22%22%00%
11 months25%25%00%
12 months30%30%210%
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)

IBITINFT (collectible/utility)
  • 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)
DiscountNFT (NFTDiscount)
  • 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)

LevelDiscount % mappingExpiry if unusedNotes
Normal1%30 daysUse → burn
Rare3% / 5% / 7%90 daysUse → burn
Legendary10% / 15% / 25%180 daysUse → burn
Epic50% / 75% / 100%365 daysUse → burn
JackpotCustom (via mintJackpot)365 daysNon-transferable
PandoraSpecialNo expiryUsage-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”.

What it can model
  • Base buy/sell fees
  • Holding-time discounts
  • VIP discounts
  • Staking discounts
  • Whale/size impacts
  • Volatility coefficient (tiers)
  • NFT discount integration
What reviewers care about
  • 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”.

Core governance constraints (from module)
  • 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”.

PhasedTokenSale
  • Phases with explicit rules and caps
  • On-chain purchase logic
  • Reward distribution mechanics (where configured)
TeamVesting
  • 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.

Key idea

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

What is upgradeable
  • Website Promo Router: UUPS proxy (upgradeable)
  • Most modules are standard deployments (non-proxy), unless explicitly proxied
Emergency controls
  • 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.
Practical reviewer check

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)

No hype. DeFi is risky. Liquidity can be thin. Smart contracts can fail. This section exists so reviewers and users don’t have to guess.

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.