# RealColibri Coin (RCC) — White Paper **Version:** 2.5.3 **Date:** July 2026 **Token:** RCC (TRC-20) **Network:** TRON Mainnet **Contract:** `TTgft2ySbTmVmxesi2hPZtpudhTt9NJjWk` **Primary issuance rate:** 1 RCC = 10 TRX (fixed, while contract supply lasts — see §4.2/§4.3) **Special allocation:** none — even the founders buy from the public contract (§4.1) --- ## Abstract RealColibri Coin (RCC) is a utility token on the TRON network that powers the RealColibri trading platform — a non-custodial automation layer for retail and professional traders on Binance, Bybit, OKX and Rithmic. The platform never holds user funds or requests withdraw permission: trading robots execute orders directly on each exchange using **Read & Trade-only** API keys, while RCC is used to pay a per-trade commission denominated in profit. A built-in **hedging-based risk-control layer is designed to keep drawdowns small**, protecting the user's deposit from large adverse moves. Every commission collected by the platform is redistributed back to the community via a deterministic, on-chain-mirrored mechanism: **50 % flows to RCC stakers** weekly, and **50 % cascades up the referral tree** of the trading user. The token therefore captures real-world cash-flow generated by automated trading, rather than depending on inflation or speculative demand alone. This paper describes the token, its distribution model, the staking and referral mechanics, the smart-contract architecture, and the off-chain mirror used by RealColibri to deliver low-latency UX while preserving on-chain auditability. --- ## 1. Problem Retail traders face three structural problems with existing automated trading services: 1. **Custody risk.** Most algorithmic-trading platforms require deposit of funds or withdraw-enabled API keys. A single platform-side breach compromises every user. 2. **Opaque pricing.** Subscription fees do not align platform incentive with user profitability — the platform earns whether the user wins or loses. 3. **Disconnected ecosystems.** Traders, referrers and platform operators compete for the same revenue pool, without a transparent mechanism for how it is divided. ## 2. Solution RealColibri addresses all three: 1. **Non-custodial by design.** API keys are restricted to *Read & Trade* on every supported exchange. Funds remain on the user's own exchange account at all times. 2. **Profit-share commission, paid in RCC.** Users pay a small percentage of *realised profit* per closed deal — never a fixed fee. If the user does not earn, the platform does not earn. 3. **On-chain redistribution.** Every commission RCC is split 50/50 between stakers and a referral cascade, with rules mirrored from the on-chain `RCService` and `RCFactory` contracts. The distribution is fully deterministic and auditable. ### 2.1 Three ways the ecosystem rewards participants RCC is designed so that value flows back to the people who use and grow the platform. There are three distinct, compounding ways to participate — all funded by **real trading cash-flow**, not inflation: 1. **Trade — earn from automation, pay only on profit.** RealColibri's robots trade on the user's *own* exchange account (non-custodial). Commission is charged **only on profitable closed deals** — never on a loss, never as a flat subscription. A built-in **hedging-based risk-control layer is designed to keep drawdowns small**, so users are protected from the deep account drawdowns typical of naive automation and do not have to fear losing their deposit to a single adverse move. *(The internal strategy is proprietary and intentionally undisclosed; automated trading still carries market risk — see §10.)* 2. **Refer — earn from your network, from day one.** Every registered user collects **50 % of all commission** generated anywhere in their referral cascade (§6) — no threshold, no approval, active from the first day. Users approved as partners earn an **additional 2–20 %** rank-based bonus on top (§6.4), funded from the platform's own residual income, not from other users' rewards. 3. **Stake — turn holding into recurring yield.** Locking RCC earns a share of the **weekly staker pool** (the other 50 % of all platform commission). The longer a stake is held, the greater its weight — up to a **16× multiplier** for long-term holders (§5.2). Passive holding becomes recurring income sourced from genuine platform activity. Together these make RCC a **utility token backed by real trading activity**: every commission is continuously recycled to stakers, referrers and partners (§4.5), while primary issuance stays fixed at 1 RCC = 10 TRX until the contract supply is exhausted (§4.2). Users do not have to trade to benefit — referral and staking income accrue on their own — but the three avenues compound for active participants. --- ## 3. Token Overview | Field | Value | | ---------------- | -------------------------------------------------- | | Name | RealColibri Coin | | Symbol | RCC | | Standard | TRC-20 | | Network | TRON Mainnet | | Contract address | `TTgft2ySbTmVmxesi2hPZtpudhTt9NJjWk` | | Decimals | 18 | | Predecessor | RCBC (deprecated, `0x0ce717CD62D2aEcBfbFBe76fB1eDEb5bb0fcEd50`) | | Factory contract | `TWf7V9cWU2gnbzRQbM9KF6f9DB3DECiouv` (RCFactory) | RCC implements the standard TRC-20 interface (`transfer`, `approve`, `allowance`, `balanceOf`, `totalSupply`, `decimals`, `name`, `symbol`) plus a `buy()` payable function used to mint RCC against TRX at a fixed contract-defined rate — see §4 for the price mechanics. --- ## 4. Token Economics ### 4.1 No pre-mine, no founders' allocation **This is the most important sentence in this White Paper:** there is **no pre-mine, no founder allocation, no team reserve, no insider tranche** for RCC. The RealColibri team — including the founders themselves — have **the same access path as any other user**: send TRX to the smart contract, receive RCC at the public rate. No backdoor mint function, no privileged role. Every RCC in existence has been minted by someone paying for it from the public contract. The team cannot "create" RCC out of thin air. ### 4.2 Fixed exchange rate while supply lasts The `buy()` function mints RCC at a **fixed rate of 1 RCC = 10 TRX**. This rate is **hard-coded in the smart contract** and cannot be changed by the team — only by deploying a new contract, which would not affect the existing one. This holds while the contract has RCC supply available. The supply was defined at deployment and cannot be expanded. ### 4.3 What happens when the contract runs out When the smart contract's RCC supply is exhausted, the `buy()` path **permanently closes**. From that moment: - **The 1 RCC = 10 TRX peg no longer exists.** No one can mint new RCC from the contract. - RCC enters **free-float on secondary markets** (DEX pools, future listings). Price is determined purely by supply and demand on those markets. - Existing RCC continues to circulate normally — transfers, staking, commissions all keep working. Only the **fixed-rate primary issuance closes**. This is a deliberate design choice. It gives early adopters a hard price floor while RCC is still being distributed, then transitions the token to fully market-driven pricing without any team intervention. ### 4.4 USD-value mechanics While the 1 RCC = 10 TRX peg is in effect, RCC's USD value is **a direct multiplier on TRX's USD value**: ``` RCC_USD = 10 × TRX_USD ``` This creates a reflexive demand loop: 1. More users want RCC (to pay platform commissions, stake, qualify for partner status). 2. They must buy TRX to swap for RCC at the contract. 3. Increased TRX buying pressure pushes TRX/USD up. 4. RCC/USD rises proportionally with TRX/USD. **RCC value is therefore directly tied to TRX network demand and to RealColibri platform usage**, with the multiplier locked at 10× while the smart contract has supply. After the contract is exhausted (§4.3), this relationship breaks — RCC trades on its own market dynamics. ### 4.5 The recycling principle RealColibri does **not retain net income in RCC**. When the platform collects a commission in RCC from a profitable user deal, the RCC is immediately split and **fully recycled back into circulation**: | Flow | Share | Recipient | | ----------------------- | ----- | ---------------------------------- | | Stakers pool | 50 % | All stakers, weekly distribution | | Referral cascade | 50 % | Up the referrer tree (§6) | | Partner VIP bonus | 2–20% | Approved partners above the trader (§6.3) — sourced from the platform's residual share | | Residual (if any) | rest | `platform_balance` (operational treasury) | The `platform_balance` is the **only** RCC that the company "earns", and it is what funds the partner VIP bonus pool. Whatever exceeds operational needs goes back to liquidity provision — never to founder wallets. **No RCC is burned.** The economy is fully circular: commission RCC keeps flowing through stakers, referrers, partners and back into the operational pool. Token velocity is high; aggregate supply does not shrink, but distribution keeps shifting toward active participants. --- ## 5. Staking — Mechanics Staking is the long-term value-capture mechanism for RCC holders. The implementation is a deterministic mirror of the on-chain `RCService` contract; the off-chain mirror used by the RealColibri backend follows the same arithmetic so that any user can reproduce their payout from public data. ### 5.1 Lock / unlock - **Lock.** A user transfers RCC from their platform balance into the staking contract. The stake is recorded with `amount`, `staked_at`, and `last_action_at`. - **Top-up.** A subsequent lock under the existing stake age-blends: small top-ups (`amount < currentStake`) rejuvenate the stake age proportionally; large top-ups (`amount >= currentStake`) preserve the age and register a `double_stake_at` timestamp used in anti-gaming checks. - **Unstake.** Full unstake only (partial withdrawal is not supported, mirroring `RCService.unlockStake`). Auto-claims all pending referral and staking payouts in the same call. ### 5.2 Age coefficient (`calcStakeScore`) Each stake is assigned a *weight* used to compute its share of the weekly pool distribution. The formula is the literal port of `RCService.calcStakeScore`: ``` weight = STAKE_WEIGHT_BASE // 10_000 + first_bump // +25 after the first 34.7-day interval + second_bump // +240 after the second + linear_decreasing_bumps // +230, +220, … → floor at +50 weight = min(weight, STAKE_WEIGHT_MAX) // 160_000 (≈ ×16 the base) ``` with `STAKE_INTERVAL_MS = 34.7 days`. A fresh stake earns the base weight 10,000; a stake matured over ten years approaches the cap of 160,000 — a sixteen-fold multiplier rewarding long holders. Stake weight is multiplied by `amount_RCC` to obtain effective pool share. ### 5.3 Pool distribution A weekly cron (`POOL_DISTRIBUTION_PERIOD_DAYS = 7`) distributes the accumulated `staking_pool` proportionally to `(weight × amount)` of every active, non-banned stake: ``` payout_i = pool_balance × (weight_i × amount_i) / Σ(weight × amount) ``` Payouts are recorded as `StakingPayout` rows with status `PENDING` until the user calls `claim()`. --- ## 6. Referral Program and Partner Tier The referral system has **two separate concepts** that are easy to confuse — and the platform UI presents them as two distinct pages: | Concept | Who has it | What they earn | | ------------------ | ------------------------------------- | ----------------------------------------------------------- | | **Referral** | Every registered user, from day one | 50% of every commission of their cascade tree (see §6.1) | | **Partner (VIP)** | Only users approved by admin after 100k RCC threshold | Additional **2–20%** rank-based bonus on commissions in their subtree, sourced from `platform_balance` (the platform's residual income) | A user is **both** a referrer (always) and, after qualification + admin approval, also a partner. Both flows compound. ### 6.1 Referral cascade — the 50% upward flow The 50 % of every commission not going to the staker pool flows **upward** through the referral tree of the user who generated the trade. The tree is permissionless and unbounded in depth; each user has at most one referrer (one-up structure). ### 6.2 Cascade algorithm Let `commission_referral = 0.5 × commission_total`. Beginning at level 1 (the user's direct referrer): ``` for each level L going up: referrer = parent at level L if referrer is None: remainder → platform_balance break self_share = INACTIVITY_PERCENTS[referrer.inactivity_weight] payout = remaining × self_share record ReferralPayout(referrer, payout, status = PENDING) remaining = remaining − payout if remaining ≤ 0: break ``` ### 6.3 Inactivity weight Each user is assigned an `inactivity_weight ∈ {0…4}` recomputed by a weekly cron. This weight determines how aggressively the referrer captures versus passes the commission upward: | inactivity_weight | self share | Pass upward | Conditions | | :---------------: | :--------: | :---------: | ----------------------------------------- | | 0 | 80 % | 20 % | Active stake (≥ 5 direct active referrals OR last action < 10 days) | | 1 | 50 % | 50 % | 10 – 35 days since last action | | 2 | 20 % | 80 % | 35 – 70 days since last action | | 3 | 10 % | 90 % | Average weight of referrals < 2 | | 4 | 5 % | 95 % | All other cases (worst) | An inactive referrer forfeits most of their reward to whoever is more active higher in the tree — incentivising both retention and quality of recruitment. ### 6.4 Partner tier — separate VIP bonus The cascade described in §6.1 is open to **all** users. Partner status is an **additional, separately-funded** bonus tier on top. #### Qualification To apply for partner status, a user must reach a cumulative RCC-purchase threshold: ``` PARTNER_ELIGIBILITY_THRESHOLD_RCC = 100,000 RCC ``` Eligible if either: - self-purchased RCC ≥ 100,000, OR - direct referrals' combined purchased RCC ≥ 100,000. Eligible users submit a partner application; approval is gated by admin review (anti-abuse). Approval is **not automatic**. #### Global cap To preserve the value of the partner tier, there is a hard cap on the number of active partners across the entire platform: ``` PARTNER_GLOBAL_CAP = 10,000 ``` When the cap is reached, no new partners are approved until existing partners are revoked. The cap may be raised by governance proposal in future versions of the protocol. #### Rank and bonus rate A partner's bonus percentage is **dynamic and grows with their network**: ``` percent = min(20%, 2% + 1% × count_partners_in_subtree) ``` - A newly approved partner with zero partners under them earns **2 %**. - Each additional partner anywhere in their downline tree adds **+1 %**. - Cap: **20 %** (reached at 18 partners in subtree). This rewards partners who themselves recruit and qualify other partners, creating a network growth incentive. #### How the bonus is funded The partner bonus is **not deducted from the staker pool or the referral cascade**. Instead, when commission flows through the distribution pipeline: 1. Staker pool receives 50 %. 2. Referral cascade distributes 50 % up the tree. 3. **For every partner in the tree above the trader, an additional payment equal to (`partner_rank % × commission_total`) is credited to that partner** — sourced from `platform_balance` (the platform's operating treasury). In effect, the company shares its residual income with its top recruiters. Stakers and ordinary referrers are not affected. #### Bonus persistence and claim Partner bonuses accrue continuously into `PartnerPayout` records with status `PENDING`. The partner can call `claim` at any time to convert pending bonus into a deposit credit. There is no time limit on claims. --- ## 7. Trading Robots — Use Case RCC's primary utility is paying commission on profitable closed deals from RealColibri's automated trading bots. Four exchange integrations are currently live or in active development: | Exchange | Status | Asset class | Notes | | -------- | ---------- | ----------------------- | ---------------------------------- | | Binance | Live | USDT-M futures | Largest user base | | Bybit | Live | USDT/USDC perpetuals | Unified Trading Account API | | Rithmic | Live | CME, EUREX, SGX futures | Professional-tier API | | OKX | Live (v1) | Linear perpetuals | passphrase auth, ctVal contracts | ### 7.1 Commission flow For every closed deal where `profit > 0`: ``` commission_RCC = profit × COMMISSION_RATIO / rcc_price ``` The robot deducts `commission_RCC` from the user's platform deposit and invokes `distribute_commission(commission_RCC, deal_table, deal_id)`, which executes the 50/50 split described in §5–6 inside a single database transaction. The split is therefore atomic with deal-saving: either the deal, the commission and all downstream payouts are recorded, or none are. ### 7.2 No commission on losses Loss-making deals incur no commission. The platform earns only when its users earn — a structural alignment that distinguishes RCC from subscription-based competitors. ### 7.3 Seasonal free access (promotions) To make onboarding risk-free, the algorithm runs **free of commission for one week** during two promo seasons each year: **1–31 January** and **1–31 July**. - **New accounts** that register during a season receive their first free week automatically — no RCC required. - **Existing users** do not receive a free week for themselves; instead they earn **one free week for every new client they bring** during the season. Four new clients therefore unlock a **full free month** of trading. The mechanic is intentionally seasonal — like a Black Friday sale — to concentrate growth around two predictable windows and to reward members who expand the network. Free weeks stack on top of the referral cascade described in §6. --- ## 8. Architecture ### 8.1 On-chain layer - **RCC token** (`TTgft2ySbTmVmxesi2hPZtpudhTt9NJjWk`) — TRC-20 implementation with `buy()` minting and standard ERC-20-like read/write functions. - **RCService** — staking logic, age coefficient, inactivity weight, one-up referral cascade. The off-chain mirror in `backend/referral/` is the literal arithmetic port. - **RCFactory** (`TWf7V9cWU2gnbzRQbM9KF6f9DB3DECiouv`) — root of the contract topology; deploys parameterised user contracts and validates `is_partner` claims. ### 8.2 Off-chain mirror RealColibri operates an off-chain backend that **mirrors** the on-chain rules with two motivations: 1. **Gas-free UX.** Users do not pay TRX gas for every stake / claim / referral payout — operations are recorded in PostgreSQL and settled in bulk where settlement is needed. 2. **Latency.** Trading robots cannot afford block-finality latency on every closed position. The off-chain ledger settles commission in milliseconds. To preserve the integrity of the model, the off-chain ledger is a **deterministic** function of the same inputs the on-chain contract would observe: every payout amount is reproducible from public data (deal log + stake ledger + referrer tree). A `RccPurchase` table mirrors the on-chain `buy()` event log, populated by a TronGrid event-listener. ### 8.3 Authentication Users authenticate with **TronLink wallet signatures** rather than passwords. The backend issues a nonce, the wallet signs it, the backend verifies the signature and issues a JWT. No email, phone, name or password is collected — there is nothing to leak, sell or steal, and the login cannot be phished. **Registration is wallet-only.** New accounts are created purely from a TronLink signature; there is no email/password sign-up. Legacy email/username login remains available for accounts that predate this change, but new password-based registration is no longer offered. This keeps user identity private and ties each account to a self-custodied wallet the user alone controls. ### 8.4 Trading API safety Every supported exchange enforces the following invariant in the integration layer: > The API key supplied by the user **must not** have withdraw > permission. The robot will refuse to start otherwise. This is enforced both at the UI guide level (visual instructions to disable withdraw during key creation) and at the API layer (rejection on `permissions` field where the exchange exposes it). ### 8.5 Unified trading engine (ports & adapters) RealColibri's exchange integrations are converging onto a single trading core. Historically each exchange (Binance, Bybit, OKX, Rithmic) ran its own robot with independently maintained strategy code, so every new capability had to be re-implemented per exchange. The platform is migrating to a **ports & adapters** (hexagonal) architecture: - A single **TradingEngine** encapsulates the platform's proprietary trading logic. That logic is **confidential and is not described in this document**; what matters architecturally is that it lives in one place and is expressed against exchange-agnostic domain types (`Candle`, `Ticker`, `Position`, `OrderRequest`, `Balance`). - Each exchange becomes a **thin adapter** implementing two interfaces: an `ExchangePort` (outgoing order commands) and an `ExchangeFeed` (incoming normalised market-data and account events). Exchange-specific concerns — contract size, position mode, channel naming, reconnect, rate limits — are isolated inside the adapter and never leak into the core. The benefit is operational integrity: a platform improvement is written once and applies to every exchange identically, eliminating the drift that arises from maintaining parallel implementations. The migration is incremental and gated behind feature flags; the battle-tested Bybit path is migrated last, and only after **replay-parity tests** prove the new engine reproduces the existing engine's behaviour exactly on recorded market data. This modernises the internal architecture while preserving the non-custodial, profit-aligned guarantees of §2. --- ## 9. Governance and Roadmap ### 9.1 Current state (2026 Q2) - ✓ RCC token live on TRON Mainnet with fixed 1 RCC = 10 TRX primary issuance (§4.2). - ✓ RealColibri platform live with Binance, Bybit, OKX, and Rithmic (global futures via Rithmic datafeed: CME, EUREX, SGX, ICE and more). - ✓ Off-chain staking + referral mirror operational; weekly cron distributing the staker pool. - ✓ Referral program available to **every** registered user from day one — personal referral link, direct/indirect tree, cascade payouts, claim. - ✓ Partner VIP tier with **2–20 % rank-based bonus** (2 % base + 1 % per partner in subtree, capped at 20 %), global cap of 10,000 active partners, sourced from `platform_balance`. - ✓ PWA installable on Android / iOS Home Screen, with Web Push notifications for referral payouts, deal close, low balance and partner bonus events. - ✓ Demo mode without TronLink — any visitor can explore the platform UI with a mock account before installing the wallet. - ✓ Wallet-only registration (TronLink): no email/password sign-up and no personal data collected (§8.3). - ✓ Guest preview of the Staking, Referral and Partner pages — visitors see the full interface before registering; actions activate on sign-up. - ✓ Seasonal free-access promotions twice a year, January & July — a free week for new accounts, plus a free week per new client an existing user brings, up to a free month for four (§7.3). - ✓ Feature and reliability parity across the Binance, Bybit and OKX integrations; users can stop their own robot instantly at any time. - ✓ Foundation of the unified trading core laid (exchange-agnostic domain types and port / feed interfaces — §8.5), behind feature flags. ### 9.2 Near-term (2026 H2) - **Capacitor-based Android app** in Google Play (iOS later, separate Apple Developer enrollment). - **Server-push backend (VAPID)** for real-time mobile notifications via FCM and APNs. - **Public DEX liquidity pairs** RCC/TRX, RCC/USDT-TRC on JustSwap and SunSwap, providing the price-discovery layer once the smart contract supply approaches exhaustion (§4.3). - **Cumulative migration of off-chain stake metadata to RCService** for fully verifiable on-chain claims. - **Unified trading engine rollout (§8.5)** — consolidating the per-exchange robots onto a single strategy core with thin exchange adapters, so new capabilities ship to all exchanges simultaneously. Rolled out incrementally behind feature flags and validated by replay-parity tests against the live engine; Rithmic adapter follows once its demo environment is provisioned. ### 9.3 Mid-term (2027) - **Additional broker integrations** — CQG and Trading Technologies for futures; Kraken and KuCoin for crypto. - **Cross-chain bridge (TRON ↔ Ethereum)** for broader exchange listings and integration with EVM DeFi. - **Partner DAO** — on-chain voting by partners on cap adjustments, rank curve, and incentive parameters. Removes the manual admin approval bottleneck. ### 9.4 Long-term - **Permissionless robot deployment** — third-party strategy authors publish algorithms on the platform and receive a share of generated RCC commission. - **RealColibri native exchange and blockchain.** Once the user base and trading volume justify it, RealColibri will operate its own order book and settlement chain. P2P RCC transfers between users will then become **fee-free** — the current TRX network fee paid on every TRC-20 transfer disappears, replaced by zero-cost on-chain operations within the RealColibri network. - **Decentralised order-book aggregation** across supported exchanges for best-execution routing. --- ## 10. Risks and Disclaimers - **Regulatory.** Cryptocurrency utility tokens are subject to evolving regulation in each jurisdiction. Users are responsible for compliance with local law. - **Market risk.** Automated trading involves loss of capital. Real Colibri does not guarantee profit. Users should test with small positions before scaling. - **Counterparty (exchange) risk.** While RealColibri itself is non-custodial, the underlying exchange holds the user's funds. Exchange-level failures (insolvency, hacks, regulatory action) are outside the platform's control. - **Smart-contract risk.** The RCC, RCService and RCFactory contracts have been internally reviewed but have not yet undergone formal external audit. An audit is on the roadmap before any public token sale event. - **Operational risk.** Off-chain mirror integrity depends on backend availability and database consistency. Postgres transactions are used to maintain atomicity; full Byzantine-tolerant replication is not in scope of v1. --- ## 11. References - TRON network: `https://tron.network` - RCC contract on Tronscan: `https://tronscan.org/#/token20/TTgft2ySbTmVmxesi2hPZtpudhTt9NJjWk` - TRC-20 standard: `https://github.com/tronprotocol/tips/blob/master/tip-20.md` --- ## Glossary | Term | Definition | | --------------------- | ----------------------------------------------------------- | | **Read & Trade key** | Exchange API key with order-placement permission but **no** withdraw permission. | | **Commission** | Per-trade fee in RCC, charged only on profitable closed deals. | | **Staker pool** | Accumulator of the 50 % commission share; distributed weekly. | | **Referral** | Open to every registered user from day one; collects 50% cascade upward through the referrer tree. | | **Referral cascade** | Upward traversal of the referrer chain, allocating the 50 % per `INACTIVITY_PERCENTS`. | | **Inactivity weight** | 0–4 score reflecting a referrer's recent activity, governing self vs upward share. | | **Partner** | VIP-tier user, approved by admin after the 100,000 RCC purchase threshold. Earns 2–20 % rank-based bonus from `platform_balance` on commissions across their entire subtree. | | **Partner rank** | Dynamic: `2 % + 1 % × count_partners_in_subtree`, capped at 20 %. | | **Partner global cap**| Maximum 10,000 simultaneously active partners across the platform. | | **Free float** | Post-issuance phase (§4.3) after the smart contract supply is exhausted: 1 RCC = 10 TRX peg ends, secondary markets determine price. | | **Recycling** | Commission RCC is never burned; it is routed back into circulation via stakers, referrers, partners and `platform_balance`. | | **Off-chain mirror** | Backend ledger reproducing on-chain `RCService` arithmetic deterministically. | --- *This document is the published v1.1. Section 4 defines the economics (no allocation, fixed 1 RCC = 10 TRX, free float on exhaustion). Any changes to numerical parameters require redeployment of the relevant on-chain contract. The latest version is always available at* `realcolibri.com/whitepaper/RCC_Whitepaper.md`. — The RealColibri Team