KRB Token &
Ecosystem Whitepaper

This Whitepaper is informational. It is not investment, legal, tax or financial advice; it is not a promise of profit, price, liquidity, listing or regulatory approval. KRB is intended as a utility token. Participation can involve total loss, smart-contract failure, stablecoin risk, wallet compromise, operational failure and legal restrictions.

Document control

How to read implementation statements

Words such as “will”, “intended”, “scheduled” and “target” describe a launch configuration. A feature is live only when its final address, verified source, funded balance, role configuration, transaction evidence and applicable terms are publicly available.

Governing-document hierarchy

1. Applicable law and final binding participant terms.
2. Verified mainnet smart contracts and their immutable state.
3. Published governance decisions and timelock executions.
4. This Whitepaper and other explanatory material.

KARAB is designed around a fixed maximum supply of 25,000,000 KRB on BNB Smart Chain. The token uses the standard BEP-20/ERC-20 interface, has 18 decimals, has no owner minting, no transfer tax, no automatic DEX burn, no blacklist and no owner power to burn a holder’s balance. A holder may voluntarily burn only tokens that holder controls.

Eight purpose-separated allocations map the entire fixed supply. The largest is the 15,000,000 KRB 1,500-Day Ecosystem Rewards Reserve, funded at up to 10,000 KRB for each completed UTC programme day. Days 1–1,000 may fund eligible ROI and network-reward categories; days 1,001–1,500 fund eligible ROI only.

The limited community sale is capped at 300,000 KRB. Its scheduled window is 01 August 2026 00:01 UTC through 31 October 2026 23:59 UTC, and it closes earlier if all 300,000 KRB are sold. BEP-20 USDT on BNB Smart Chain is the accepted payment asset. A package-mode purchase, KRB allocation and locked position are intended to succeed or revert atomically.

Liquidity may be provisioned only after the ICO completes. LP tokens received from that provisioning are locked for four years (1,460 days). Treasury, Community, contributor, network-security and DAO reserves follow the independent schedules in Section 4.

Core administration is intended to be controlled by a 2-of-3 Safe through a 48-hour Timelock. Reward settlement separates operator, approver and payer roles. Mining is an upcoming post-ICO feature inside the same 10,000 KRB daily envelope; it is not active during the ICO.

Launch evidence required

• Final deployed addresses and BscScan-verified source.
• On-chain owner, pending-owner, role and 48-hour Timelock evidence.
• Funded balances matching all eight allocations.
• Sale inventory, dates, price curve, USDT treasury and unsold-inventory proof.
• Independent security review, full test output and a testnet rehearsal of purchase, staking, reward and withdrawal paths.
• Issuer identity, eligibility rules, binding terms, privacy notice and jurisdictional legal review.

1.1 Intended purpose

KRB is intended as a utility token for supported KARAB products, payments, gifts, cards, access, commerce, service fees, community programmes and future network functions. Utility availability depends on product delivery, partner support, law and published terms.

1.2 Scope

This document covers token supply, eight allocations, the limited sale, locked packages, capital release, reward accounting, mining disclosure, liquidity, administration, governance, security, transparency and material risks.

1.3 Design principles

2.1 Pre-deployment status

This Version 1.4 is a launch-candidate disclosure, not an announcement that the mainnet system is already operational. The verified mainnet contracts and their on-chain state are the authoritative technical record after deployment.

2.2 Canonical hierarchy

Production configuration files, deployment manifests, verified contracts, on-chain role state, public allocation proofs and binding terms must reproduce the parameters in this document. If a public page conflicts with deployed code or binding law, publication must pause until the conflict is resolved.

2.3 Material implementation reconciliation

3.1 Core parameters

3.2 Supply and transfer invariants

• Total supply can never exceed 25,000,000 KRB.
• No owner, Safe, Timelock, DAO or other role can mint additional KRB.
• Token transfers do not deduct a protocol transfer tax or automatic burn.
• No administrator can seize, blacklist, freeze or burn a holder’s KRB through the token contract.
• Application-level eligibility or settlement controls do not change the token’s transfer invariants.

3.3 What KRB does not promise

KRB does not promise a market price, appreciation, listing, redemption at a fixed value, guaranteed liquidity, guaranteed reward, guaranteed capital recovery or legal availability in every jurisdiction.

