# BTC Stock Protocol Technical Roadmap

**BSP Treasury · BSP Treasury Platform**  
Decentralized RWA Treasury Economic System

BSP Treasury uses real-world asset (RWA) tokens as treasury reserves. The first project uses NVDA stock tokens.

## 01. Objectives, Scope, and Current Status {#scope}

BTC Stock Protocol is built around a stock-token treasury and provides economic mechanisms for public issuance, contribution accounting, reward claims, and rule-based buybacks. This technical roadmap explains how those rules connect to user actions, and the conditions under which later features will open.

**The BTCNVDA Factory, Token, Hook, and official pool have been deployed on Robinhood.** The BSP Treasury protocol/Launchpad site and the standalone BTCNVDA project site currently provide rule reading, project discovery, and on-chain status queries; web trading, reward claims, public creation, and continuous execution are not yet open. Pure-mining planning is carried by the standalone pure-mining tool site or local execution tools and is not yet publicly open; the official project site currently provides status queries, and later trading entry points will be used for ordinary buys and sells and the corresponding Work contribution.

The technical roadmap version is 1.2, updated on **2026-09-06**, and applies to BTCNVDA on Robinhood chainId 4663. The deployed instance version identifier is `u4-release-candidate-v0.1`. Issuance and economic rules are detailed in the [Protocol Whitepaper](/protocol/docs/whitepaper/); website updates do not change contract rules.

## 02. Technical Architecture: Four Cooperating Parts {#architecture}

```flow
On-chain rules | Factory, Token, Hook, and the official PoolManager record assets, issuance, and treasury state.
Execution tools | Complete trades, claims, refunds, or maintenance within authorized bounds; pure mining is provided by standalone tools.
Public data | Read state and events by block, annotating source, time, and confirmation results.
User entry points | The protocol/Launchpad provides rules and project discovery; the project site provides trading, rewards, and treasury entry points.
```

Asset and transaction outcomes are determined by on-chain rules; pages are responsible for display and operations. After a transaction is submitted, the success receipt and the corresponding ledger changes together describe the execution result; a transaction still waiting for confirmation may still fail. The two sites currently provide read-only functionality.

### Fixed Instance and Website Updates {#fixed-instance}

BTCNVDA's genesis time, parameters, and addresses are fixed at creation. The same instance's asset identity, genesis ledger, and participation history are retained continuously; a website redesign or domain change does not reissue the token. A new contract version corresponds to a new instance identity and should be identified separately from the existing instance.

The current instance uses ERC20 + Uniswap v4 Hook, denominated in NVDA. BTCNVDA can be transferred under the ERC20 standard; this instance's protocol-fee and Work rules apply to trades that pass through its official Hook.

### Components and Public Interfaces {#interfaces}

| Component | Core inputs | User-verifiable results |
|---|---|---|
| Factory | Fixed configuration, creation code, and project metadata | Project creation events, Token/Hook/official-pool identities, and genesis time. |
| Hook and issuance module | Official swap, effective fee, rounds, claim requests | Toll, Work, reward-claim records, cumulative minting, POL, and fee splits. |
| Buy-wall module | Price observations, funds awaiting allocation to buy walls, existing positions | Tiers, anchors, conversions and burns, fund ledgers, and limited maintenance rewards. |
| Standalone pure-mining tool | owner budget, fixed beneficiary, minimum Work | Actual payment, Work increment, a small spot output, and refunds. |
| Read-only layer | Fixed instance, block height, public accounts, and page numbers | Snapshots with timestamps and block hashes; missing data is marked unknown. |
| Client | User-selected project and action | Rules, feature status, and result display; corresponding confirmation is provided after execution features open. |

The current factory fixes configuration such as the NVDA reserve, platform payee, initial tick, target Work, keeper rewards, and creation bytecode. Project identity combines chain ID, factory, creator, and project key; same-name projects do not share identity. `create()` requires an EOA to create directly; smart-wallet or sponsored creation is not currently supported. The website creation entry is not yet open; on-chain creation permission is still determined by contract conditions.

## 03. Status Queries and Fund Accounting {#data}

### How to Read Status Snapshots {#snapshots}

The read-only service checks the network, contract identity, running code, and genesis parameters, reads primary state at the same fixed block, and verifies the block hash. Detail queries separately annotate the sampled block; if it differs from the primary snapshot, the page lists each source and time.

Data older than 30 seconds is shown as stale, and countdown estimates pause. Remaining-time figures that change every second on the page do not represent new trades, minting, Work, or POL. On connection failure, network mismatch, data-source error, or an unconnected account, the related data is marked unknown.

