Planet — an on-chain commodity purchasing-power index.

This is the light summary. The complete edition — mathematics, basket table, worked simulation and technical appendix — is on the complete edition view.

1. Overview

Planet (PLT) aggregates the real prices of a basket of global commodities — energy, metals and agriculture — into an on-chain purchasing-power index (PPI), and expresses that index as a TEP-74 token on TON. A wallet can mint PLT by depositing value at the current PPI, and burn PLT to redeem against the basket.

Phase 1 status. Planet is a proof-of-concept synthetic index token. It holds no real commodity reserve and is not a fully-collateralised stablecoin. The full “1:1 commodity reserve” variant is a future phase that requires an RWA custodian and regulatory compliance.

2. Architecture

3. The index (PPI)

The owner configures a weighted basket — currently 14 commodities — and locks the base prices on-chain. A relayer submits signed per-asset prices; PlanetCore recomputes the PPI from the live basket. An asset flagged as frozen is excluded and the remaining weights are re-normalised; if nothing is active the index is undefined and minting is refused.

4. Mint / burn and fees

Minting deposits value and issues PLT at the current PPI, net of a tiered fee. Each fee is routed 30% burn · 50% reserve · 20% staking, less a 10% risk-fund carve-out. Burning goes through the TEP-74 jetton wallet and is mirrored back to core accounting so supply stays consistent.

5. Stability mechanisms

• Band circuit-breaker: minting is refused when the index is undefined, and blocked beyond a 15% deviation.
• Fee slope: fees rise above a 5% deviation; redemption is asymmetric and capped.
• Arbitrage incentive: a fee rebate when the index is rich, to pull it back.
• Stabilisation bonds & risk fund: absorb selling pressure below peg; part of each fee funds a risk reserve.

6. Oracle

Prices are sourced off-chain from two independent feeds, combined as a median, and signed with ed25519. PlanetCore verifies against an M-of-N signer set (distinct signers enforced) and applies guards: strictly increasing timestamps, a single-update price-jump limit, a freshness ceiling on minting, and automatic freeze on source divergence.

7. Governance

All privileged actions require the owner. Ownership is migrated to a timelock and routed through Propose → delay → Execute, giving holders a reaction window; the timelock’s owner should be a multisig for M-of-N plus delay. A staking token (PLTG) distributes fee revenue pro-rata and carries stake-weighted parameter signalling. The original DAO plan, and exactly what is live today, are set out in §9 of the complete edition.

8. Status & roadmap

• Now: TON testnet; contracts implemented and tested (239 tests); multi-source oracle live; key separation done.
• Next: third-party audit; multisig owner; production oracle sources; binding PLTG governance.
• Later: 1:1 commodity reserve via an RWA custodian, proof-of-reserve and compliance.

9. Disclaimer

This is a technical proposal and a proof-of-concept, not investment advice. It is not audited. Commodity prices are volatile and an early-stage index token may diverge materially from its theoretical PPI. Do not use with value you cannot afford to lose.

0. Status, scope and honesty

This document describes Planet v1.9, a working proof-of-concept deployed on the TON testnet. It is written to be falsifiable: every mechanism is marked implemented · design · future.

Red lines. PLT is a synthetic index token. It has no physical reserve, is not a stablecoin, and is not “fully collateralised”. Market price may diverge materially from the theoretical index. Nothing here is investment advice.

• 1. Problem & design goals
• 2. Architecture & contracts
• 3. The index: basket & PPI
• 4. Mint, redeem & fees
• 5. Stability mechanisms
• 6. CAM adapter layer
• 7. Oracle & price integrity
• 8. Rebalancing (RTRA)
• 9. Governance & the DAO plan
• 10. Tokenomics
• 11. Fund (tokenised ETF shares)
• 12. Trust & threat model
• 13. Evidence
• 14. Roadmap
• 15. Risks & compliance
• A. Worked simulation
• B. API reference
• C. Code excerpts (Tolk)
• D. Security & audit appendix
• E. Off-chain services
• F. Deployment & monitoring

1. Problem & design goals

• Single commodities (gold, oil) are volatile and concentrated; multi-commodity exposure is hard to hold on-chain.
• Inflation hedging exists, but there is no public, verifiable object equal to “one token = a basket of global commodity purchasing power”.
• Design goals: (i) a transparent index whose formula runs on-chain; (ii) a token redeemable through the commodity layer; (iii) failure isolation, so one bad feed cannot poison the whole index; (iv) no custodian in Phase 1; (v) every privileged change observable and delayed; (vi) no self-built exchange.