4.1 Fixed allocation

4.2 Lock and release controls

4.3 Circulating-supply disclosure

Public reporting must separate total supply, burned supply, sale inventory, locked reserves, vested but unclaimed balances, liquidity balances, project-controlled balances and freely circulating KRB. “Circulating” must never include locked or unavailable allocations.

5.1 Intended utility categories

Subject to availability, local law and separate product terms, KRB may support:

• access to eligible KARAB digital services or features;
• settlement for specified ecosystem goods or services;
• community incentives and promotional campaigns funded from disclosed reserves;
• payment of eligible application or network charges;
• governance participation after binding DAO activation;
• future interoperable applications or a native KRB-chain migration, if separately audited and approved.

Utility is roadmap-dependent. A planned merchant, card, recharge, gift-card, exchange, bridge or partner integration is not guaranteed until the responsible provider, supported jurisdiction, fees and consumer terms are published. Third-party products remain subject to their own availability and legal restrictions.

5.2 No value-support promise

Product utility, fixed supply, reserve locks, voluntary holder burn and governance are functional design choices. They must not be marketed as mechanisms that guarantee price appreciation or allow a participant to recover a purchase amount. No internal illustration is a forecast.

5.3 Future-chain policy

Any migration from BNB Smart Chain to a native or alternate network is a Critical Proposal. The proposal must disclose the bridge or swap mechanism, snapshot rules, custody model, audit scope, exchange treatment, user deadline, treatment of lost keys, residual supply, administrator powers and rollback plan. A migration may not duplicate supply across chains.

6.1 Purpose-separated custody

Each allocation uses a labelled contract or controlled address. A balance assigned to one purpose cannot be silently re-labelled for another purpose. Release transactions and destination addresses must be publicly auditable.

6.2 Treasury use of sale proceeds

Sale USDT is transferred to the disclosed Safe treasury. On-chain transfers are public. Public reporting should identify the treasury address, material transfers, purpose, authorisation and supporting records without exposing private personal data.

6.3 Conflicts and related parties

Payments to founders, owners, contributors, advisers or related vendors require written disclosure, conflict abstention where applicable, Safe approval, Timelock delay and transaction evidence.

7.1 Fixed sale framework

7.2 Piecewise price curve

The contract computes the price across each applicable segment. A quote must disclose the USDT input, KRB output, average price, maximum cost, expiry and slippage protection before signature.

7.3 Transaction safeguards

• Wrong-chain and wrong-token payments are rejected.
• The sold counter cannot exceed 300,000 KRB.
• A stale quote or insufficient approved USDT reverts.
• A failed stake creation reverts the complete purchase.
• The buyer receives the transaction hash and final package record.

7.4 Unsold inventory

At finalisation, unsold KRB is moved into the disclosed unsold-inventory lock for 365 days. Any later sale requires a new public schedule, price disclosure, governance approval and Timelock execution.

7.5 Eligibility

Participation may be restricted by jurisdiction, age, sanctions, identity, source-of-funds, risk or legal requirements. A wallet connection alone does not create a right to participate.

8.1 Bounded daily reserve

The 15,000,000 KRB reward reserve is divided across 1,500 completed UTC programme days. For each completed day, DailyReleaseVault makes 10,000 KRB available. A missed release job does not permanently strand that day’s allocation; catch-up processing remains bounded by elapsed completed days and the fixed reserve.

8.2 Programme phases

• Days 1–1,000: eligible ROI, Normal Level, Level Bounce, Royalty and approved offer income may be settled after any mining deduction.
• Days 1,001–1,500: eligible ROI only may be settled.
• Entitlements are subject to eligibility, package caps, available daily funding, oracle controls and binding terms.

8.3 Locked staking plans

The client enters the amount first and then selects a duration. That choice fixes the package’s ROI rate, reward cap and lock expiry. The reward cap and 1X capital entitlement are separate.

8.4 Capital claim

After the selected lock expires, the user may start the 1X capital-claim schedule. That first claim stops future ROI for the package and transfers 10% of original capital immediately on the claim date. Nine more 10% portions become claimable after successive complete 30-day intervals, for ten releases totalling 1X. If the user delays the first claim, ROI may continue only until the package reward cap is reached.

8.5 Reward withdrawals