Personal history is paginated at a maximum of 16 entries, showing participation rounds, Work, rewards, and claim status. Statistics on the current page are that page's subtotal; wallet balance is listed separately. Later full-history queries will annotate the index coverage interval and the last confirmed height.

### What Each Fund Figure Represents {#accounting}

| Displayed item | Meaning |
|---|---|
| Genesis accrual | Planned amount for completed genesis rounds; actual minting still requires a settlement transaction. |
| `polReserve` | Cumulative amount of minted genesis BTCNVDA. |
| `polDeposited` | Cumulative BTCNVDA amount that has entered POL; it does not represent the balance still in the pool. |
| Platform share | Accrual ledger backed by the corresponding claims in PoolManager; only after a successful withdrawal does it enter the fixed payee wallet. |
| Buy-wall funds | Pending onboarding balance, maintenance ledger, and actual liquidity positions are shown separately; exit value is affected by price and fills. |
| Keeper rewards | NVDA claims obtained after successful maintenance; they become wallet spot only after redemption. |
| User rewards | Counted from matured rounds and claim records, and distinguished from account balances that may include buys and inbound transfers. |

## 04. Wallet, Authorization, and Execution Boundaries {#wallet}

The current pages request only public account and network information, preferentially discover OKX Wallet, and are compatible with standard EVM wallets. Allowed methods are only `eth_accounts`, `eth_requestAccounts`, and `eth_chainId`; they do not automatically switch chains, sign, approve tokens, or send transactions. Full compatibility of real-wallet execution features remains to be verified.

Later transaction confirmations will display and bind **network, target contract, amount, asset, beneficiary, minimum result, validity period, and fee bounds**. After changing the amount, switching project or network, or updating a quote, reconfirmation is required. The authorization scope of a delegated-execution service must not exceed the conditions confirmed by the user.

When the account changes or disconnects, the page clears the old account data; new read results correspond only to the current account. This avoids showing another person's historical results after an account switch.

In the standalone pure-mining tool, the owner funds the operation and receives refunds and a small amount of spot; the beneficiary receives Work and subsequent issuance rewards. The two may differ and should be checked when using the tool. Gas is still paid in ETH by the party executing the transaction; unifying payment in NVDA in the future would require an additional sponsorship or conversion service.

## 05. Current Features and Openness Status {#baseline}

| Feature | Status | Scope of use |
|---|---|---|
| Issuance, fee, and treasury contracts | Deployed | Fixed rules run on the BTCNVDA instance on Robinhood. |
| Protocol/Launchpad project directory | Readable | View the first project, rules, and feature status; the public creation page is not yet open. |
| BTCNVDA project site | Readable | Query protocol rounds, genesis, treasury, and bounded personal history. |
| Whitepaper and technical roadmap | Readable | Online table of contents, stable section links, Markdown download, and print. |
| Standalone pure-mining tool | Not yet open | The official executor address and usable entry points remain to be verified; the official project site does not embed pure-mining execution. |
| Web trading and reward claims | Not yet open | Quotes, authorization confirmation, and actual receipts will be provided later. |
| Continuous execution, recovery, and maintenance services | Planned | Open conditions are limited budget, state checks, and stoppable authorization. |
| Public creation, multi-asset, and multi-chain | Planned | Open according to factory capabilities and each network's independent conditions. |

The genesis start is fixed at **2026-09-06 10:16:46 PDT**; 144-round expiry is **2026-09-07 10:16:46 PDT**. Expiry is a contract time condition; actual public trading still requires completing genesis settlement and POL injection. The times above do not mean that all product features open at the same time.

## 06. Later Features and Open Conditions {#milestones}

The following stages are ordered by primary dependencies. Feature opening is based on actual addresses, executable operations, and verifiable results; specific status is updated at the corresponding entry points.

### M1 · Standalone Pure-Mining Tool and Fee Estimates {#m1}

The standalone pure-mining tool site or local execution tool will provide budget, fee estimates, minimum Work, and beneficiary confirmation. The tool is separate from the official project site; the official site may provide explanations or jump guidance. Ordinary buys likewise obtain Work from qualifying fees on the official Hook.

Before opening, the official executor and its bound chain, PoolManager, Hook, Token, and NVDA must be confirmed. A successful execution should settle within budget, with Work going to the beneficiary and refunds and a small amount of spot going to the owner; on an error callback, budget overrun, or insufficient minimum Work, the entire transaction is rejected.