2. Architecture & contracts

2.1 Layer map

L4  Fund           tokenised ETF shares; subscribe/redeem at NAV             [implemented]
L3  Stability      tiered fees · elastic curve · arbitrage · bonds ·
                   risk fund · circuit-breakers                            [implemented]
L2  CAM            per-commodity adapter: price/vol/liquidity/risk state    [phase A]
L1  Core           basket · on-chain PPI · mint/burn · fees · redemption
                   mirror · governance basket ops                          [implemented]
L0  Reserve/RWA    physical & ETF custody · proof-of-reserve               [future]
(no self-built DEX/AMM; trades happen on external venues)

2.2 Contracts

2.3 Data, fixed point and the TVM

The TON Virtual Machine has no floating point. All arithmetic is integer fixed-point: the index uses a 1e6 scale (1e6 ≡ 1.0), the weight sum is 1e6, and reward accounting uses 1e12. Contract state lives in cells (≤1023 bits inline, ≤4 refs), so the asset map is stored in a dictionary reference. PLT is a TEP-74 jetton; the jetton minter is the single source of truth for supply.

2.4 Message flow

mint      user wallet ──Mint─────────────────────────▶ PlanetCore ──MintNewJettons─▶ PLT minter ─▶ wallet
burn      user wallet ──AskToBurn─▶ own jetton wallet ─▶ PLT minter ──BurnNotification─▶ PlanetCore (mirror)
prices    relayer ──SignedPriceUpdate(payload, sigs)─▶ PlanetCore   (anyone may relay; the signature is authority)
admin     owner ──TlPropose─▶ PlanetTimelock ──(wait delay)── operator ──TlExecute─▶ dest contract

3. The index: basket & PPI

3.1 The live basket (14 commodities)

The full design targets 20+ commodities, each class ≤15%, with global geographic spread. The live testnet basket holds 14; the futures column is the price reference and the ETF column the investable proxy for the future reserve phase.

Weights sum to exactly 100% and no single weight may exceed 15%; both are enforced on-chain on every price update. The v1 whitepaper listed an additional rubber (TSR20) line, which is not in the live basket.

3.2 Definition

Let assets be i = 1…n with weight w_i, locked base price P_i^base and current price P_i. Let A be the set of active (non-frozen) assets.

• Constraint: Σ_i w_i = 10⁶ and 0 ≤ w_i ≤ 150000.
• Re-normalisation — dividing by the active weight sum — is what makes a frozen asset disappear cleanly instead of silently biasing the index.
• Equation (2) is a safety property: an early implementation returned 1.0 when everything was frozen, which allowed minting against a fabricated index. It now returns 0 and minting is refused (§4.1).
• Target price: Price_PLT = PPI × USD_base, with USD_base = $1.00 at genesis — PLT tracks the ratio of the basket’s price to the locked base, not a fixed dollar.

3.3 Worked example

Take three assets A, B, C with weights 0.5 / 0.3 / 0.2 (encoded 500000 / 300000 / 200000), base prices 100 / 50 / 80, current prices 110 / 47.5 / 84:

(1c) is the consequence readers should internalise: excluding a falling asset raises the index. That is arithmetically correct — the remaining basket really is worth more per active unit — and is exactly why the freeze state is a governed, observable action rather than an automatic one.

4. Mint, redeem & fees

Let D be the value deposited, B the PLT burned, and f the fee rate for the current band.

4.1 Mint gating

(6) means the protocol never mints while the oracle is stale; (7) closes the frozen-basket hole. These are the only two “market” reasons a mint can be refused.

4.2 Fee routing

Why the reserve bucket is the largest: in the fully-backed future phase the reserve must grow at least as fast as the index, otherwise the collateral ratio decays. The v1 whitepaper used 45 / 30 / 25 (burn / reserve / staking); this is a deliberate re-weighting, not an oversight (§10.2).

4.3 The redemption path

Redemption is a jetton burn: the wallet sends AskToBurn to its own jetton wallet, which burns and notifies the PLT minter, which in turn notifies the Core so accounting stays mirrored. Supply is authoritative at the minter, never at the Core.