• Minimum ordinary reward withdrawal: $30 equivalent.
• Requests below $500 equivalent use the automatic settlement route.
• Requests at or above $500 equivalent require an independent approver before payment.
• Ordinary reward withdrawals deduct a fixed 10% programme administrative charge.
• Capital releases and mining claims do not pay that programme charge.

8.6 Mining — upcoming after ICO

Mining is not active during the ICO. After ICO finalisation, governance may activate one publicly announced 90-day eligibility campaign. A qualified participant completes the seven-day task cycle and may then claim the published $1-equivalent KRB amount directly to the participant’s wallet for up to 100 claim days. Missed daily claims expire; there is no carry-forward, package 2X/3X/4X consumption, $30 minimum or 10% programme charge.

Global mining claims are capped at 1,000 KRB per UTC day and are paid first from that day’s 10,000 KRB envelope. The remaining main-distribution budget is 10,000 KRB − actual mining claims. Unused mining capacity remains available to the day’s eligible main distribution.

8.7 No guaranteed income

Published percentages describe programme calculations, not guaranteed profit or guaranteed payment. Eligibility, package caps, daily funding, contract operation, token price, liquidity, law and participant actions can reduce or prevent a payment.

9.1 Required separation

The system must separately record ROI, Normal Level, Level Bounce, Royalty, offer income, mining, capital release, administrative charge and final KRB settlement. A category cannot be silently converted into another category.

9.2 Daily close

Main-income calculation closes at 23:59 UTC. A reproducible run records eligible packages, inputs, oracle snapshot, category totals, per-package cap consumption, mining deduction, final allocations and settlement identifiers.

9.3 Price and oracle controls

Any USD-equivalent KRB settlement uses a fresh, recorded oracle snapshot with staleness, positivity, deviation and replay checks. Browser-supplied prices are not authoritative.

9.4 Operator controls

Operator, approver and payer duties are separated. The operator cannot approve its own high-value request; the approver cannot rewrite the recipient or amount; a payer can execute only an approved, unexpired settlement. Liability reserves and surplus withdrawal limits protect participant obligations.

9.5 Referral, levels and rank bonus

Level access opens by active direct count: one active direct opens Level 1, continuing one-for-one through nine active directs and Level 9; ten qualified active directs open all 20 levels. Each active direct must hold at least $100 equivalent in an active Lock Package. An Unlock Package does not create level, rank or mining eligibility.

R1 through R5 require the published self-business, active-direct and team-business conditions. Rank Level Bonus pays 5% on the corresponding Normal Level income: R1 on eligible Level 1 income, R2 on Level 2, R3 on Level 3, R4 on Level 4 and R5 on Level 5. It is distinct from differential Royalty.

9.6 Direct-selling condition

No reward is payable merely for recruiting a person. Every reward must trace to an eligible funded package or disclosed utility event and comply with local law.

10.1 Post-ICO provisioning

No project-provided swap or liquidity route is promised during the ICO. After ICO completion, authorised KRB and the paired asset may be supplied to a disclosed DEX pool under Safe and Timelock control.

10.2 Four-year LP lock

LP tokens received from the initial post-ICO liquidity provisioning are transferred to the public LP-lock contract and locked for four years (1,460 days) from the lock transaction. The transaction hash, LP token address, amount, unlock timestamp and beneficiary must be published.

10.3 Market risks

The token itself does not block trading or charge a transfer tax. DEX pricing, slippage, MEV, pool imbalance, impermanent loss, third-party fees and low liquidity remain material risks. A four-year LP lock restricts custody of the locked LP tokens; it does not guarantee price or permanent liquidity.

11.1 Standard token transfers

KRB applies 0% transfer tax. Wallet transfers, buys, sells and liquidity actions are not subject to a KRB protocol fee or automatic burn. The token does not need pair or router classification to calculate a fee.

11.2 Voluntary holder burn

A holder may permanently burn only KRB controlled by that holder. No owner, Safe, Timelock, DAO or administrator can burn another holder’s balance. Voluntary burn reduces total supply but does not guarantee price appreciation.

11.3 Separate programme charges

The fixed 10% reward-withdrawal administrative charge is an application settlement rule, not a token transfer tax. Capital releases and mining claims do not pay it. Gas fees and DEX/AMM fees are charged by the network or third-party venue, not by the KRB token.

12.1 Launch control

