SIMYSuper Intelligence Money

Documentation

Documentation

Brand ID

SIMY banner. Super Intelligence Money.

SIMY. Super Intelligence Money. Try your best to make a loss.Download

1. Executive summary

SIMY is a new experimental crypto concept designed using advanced Super Intelligence AI models to simulate the original mining, minting, issuance, and historical price behaviour of major cryptocurrencies, including Bitcoin (BTC), Ethereum (ETH), and Binance Coin (BNB) + other.

The protocol reconstructs simulated issuance records into protocol-managed lots, offers those lots at a fixed reserve price derived from historical price data, and records ownership through protocol escrow. SIMY lots are not real BTC, ETH, or BNB. They are simulated digital assets created within an independent protocol.

By combining AI-driven historical simulations with a new approach to crypto issuance and price mechanics, SIMY introduces a new crypto alpha experiment: a game where the objective is to try to make a loss.

The challenge is simple: can you actually lose?

The system has three core components and SI-Btc is used to explain the concept

  • a separate non-transferable pseudonym registry;
  • a versioned historical-data registry;
  • and an auction/escrow contract that accepts exact-reserve purchases and tracks weekly partner rewards.

The web frontend exposes registration, auction purchases, escrow positions, seller proceeds, historical data provenance, and claims.

2. Core design principles

  • Fixed-reserve purchase price: users pay the published weekly reserve exactly, in respective gas tokens or other tokens. A purchase below or above the reserve is rejected.
  • Immediate purchases via the weekend auction: a lot becomes unavailable for the rest of the current auction week (weekdays) after a successful purchase.
  • Resales: the previous holder receives the full resale purchase price as claimable. The buyer becomes the recorded escrow holder.
  • Escrow custody: SI-Btc lots cannot be withdrawn or transferred to an external wallet. Ownership is an internal protocol ledger position only.
  • Weekly treasury distribution: only proceeds from new lots sold during that week fund the 80/10/10 split. Resale proceeds are owed to previous holders and are not treasury proceeds.
  • Pull payments: sellers, partners, operations and developers claim their own ETH. Settlement does not loop over all users.
  • Transparent data: each weekly reserve record is associated with a dataset hash, URI and version.

3. Pseudonym registry (separate contract)

The pseudonym registry is deployed separately from the auction contract as it cover all SIMY (BTC, ETH, BNB) on the respective chain.

Base Chain example

  • Name registration is live on BASE chain. Registration price: 0.01 ETH
  • Registration is non-refundable; the payment is forwarded to the operations Safe.
  • Names are unique case-insensitively under ASCII normalization and are limited to 1–32 ASCII letters, digits, underscores or hyphens. Alice and alice are the same name. The original capitalization is what is stored.
  • A name is lifetime-bound to the registering wallet. It cannot be transferred, renamed, or recovered. One name per wallet is the rule. Another name needs another wallet. A lost wallet loses that name. This is intentional.
  • There is no owner. Nobody can pause registration, change the price, replace the Safe, or alter a name.
  • 1, l, and I are different names. 0 and O are different names. The registry does not treat them as the same.
  • There is no reserved-name list and no proof-of-personhood check. Another wallet can register another name. A squatted name cannot be reclaimed. The production fee is the cost of that registration.
  • Registration does not itself qualify a wallet for auction partner rewards. A wallet needs at least one successful purchase on that weekend.

4. Historical data and weekly reserves

The historical-data registry publishes a weekly record containing:

  • deterministic auction week ID;
  • reserve price in wei (ETH);
  • a dataset hash;
  • a public dataset URI;
  • a monotonically increasing version.

The auctions are SATURDAY & SUNDAY. The window is Saturday 00:00 UTC until Monday 00:00 UTC, which is the end of Sunday. It repeats every weekend and does not stop. The same published reserve (price) applies to every lot available during that auction. The reserve is snapshotted on the first successful purchase of the weekend so a later registry correction cannot change the price after sales have begun.

The public project date is 3 January 2027. The first auction is SATURDAY & SUNDAY, 9 and 10 January 2027.

  • PseudonymRegistry
  • HistoricalDataRegistry
  • SIbtcAuctionHouse

The auction contract does not open before 9 January 2027.

Historical-price policy

The first reserve is $0.00001 per BTC. There is no market price on 3 January 2009. The first widely published dollar rate is the New Liberty Standard print on 5 October 2009: 1,309.03 BTC = $1, about $0.00076392 per BTC. That figure is not inside a Bitcoin block. A block explorer can show it only by attaching an outside market feed.

A precomputed geometric path: $0.00001 on 3 January 2009, the published rate on 10 October 2009, and one smooth step on every Saturday between them. The last step is pinned to the published rate. After that weekend the reserve uses the archived market price, still labelled separately from the estimate. The path is calculated once and stored, so every weekend price is known before the first auction.

The historical-data pipeline is a protocol component, not a download script. It keeps separate records for blocks, daily issuance, exclusions, source observations, model prices, source-to-lot allocations, lots and weekly reserves. The on-chain datasetHash is the SHA-256 of the canonical sibtc.historical.v1 publication manifest. The registry stores that commitment. It does not prove the historical facts.

5. Lots and escrow lifecycle

  1. An authorized publisher creates a lot only after the offchain historical-data pipeline has accepted its metadata and eligibility status.
  2. Each lot ID can be created once. A source-outpoint hash cannot be reused.
  3. All existing lots are eligible for one purchase per auction week, subject to the published reserve and the wallet participation limit.
  4. A lot not purchased during the weekend remains available in the following week at the new week's reserve.
  5. A new lot's first successful purchase sends its price into that week's new-lot proceeds bucket.
  6. A resale purchase credits the full price to the previous holder's claimable seller balance.
  7. The buyer becomes the lot's new recorded holder in protocol escrow. The lot is not transferable to an external wallet.
  8. A lot cannot be purchased twice in the same week.
  9. The current implementation records internal escrow ownership. Internal escrow is a design choice over distribution of tokens as a security issue. This is NOT real Bitcoin or Ethereum. This is a game.

6. Wallet participation limits

The limit applies for the first 40 hours of the weekend, Saturday 00:00 UTC to Sunday 16:00 UTC. For the last 8 hours, Sunday 16:00 UTC to Monday 00:00 UTC, unsold lots are open. There is no per-wallet cap.

The lot list does not say whether a lot is new or a resale.

A resale is always paid in full to the previous holder. This payment is fixed and is not part of the 80/10/10 split. The contract enforces a 50-ID maximum per batch to limit gas. A wallet may make multiple batches until it reaches its total weekly limit.

7. Weekly treasury and partner rewards

Only the proceeds from new lots sold during a Saturday and Sunday auction fund that week's distribution:

  • 80% partner pool;
  • 10% operations Safe;
  • 10% developer Safe.

Resale proceeds are not included in the new-lot treasury pool; they belong to the previous holder. The partner pool is allocated proportionally to each wallet's total spending on successful purchases during the week. Weight includes spending on both new-lot purchases and resales, as agreed. A wallet with at least one successful settled purchase is a partner for that week. After the auction window closes, anyone may call finalizeWeek.