5. Stability mechanisms

5.1 Tiered fee and circuit-breakers

5.2 Asymmetry and arbitrage

Redemption is deliberately not symmetric with minting: exiting below peg carries an extra penalty (bounded by (10)), while minting below peg is what re-floats the index. When the index is rich the protocol pays a rebate so an external arbitrageur is rewarded for pushing price back toward PPI.

5.3 Risk fund

5.4 Stabilisation bonds

Below peg, holders can subscribe at a discount to be repaid a premium. Bonds are requested by the holder and settled by the operator — asking to redeem can never destroy a claim before it has been paid. Owner-opened, owner-priced, bounded.

5.5 Dual-track anchoring

5.6 Hard limits

Per-transaction limits (SetLimits), a global pause (SetPaused), and the >15% mint refusal are hard circuit-breakers that do not depend on incentives.

6. CAM adapter layer — failure isolation

Each commodity has a CAM (Commodity Adapter Module) emitting a standardised tuple (price, volatility, liquidity, riskState) with riskState ∈ {normal, caution, frozen}.

This is the core safety property: a single bad source, price or liquidity event is contained. The protocol propagates the state — raising fees, lowering limits, freezing one asset — rather than the error, so one commodity cannot poison the index. Adding or retiring a commodity does not require touching the core.

7. Oracle & price integrity

7.1 Sources

The relayer fetches each commodity from two independent sources (Yahoo Finance and Sina for the energy/metals complex), takes the median, and signs the result. If the two diverge beyond 2%, the asset is emitted as frozen rather than guessed.

7.2 Verification

7.3 Guards

7.4 Freshness model (two different clocks)

They are intentionally different. Stated plainly: with a daily push, minting is available within 6 h of a push.

7.5 Key management

Signer keys live in a set (SetSigner{index,key}); writing a slot revokes what was there, and SetThreshold{m} raises M. Rotation goes through the timelock, never directly. The price-signing key is deliberately separated from the owner key: a leak of the former can only submit guarded prices, never touch funds.

8. Rebalancing (RTRA)

• ΔA_i — value to trade in asset i; w_i — target weight; V_i — current holding; T — total reserve.
• Trigger: drift-based and risk-adaptive — a frozen asset is not traded, and high volatility / low liquidity raises the trigger threshold.
• Execution is deliberately out of scope: Planet does not build a DEX/AMM/order-book. On TON, trades would be routed to external venues (e.g. STON.fi, DeDust); the protocol only computes the target.

9. Governance & the DAO plan

9.1 What the original whitepaper (v1.0) planned

The first whitepaper specified a governance token PLTG, fixed at 1,000,000,000 units, with a published allocation and vesting schedule:

The DAO was to control, by PLTG vote:

• commodity weights w_i — “adjusted quarterly by DAO vote”;
• fee rates (stated range 0.3%–0.8%);
• the PPI deviation thresholds (±3% default);
• the choice of reserve custodian.

PLTG captured value two ways: staking dividends — a share of fees paid periodically in stable value — and voting power. Liquidity providers of the PLT/stable pool were to receive PLTG rewards. The roadmap scheduled DAO governance launch in Q2 2026. Anti-fragility commitments included spreading reserve assets across 10+ venues and a minimum collateral ratio of 105%.

The v1 fee split was 45 / 30 / 25 (buyback-burn / reserve / staking); the implemented split is 30 / 50 (+10 risk) / 20 — the reserve bucket was deliberately re-weighted upward.

9.2 What is live today

Honest summary. The economic layer of the DAO (PLTG staking and fee dividends) is implemented and tested. The decision layer is not: votes are advisory, and real parameter authority sits with the owner behind a 60-second timelock on testnet. Closing that gap — binding, executed proposals — is a deliberate design step, not a claim we make today.

9.3 Privileged actions and the timelock

Owner-gated operations: basket weights / add-asset, fee parameters, limits, oracle signer set, pause, and ownership itself. Ownership changes must themselves go through Propose → delay → Execute; a direct owner call is rejected. The delay is the holders’ reaction window, and the timelock’s owner should be a multisig (M-of-N plus delay).

9.4 Staking dividend mathematics

A classic reward-per-share accumulator. Note (22) floors: dust stays in the pool rather than being minted. Reconciling that dust is one of the things an auditor should check.