At launch, a three-owner Safe requiring any two owners controls administrative contracts through an enforced 48-hour Timelock. The Safe is not a private-key wallet and has no single private key; each owner signs from a separate owner wallet.

12.2 Timelock purpose

The 48-hour delay applies to scheduled administrative and governance changes. It does not delay an ordinary token transfer or every client withdrawal. The delay gives participants and monitors time to inspect a queued high-impact action before execution.

12.3 DAO activation

Binding DAO execution may begin only after audited governance contracts, published voting-supply exclusions, quorum and proposal thresholds, tested delegation/snapshot rules, role handoff and public operating procedures. Before that evidence exists, any community vote is advisory.

12.4 Reserve decisions

DAO-reserve spending requires a documented proposal, conflict disclosure, vote or authorised Safe decision under the current phase, Timelock delay and on-chain execution. Governance cannot mint KRB or bypass immutable vault schedules.

13.1 Standard proposals

Standard proposals may cover published grants, community programmes, product initiatives and released reserve use within existing limits.

13.2 Critical proposals

Ownership transfer, role changes, oracle replacement, reserve destination changes, sale recovery, liquidity custody and governance upgrades are Critical Proposals and require enhanced review, explicit calldata, simulation, Safe approval and the full Timelock.

13.3 Conflicts

A proposer or signer with a financial or personal interest must disclose it and abstain where the governing procedure requires. Related-party transfers must identify the beneficiary and purpose.

13.4 Restricted emergency authority

Guardian roles may pause a pausable operational module or revoke a compromised operator. They cannot mint tokens, seize user tokens, rewrite a completed entitlement, shorten an allocation lock or redirect a reserve. Any emergency action must be logged, time-limited and reviewed.

14.1 Component map

14.2 Contract properties

• Checks-effects-interactions, reentrancy protection and exact role checks.
• Immutable supply, inventory, schedule and percentage bounds where practical.
• Events for allocation, claim, release, approval, payout, role and administrative actions.
• Fresh-oracle enforcement for USD-equivalent settlement.
• Liability-reserve protection before any surplus withdrawal.
• Ownable2Step or equivalent acceptance so ownership cannot be sent accidentally.

14.3 Upgrade policy

The core token is intended to be non-upgradeable. Any upgradeable operational component must publish proxy/admin addresses, storage review, implementation hash, audit, simulation, Safe approval and Timelock transaction before execution.

15.1 Required role matrix

15.2 Handoff evidence

For every ownership-controlled production contract, public evidence must show the final Timelock as owner, a zero pending owner, the expected roles, the Safe threshold, the 48-hour minimum delay and the handoff transaction hashes.

15.3 Pause policy

A pause is protective and temporary. It does not erase earned balances or authorise confiscation. The reason, scope, start time, responsible role, remediation and unpause transaction must be recorded.

16.1 Required assurance sequence

1. Freeze the exact source commit and configuration.
2. Install dependencies reproducibly; compile with the pinned compiler.
3. Run unit, integration, invariant, fuzz, coverage, lint and type checks.
4. Deploy the same build to BSC Testnet.
5. Rehearse sale, package, ROI, level/rank, capital, withdrawal, reserve and governance paths.
6. Resolve material findings and archive evidence.
7. Obtain an independent professional smart-contract audit before public mainnet reliance.
8. Deploy and verify source on BscScan.
9. Fund exactly, hand ownership to the 48-hour Timelock and verify all roles on-chain.

16.2 Minimum test themes

16.3 Audit limitations

Testing and audit reduce risk but cannot prove the absence of all bugs, economic failures, key compromise, legal restrictions or third-party failure. An internal or AI-assisted review is not a substitute for an independent professional audit.

16.4 Mainnet launch checklist

Mainnet launch remains blocked until the exact build, full tests, testnet rehearsal, independent audit, final parameters, funded balances, verified source, Safe/Timelock ownership, separated roles, oracle, legal documents, monitoring, incident response and public evidence are complete.

17.1 Public dashboard

Reporting should show fixed/remaining supply, holder burns, all eight allocation balances, release schedules, sale progress, price segment, treasury USDT receipts, reward-day releases, category settlements, liabilities, mining claims when active, LP lock proof and governance queue.

17.2 Version and change control