Fee estimates must account for the fee-adjustment window at fill time: the first public swap in rounds 144–287 uses 3%; if the first swap occurs in round 288 or later and the current target Work is still nonzero, zero historical density first adjusts the rate to 1.5%. Minimum contribution is determined by the actual execution result.

### M2 · Public Trading and First Participation {#m2}

Users will be able to participate in BTCNVDA through the official trading path. The first public trade can, in the same transaction, settle genesis, inject POL, and record valid Work; independent genesis settlement and injection may also be performed first.

Open conditions include 144-round time expiry, valid POL, and an executable official swap path. `flushPol()` only injects the existing pending-to-pool amount and does not automatically settle genesis first. Pages will distinguish genesis accrual, minted, pending-to-pool, deposited, and public-running status; a failed trade does not increase user Work or balance.

### M3 · Matured Rewards and Batch Claims {#m3}

Users can view per-round contributions, pending-to-mature rewards, and claimable amounts, and initiate claims after a round ends. Default `claim()` processes at most 64 records per call; a bounded batch interface may also be used to choose how many to process.

Open conditions include claim results matching the freeze formula, already-processed records not being paid again, and delegated settlement always delivering rewards to the original beneficiary. The rewards page will list pending-confirmation and claimed statuses and the corresponding transactions; page subtotals and full-history statistics are annotated separately.

Wallet balances are also affected by buys and transfers, so reward-arrival records will be based on claim events and the processing cursor.

### M4 · Limited Continuous Execution and Interrupt Recovery {#m4}

Continuous execution will allow users to set round count, per-round and cumulative budgets, validity period, and a manual stop condition. A single authorization does not automatically expand into an unlimited budget; specific permissions are confirmed before start.

This capability assumes that single-round participation and claims are reliably available. On lost responses, node timeouts, or restarts, the service first checks existing transactions, then decides subsequent actions. When state is unknown, new debits are paused; when fees or participation conditions change, the budget is rechecked.

Run records will show each round's actual payment, Work, refunds, and confirmation status. Continuous pure mining remains carried by standalone tools and is not mixed with the official project site's ordinary trading entry as the same feature.

### M5 · Treasury Maintenance and Buyback Records {#m5}

The treasury page will provide more complete records of wall building, buybacks, harvests, burns, and maintenance rewards, helping users understand how reserves are used for supply adjustment.

The first wall build requires a valid price observation, funds awaiting allocation to buy walls, and a safe anchor, and must actually form a nonzero position; it is rejected when the current price crosses the first-tier safety boundary. After initialization, a normal heartbeat is at least 144 rounds apart and must still satisfy other contract conditions. A successful `poke()` finally pays `min(0.001509 NVDA, keeperEscrow)` in claims; `harvest()` does not pay the same heartbeat reward.

Opening the maintenance service also requires recovery of generation, anchors, positions, and transaction state after an interrupt. Ledgers, position valuations, claims, and wallet spot are presented separately. The fixed reward does not guarantee covering network costs; continued availability of the maintenance service still depends on execution cost and funding conditions.

### M6 · Buy/Sell Quotes and Optional Payment Assets {#m6}

The official project site will provide ordinary buy, sell, Work contribution, and fill queries. The confirmation page lists amount, protocol fee, network fee, minimum received, quote validity period, and remaining quantity on a partial fill.

Before opening, actual quotes, price limits, wallet confirmation, and result checks must be completed. Changes to amount, network, or quote invalidate the previous confirmation; expired, tampered, and duplicate requests should be rejected.

Later, an ETH/USDG-to-NVDA conversion entry may be added. Routing compares executable quotes, slippage, Gas, and failure handling; obtaining a quote does not mean a fill has occurred. Unified payment in stock tokens is an additional service; underlying Gas is still paid in ETH by the executing party.

### M7 · Full History and Continuous Status Queries {#m7}

Full history will cover per-round participation, claims, fees, and treasury activity since deployment, and will annotate the coverage interval and last confirmed block. Users will be able to inspect the corresponding on-chain records from the statistics.

This capability requires event indexing, reorg handling, breakpoint recovery, and ledger reconciliation. Historical backfill and new events should avoid double-counting; temporarily missing data is marked unknown; a disconnect does not equal transaction success or failure.

Continuous status services and continuous trade execution open separately. Long-term page availability does not mean that an account has authorized unattended operations.

## 07. Platform and Ecosystem Expansion {#ecosystem}

### Public Creation Entry {#creation}

Launchpad will provide project metadata, rule confirmation, predicted addresses, and creation-result queries. The first stage is based on the existing fixed factory and only accepts the NVDA reserve and configuration it supports; creation calls require an EOA to initiate directly.