10. Tokenomics

10.1 Token system

10.2 Fee flow, v1 vs now

10.3 PLTG utility

• Staking dividends — a pro-rata share of fee revenue, paid in stable value.
• Governance — voting on commodity weights, fee rates, deviation thresholds and (in future) the reserve custodian.
• Liquidity incentives — the v1 design reserved emissions for pool LPs future.

10.4 Allocation & vesting

The v1 schedule (§9.1) stands as the intended distribution; it has not been executed, and the current supply sits with the deployer. It must be distributed before any binding governance, or the vote is meaningless.

11. Fund (tokenised ETF shares)

The Fund is the L4 wrapper: it issues shares against a basket of ETF positions at NAV, so holders get fund-style exposure rather than a purely synthetic index. Actions that move NAV (mint, custody changes) are custodian-signed under an M-of-N policy; redemption is trustless — the fund receives its own TEP-74 share tokens on a normal transfer notification and burns them, releasing the claim, without an operator having to co-operate.

12. Trust & threat model

• Owner-key compromise is the dominant risk; the delay is the only mitigation — hence multisig + a longer delay before mainnet.
• Hot-key compromise is bounded: prices only, inside the jump band and divergence freeze; funds are unreachable.
• Payload replay is defeated by the strictly increasing timestamp (eq. 17).
• By design, not fixed: the redemption mirror has no freshness guard (asymmetric with minting), the burn bucket is accounting-only, and proposals do not execute. These are documented, not hidden.

13. Evidence

• 239 tests / 19 files; coverage 95.9% lines / 85.1% branches / 91.8% score, with a CI gate that can only ratchet up.
• An emulation dry-run job validates the deploy scripts before any funds are committed.
• On-chain verification of the live testnet build: 14 assets, base prices locked, signer = the dedicated hot key, owner = the timelock, 14 prices written and read back identical.
• Independently reproducible from docs/deploy-runbook.md.

14. Roadmap

15. Risks & compliance

• Index divergence — with no reserve, market price may diverge materially from PPI.
• Oracle — source coverage and availability; the guards bound but do not eliminate this.
• Liquidity — thin at cold start, so the market price is manipulable.
• Compliance — enabling real mint/redeem constitutes a financial product and needs licensing/custody; Phase 1 deliberately avoids it.
• Mechanism limits — the stability toolkit is soft (fees, bonds, incentives); it is not a substitute for real reserves.

Appendix A — worked economic simulation

Reproducing the v1 simulation with the current mechanics. Scenario: the energy complex rallies and the composite index rises 4.5% — from 1.000 to 1.045 (per eq. 1b).

The v1 whitepaper’s own numbers (a 10% oil move, a 0.5% fee, 970,873 PLT for 1,000,000 in) have the same shape; what changed is the fee band and the routing. Note the fee is charged on the deposit, so the minted amount is monotonically decreasing in both the fee and the index — there is no path where a minter receives more than D/PPI.

Appendix B — API reference

On-chain interactions (mint, burn, stake, vote) are not REST calls: they are TON messages signed in the user’s own wallet and constructed by the Mini App. The API is read-only.

Appendix C — code excerpts (Tolk)

The v1 appendix carried Solana/Rust snippets. These are the TON equivalents that actually run, abbreviated for readability.

C.1 The index (§3)

// Re-normalised weighted mean over ACTIVE (non-frozen) assets, 1e6 fixed point.
fun computePpi(assets, count) {
    var num = 0; var den = 0;
    for (i in 0..count) {
        val a = assets.mustGet(i);
        if (a.riskState == FROZEN) { continue; }              // eq. (15)
        num += a.weight * (a.currentPrice * SCALE / a.basePrice);
        den += a.weight;
    }
    if (den == 0) { return 0; }                                // eq. (2): undefined, not 1.0
    return num / den;
}

C.2 Fee band (§5.1)

// Tiered fee + elastic slope; >15% is refused elsewhere as a hard breaker.
fun feeBpsForPpi(ppi) {
    val d = abs(ppi - SCALE);
    var f = BASE_FEE;                                          // 0.5%
    if (d > SCALE * 3 / 100) { f = 100; }                      // 1% at 3-5%
    if (d > SCALE * 5 / 100) { f = 200 + SLOPE * (d - SCALE*5/100) / SCALE; }   // eq. (9)
    return f;
}