Every publication must display its version and date. Material changes require a changelog, affected sections, source/config hash, approval evidence and effective time. Public pages, client/admin panels and PDFs must use the same canonical data.

17.3 Marketing controls

Marketing must not use “guaranteed”, “risk-free”, “double money”, “fixed profit”, “Bitcoin mining” or false scarcity. It must distinguish token transfer tax (0%) from the separate 10% reward-withdrawal programme charge.

19.1 Responsible entity and local launch

Before participation, a jurisdictional supplement must identify the issuer/offeror's full legal name, legal form, registration number, registered office, directors or responsible officers, grievance contact, compliance contacts, governing law and forum. It must identify eligible and restricted jurisdictions. "Global" availability must not be claimed merely because a smart contract is technically accessible.

19.2 India-specific launch gates

KRB is not Indian legal tender, is not the Digital Rupee, is not issued or guaranteed by the Reserve Bank of India and is not covered by a bank-deposit or investor-compensation scheme.

Before India access, the responsible entity should obtain written specialist analysis covering at least:

• activity-based applicability of the Prevention of Money Laundering framework and current FIU-IND VDA service-provider requirements;
• customer due diligence, beneficial ownership, source of funds, sanctions/PEP screening, transaction monitoring, recordkeeping and reporting;
• Consumer Protection Act and Direct Selling Rules, including whether remuneration is solely from genuine end-customer goods/services sales;
• Prize Chits and Money Circulation Schemes (Banning) Act exposure;
• Banning of Unregulated Deposit Schemes Act treatment of package, capital and reward promises;
• SEBI collective-investment-scheme analysis of pooled contributions, management and expected income;
• income-tax, withholding/TDS, GST and user-reporting obligations without hard-coding changeable tax rates here;
• FEMA and cross-border payment-flow requirements for USDT receipts;
• privacy, cybersecurity, electronic-contract and grievance obligations.

This list identifies issues; it does not conclude that KARAB is or is not within a particular legal category. If positive written analysis and an operational compliance design are unavailable, India sale/reward access must remain disabled or the model must be restructured.

19.3 AML/KYC and eligibility controls

Participation is limited to adults who are legally competent, located in an eligible jurisdiction and acting for their own disclosed benefit. The operator may require identity, beneficial-owner, source-of-funds, sanctions, PEP and wallet-risk checks; reject, delay or restrict a transaction where law or Binding Terms require; and retain or report information to competent authorities where legally authorised.

19.4 Consumer and privacy documents

Before collecting value or personal data, publish accessible Sale Terms, Reward Programme Terms, Privacy Notice, AML/KYC Policy, Restricted Jurisdictions Schedule, risk acknowledgement, complaint/escalation procedure and refund/error policy. Privacy materials must state purpose, legal basis where applicable, retention, processors, cross-border sharing, security, user rights, grievance contact and breach handling.

19.5 No regulatory-status marketing

An FIU registration, audit, legal memorandum, company registration, token listing or verified contract must not be presented as government endorsement, investment approval or guarantee. Legal classification depends on actual rights, economics, marketing and operations in each jurisdiction.

20.1 Clear pre-transaction display

Before signature, a user should see the responsible counterparty, product/package, token amount, payment amount, 0% token transfer-tax status, programme charge, network fee, lock, capital-release conditions, reward limitations, price source, refund/error policy and risk acknowledgement in a durable form.

20.2 Complaints and errors

The responsible entity must provide a traceable complaint channel, acknowledgement time, escalation route and final-response time. Lost private keys and voluntary transfers to the wrong address may be technically unrecoverable, but issuer error, duplicate debit, failed package activation, misrepresentation and non-waivable statutory rights require a documented process.

20.3 Prohibited conduct

The target programme prohibits:

• guaranteed-profit, fixed-income or guaranteed-capital-recovery representations;
• compensation solely for recruiting, enrolling or activating another participant;
• undisclosed personal fee destinations or reserve transfers;
• wash trading, market manipulation, false volume or misleading liquidity claims;
• sanctions evasion, identity misrepresentation or use of prohibited funds;
• wallet splitting or controlled-account voting to manipulate limits or governance;
• misleading use of "tax," "approved," "insured," "risk-free," "banked" or "audited."

20.4 Management responsibility