Open conditions include clear creation fees and signed content, handling of duplicate identities, failure-result feedback, and on-chain instance verification. The same project name does not mean the same asset; users should check the network and contract identity.

### Multi-Asset and Multi-Chain {#multichain}

Robinhood is the first network with a deployed instance; the project is in progress. BSC is not yet open; Solana and X Layer are in planning. BSC and X Layer are each constrained by chain parameters, PoolManager/Hook support, contract size, reserve assets, and trade-execution capability; Solana requires separate adaptation and verification, and currently has no deployed instance or committed open time.

The existing factory is fixed to NVDA. Adding a stock token requires checking decimals, transfer behavior, pause/upgrade, settlement, and unit conversion, and adopting the corresponding new configuration or version. Existing BTCNVDA is not changed retroactively.

Each chain's project identity and treasury are independent; signatures bind chainId and the specific contract. Cross-chain bridges, unified balances, and shared treasuries are not currently provided.

### Independent Products and Governance {#future-products}

Ecosystem plans include the protocol official site, standalone project sites, Launchpad, and a trading client. Two entry points are currently accessible: protocol/Launchpad and BTCNVDA. In the future, dedicated product flows may be provided separately while citing the same instance and rules. The standalone pure-mining tool is a separate execution tool and does not replace the official project site.

Governance, a platform token, and platform-revenue buybacks have no published rights or allocation rules. If introduced later, the corresponding permissions, scope of application, and funding sources will be disclosed separately and will not automatically change the rights of existing BTCNVDA holders.

## 08. Feature Opening and Information Transparency {#verification}

### How to Judge Whether a Capability Is Available {#completion}

| Status | Meaning for users |
|---|---|
| Planned | Describes the objective and scope; currently not operable. |
| Under verification | Function and failure handling are being confirmed; test results are not equivalent to official availability. |
| Contract deployed | On-chain address and code exist; this does not mean all client entry points are open. |
| Operation open | The corresponding page can confirm and submit the operation; execution results are determined by the on-chain receipt. |

Open conditions for fund-related features cover fee changes, halvings, batch claims, duplicate requests, expired signatures, partial fills, first wall-build failure, chain reorgs, and disconnect recovery. Code review and tests help verify these conditions, but they do not constitute independent audit certification or a yield guarantee.

Each formally opened feature should provide the applicable network, contract identity, rule version, fee description, result queries, and known limitations. Unknown or pending-confirmation states are presented separately from successful results.

### Reading the Rules and Viewing Runtime Status {#publication}

The whitepaper and technical roadmap provide a complete table of contents, stable section links, Markdown download, and print. Readers can jump between the two documents or return to Launchpad to view projects.

The documents describe fixed rules and feature status; in-progress rounds, balances, and treasury activity are determined by the project site's reads annotated with a block. When a snapshot is stale, a prompt is shown; document updates do not modify on-chain rules.

## 09. Fixed Parameters and Related Materials {#references}

| Parameter | Fixed rules for this instance |
|---|---|
| Assets | Payment/reserve NVDA; reward BTCNVDA; network Gas uses ETH. |
| Issuance cap | 21,000,000 × 10^18 raw units; actual minting is not guaranteed to reach the cap. |
| Time | 600 seconds per round; first 144 rounds are genesis; every 4,320 rounds is an issuance epoch. |
| Initial target Work | 0.010777023386140748 NVDA, halved by right-shift each epoch. |
| Fee rate | Initialized at 3%, with 1%–10% bounds; post-expiry swap updates are lazy, not a fixed 3% per trade. |
| Split | Of the total fee, 30% platform, 70% project; of the project share, at most 2% tops up maintenance, subject to a cap. |
| Keeper | At most 0.001509 NVDA claims per call; reserve cap 0.04527 NVDA. |

Exact formulas, the 100 NVDA total-fee cap worked example, complete addresses, and transaction identifiers are governed by the [whitepaper technical appendix](/protocol/docs/whitepaper/#math) and the [version and deployment table](/protocol/docs/whitepaper/#deployment). For live status, see the [BTCNVDA project site](/protocol/#project-directory); for project discovery, return to [Launchpad](/protocol/#launchpad).

Core source identifiers: `Factory`, `Hook`, `Miner`, `Emission`, `Block`, `Difficulty`, `Toll`, `Genesis`, `DefenseNetModule`.

This repository delivers the protocol reading pages; source filenames are retained as rule references. Contract and auxiliary-tool source code is not included in this site package. When standalone project-site links and live data interfaces are not configured, the pages do not provide usable outbound links or live readings.