C.3 Oracle verification (§7.2)

// Anyone may relay; the signature is the authority. Distinct signers via a bitmask.
fun handleSignedPriceUpdateN(msg) {
    val os = OracleState.fromCell(storage.oracleState);
    val h  = priceHash(msg.payload);
    var used = 0; var matched = 0;
    for (k in 0..n) {
        val sig = ...;
        for (j in 0..os.signerCount) {
            if (!((used >> j) & 1) && isSignatureValid(h, sig, os.signers.get(j))) {
                used = used | (1 << j); matched += 1; break;
            }
        }
    }
    assert (matched >= os.threshold);                          // eq. (16)
    applyOraclePayload(msg.payload);                           // eqs. (17)-(18)
}

C.4 Rebalancing (§8)

// Target trade per asset; execution happens on external venues, never in-protocol.
fun rebalanceDrift(assets, count, totalReserve) {
    for (i in 0..count) {
        val a = assets.mustGet(i);
        if (a.riskState == FROZEN) { continue; }               // never trade a frozen asset
        val delta = (a.weight - a.value * SCALE / totalReserve) * totalReserve / SCALE;   // eq. (20)
    }
}

C.5 Staking dividends (§9.4)

// Reward-per-share accumulator, 1e12 fixed point.
fun notifyRewards(r) {
    assert (sender == storage.owner && storage.totalStaked > 0);
    storage.accRewardPerShare += r * RPS_SCALE / storage.totalStaked;   // eq. (22)
    storage.accRewards += r;
}
fun pending(s) { return s.amount * storage.accRewardPerShare / RPS_SCALE - s.rewardDebt; }  // eq. (23)

Appendix D — security & audit appendix

D.1 TVM-specific properties

• No floating point ⇒ all invariant checks are exact integer comparisons; the classic float-rounding attack surface does not exist.
• No EVM-style reentrancy: a message handler sends an async message and returns; cross-contract calls cannot re-enter mid-execution. Correctness instead depends on state-before-send discipline, which the contracts follow.
• Bounces: every self-written contract implements onBouncedMessage and ignores bounced bodies, so a failure cannot be misparsed as a valid message.
• Arithmetic: values are bounded and subtractions are guarded (e.g. totalIssued ≥ face) so an underflow cannot wrap into a huge mint.
• Cell layout: the asset map is a dictionary ref, keeping the head cell under the 1023-bit limit as the basket grows.

D.2 The review register

A first-party review found and fixed 10 issues, each with a regression test: an undefined index returned 1.0 and permitted minting; timelock ownership could bypass the delay; a failed executed action could fail silently; a voter could unstake immediately; proposal spam; bond redemption could destroy a claim without payment; the bond premium was unbounded; and a supply underflow. Three further items are documented as by design (mirror freshness asymmetry, accounting-only burn bucket, advisory proposals) and four as hardening for the next version (per-asset staleness, sweeping parked TON, enabling M>1 threshold, wiring the fund).

D.3 What an auditor should attack

1. Manipulating the freeze state to profit from re-normalisation (eq. 1c).
2. Fee accounting: do the buckets reconcile with the actual token balance?
3. Payload encoding / domain separation: any ambiguity or cross-class replay?
4. Timelock: can dest/body be swapped between propose and execute?
5. Reward-per-share rounding: extractable dust, or a griefing path?
6. Supply identity (eq. 25) under adversarial ordering of mint/burn/mirror messages.

Appendix E — off-chain services

• Relayer — fetches both sources, medians them, signs, and pushes. Gated by a movement threshold (0.1%) with a heartbeat ceiling so a quiet feed cannot go stale. Costs roughly 0.0023 TON of gas per asset update.
• Proof-of-reserve future — the v1 design was a daily Merkle root of custodian holdings published so anyone can verify inclusion. Requires the RWA custodian.
• Cross-chain future — the v1 design used a bridge to widen distribution; not implemented.
• Public read API — see Appendix B; versioned, cache-friendly, with a health endpoint for the oracle.

Appendix F — deployment & monitoring

Disclaimer. This document is a technical proposal and a proof-of-concept, not investment advice. It is unaudited. PLT is a synthetic index token with no physical backing; its market price may diverge materially from the theoretical PPI. Do not use it with value you cannot afford to lose.