Before any final public issue, the responsible entity's management should confirm, after reasonable inquiry and to the best of its knowledge as of the publication date, that the final Whitepaper is fair, clear and not misleading and does not omit information whose omission would materially affect a reasonable reader's assessment. That confirmation is management accountability, not regulatory approval.

No control eliminates risk. Participants should understand at least the following:

21.1 Voluntary burn does not remove risk

Burning reduces supply but does not create demand, liquidity, utility or a guaranteed price.

21.2 Governance does not remove responsibility

Safe, Timelock or DAO approval does not make an action lawful, prudent, secure or economically beneficial. Responsible operators remain accountable for evidence and compliance.

Unless expressly provided in applicable Binding Terms, KRB does not represent:

• equity, shares, debt or beneficial ownership in KARAB or another entity;
• a deposit, savings product, collective investment, managed fund or insurance policy;
• a claim on revenue, profits, treasury assets, dividends or interest;
• a guaranteed redemption, buyback or repayment of purchase price;
• a promise of exchange listing, liquidity, market-making or minimum price;
• a guaranteed programme allocation, reward rate or capital recovery;
• legal title to reserves, liquidity or intellectual property.

Governance participation does not itself create a partnership, agency, employment, fiduciary or directorship relationship. A proposal can succeed only within the powers of deployed contracts, Binding Terms and applicable law.

Forward-looking statements — including roadmap, integrations, chain plans, adoption, rewards, liquidity, governance and compliance milestones — are uncertain. They may be delayed, changed or cancelled. Historical, illustrative or projected figures are not guarantees.

A.1 Supply

• Maximum supply = genesis supply = 25,000,000 KRB.
• Additional minting = 0.
• Transfer tax = 0%.
• Only holder-initiated burn reduces total supply.
• The eight allocations sum to exactly 25,000,000 KRB and 100%.

A.2 Reward envelope

• Daily release = 10,000 KRB for each completed UTC programme day.
• Maximum programme days = 1,500.
• Total reward reserve = 10,000 × 1,500 = 15,000,000 KRB.
• When mining is active: main daily budget = 10,000 − actual mining claims; actual mining claims ≤ 1,000 KRB/day.

A.3 Sale curve

For an order crossing multiple sold-quantity intervals, total USDT cost is the sum of quantity purchased inside each interval multiplied by that interval’s price. Cumulative sold quantity must remain ≤ 300,000 KRB.

A.4 Capital release

Capital instalment = original capital × 10%. Instalment 1 is transferred on the first claim after lock expiry. Instalments 2–10 require successive complete 30-day intervals after that first claim.

A.5 Governance

• Safe threshold = 2 of 3 owners.
• Production Timelock minimum delay = 48 hours.
• Governance cannot mint KRB, impose a token transfer tax or shorten immutable reserve/LP schedules.

• Final source commit, build manifest, compiler settings and archive SHA-256.
• Full install/build/test/coverage/lint/typecheck output.
• Independent professional audit report and its SHA-256.
• Mainnet contract-address manifest and BscScan verified-source links.
• Exact 25,000,000 KRB allocation funding transactions and vault balances.
• 2-of-3 Safe owners/threshold and 48-hour Timelock configuration.
• For every owned contract: final owner is the Timelock and pending owner is zero.
• Sale start/end, 300,000 cap, price curve, accepted USDT, Safe treasury and unsold-lock proof.
• Reward reserve funding, 1,500-day start and 10,000 KRB daily-release proof.
• Treasury, Community, contributors, chain/security and DAO schedule proofs.
• Post-ICO DEX pool and four-year LP-lock transaction/address/unlock proof.
• Oracle, operator, approver, payer, guardian, monitoring and incident-response evidence.
• Issuer, jurisdiction, eligibility, sale/reward terms, privacy and complaints documents.

Version 1.4 — 31 July 2026

Primary technical sources

1. BNB Chain — BNB Smart Chain introduction
2. OpenZeppelin Contracts 5.x — ERC-20 API
3. OpenZeppelin Contracts 5.x — Governance guide
4. OpenZeppelin Contracts 5.x — Access Control
5. PancakeSwap — Swap FAQ
6. Safe — Documentation

Internal launch sources

The final contract source, deployment manifests, allocation proofs, test reports, audit evidence and binding terms are published with the mainnet release. Repository notes or draft screenshots are not participant-facing guarantees.