BTC Stock Protocol Whitepaper

BSP Treasury · BSP Treasury Platform
Decentralized RWA Treasury Economic System

BSP Treasury uses Real-World Asset (RWA) tokens as treasury reserves, with the first project adopting the NVDA stock token.

01. Abstract and Design Goals #

BTC Stock Protocol is dedicated to building a decentralized stock token treasury economic system driven by fair launch. The protocol distributes independent protocol tokens through public rules, accumulates qualifying transaction fees as stock token reserves, and regulates token supply with preset buyback ranges and maintenance mechanisms. Its goal is to align public participation, reserve building, and supply regulation.

The first instance, BTCNVDA, uses the existing NVDA stock token on the Robinhood Chain for pricing, payments, and treasury assets. BTCNVDA is a newly issued reward token of the protocol, possessing distinct contracts, utilities, and rights from the NVDA reserve. Holding BTCNVDA does not grant the right to redeem the treasury's NVDA at a fixed ratio.

The protocol draws inspiration from Bitcoin's timed issuance, supply cap, and halving imagery; issuance contribution is measured by actual qualifying fees. It does not implement Bitcoin's Proof of Work consensus, does not inherit the security of the Bitcoin network, and does not duplicate Bitcoin's production curve and halving cycle. For this instance, each round lasts ten minutes and halves every thirty days, all defined by its own code.

This whitepaper introduces BTCNVDA's asset structure, issuance rules, fee distribution, and treasury mechanisms, applicable to the version deployed as of 2026-09-06. For real-time rounds, balances, and execution progress, please check the BTCNVDA Project Directory; for subsequent development arrangements, see the Roadmap. Documentation updates will not alter the deployed contracts.

02. Protocol, Platform and Independent Treasuries #

BSP Treasury (BSP Treasury Platform, or BSP for short) is the platform brand, while BTC Stock Protocol is the full name of the protocol. The protocol layer defines asset identity, issuance, fees, reserves, and execution rules; the Launchpad is the client for discovering projects, understanding rules, and initiating future creations; each independent instance has its own Token, Hook, official pool, genesis time, and ledgers. BTCNVDA is the first instance, not a universal platform token covering all future projects.

"Fair participation" here means the public rules of the same instance apply to all participants, and genesis rewards are not allocated to creators. It does not imply everyone gets the same amount, nor does it eliminate differences in information, funds, tools, participation timing, or on-chain ordering. If the team participates during the public phase, they must also bear fees and compete through the same paths. Team participation and holdings should be based on verifiable on-chain records and public disclosures.

The current version adopts the actual architecture of ERC20 Token + Uniswap v4 PoolManager + Official Hook. BTCNVDA can be transferred according to the ERC20 standard; trading venues are not exclusively restricted by the web portal. Ordinary transfers and trades on other markets not bound to this Hook will not automatically incur this instance's fees or generate this instance's Work.

03. Assets, Participants, and Value Flows #

This diagram describes two parallel ledgers: fees enter treasury uses; Work determines new token issuance ownership. Issuance rewards are not a direct distribution of received NVDA to miners by share. Selling for NVDA relies on execution prices, slippage, fees, and available liquidity; it is not a fixed redemption against the treasury.

Future additions may include portals to swap ETH or USDG into NVDA, as well as experiences where stock tokens cover user-side gas fees via paymasters. Neither of these are currently connected production features. Underlying network gas still requires someone to pay ETH; actual costs across different exchange channels depend on quotes, slippage, and network fees.

04. From Genesis to Public Operation #

Each protocol round lasts 600 seconds, starting from the genesisTimestamp written during the actual construction transaction. This is the protocol's time unit, not the underlying blocks of Robinhood. The genesis starting point for the first instance is 2026-09-06 10:16:46 PDT, and the expiration of the 144-round period is 2026-09-07 10:16:46 PDT. Website or domain updates will not pause or restart this timeline.

Four Easily Confused Quantities #

The scheduled amount for the first 144 rounds is approximately 350,000 BTCNVDA, designated as the protocol's Protocol Owned Liquidity (POL), not a team reward. Rounding to integers in each round and pool injection conversions may leave dust amounts, thus it cannot be guaranteed that the actual injection is exactly 350,000. Genesis positions can sell tokens to participants during trading; a "locked position" does not mean the tokens inside will never be traded.

settleGenesis() can settle all ended, unsettled genesis rounds at once, up to a limit of 144 rounds, without needing manual transaction per round. It mints tokens and increases the pending injection amount. Independently calling flushPol() only attempts to inject the existing pending amount into the pool and will not settle genesis on its behalf first.

The beforeSwap during the public phase will first back-settle genesis, attempt to inject POL, and check that a non-zero POL injection has already occurred before proceeding with trading and Work processing. Therefore, the first successful public swap (including swaps used by auxiliary Miners) can complete settlement, pooling, and participation within the same transaction. The source code does not have an additional open() button; time expiration will not automatically send any on-chain transactions. If any step fails, the entire transaction state reverts.

References: GenesisModule, BTCStockHook.

05. Issuance Schedule, Work, and Claims #

The issuance cap is 21,000,000 tokens, each adopting 18 decimals of precision. 4,320 rounds constitute one issuance epoch, equivalent to 30 days. Epochs are calculated continuously from the genesis starting point and will not reset when public participation begins at round 144: round 4,319 belongs to epoch 0, and round 4,320 enters epoch 1.

In epoch 0, the scheduled reward per round is approximately 2,430.55555555 BTCNVDA. In epoch 1, it roughly halves to 1,215.27777777 tokens, halving successively thereafter. The scheduled amount is the round's maximum, not an actually guaranteed payout; unmet targets, rounding dust, zero participation, and unclaimed rewards will all cause the actual minted tokens to differ from the scheduled curve.

How Contribution Determines Rewards #

Work is the buy-side protocol fee recognized by this instance, accounted for in NVDA's smallest units; it is not CPU hashrate, ordinary deposit amount, total trading volume, or the net amount entering the buy wall after fee splitting.

Individual Round Reward = floor(Scheduled Round Reward × Individual Work ÷ max(Total Round Work, Target Round Work))

When total round Work is less than the target, participants still receive rewards proportionally, and the remaining scheduled amount will not automatically supplement any individual due to the passage of time. When total round Work exceeds the target, the denominator uses the actual total Work, and participating in competition will decrease the share corresponding to the same input.

For example: scheduled reward is 1,000 tokens, target is 100 units, you contribute 10 units. When total Work is 50, you get 100 tokens; when total Work is 150, you get about 66.67 tokens. This example only illustrates the allocation method and uses illustrative target values; the contract rounds down to the smallest unit.

The initial target for this instance is 0.010777023386140748 NVDA, with the raw integer being 10777023386140748. Reaching this target when there is no competition makes it possible to obtain the full single-round scheduled reward; it is not a minimum participation amount and does not include network Gas. The target only shifts right and halves with issuance epochs, and is not a dynamic difficulty value that increases upward based on demand. Demand feedback adjusts the fee rate in the next section.

When Rewards Are Credited #

While the current round is not ended, only estimates can be displayed. After it ends, users mint mature rewards into the beneficiary's wallet through a claim transaction. claim() processes up to 64 participation entries at a time; claimUpTo(maxEntries) allows limiting the batch size; settleFor(miner) can trigger settlement on someone else's behalf, but rewards are always given to the specified miner, not the triggerer. Rewards do not have an expiration time for claiming; longer histories can be claimed in batches to control the gas consumption of a single transaction.

The contract uses the participated round list and claimCursor to prevent duplicate claiming. After claiming, rewardOf can still return the corresponding historical calculated value, so one cannot use a "non-zero value" to judge that it has not been claimed. The project site reads at most 16 entries per page, displaying the subtotal of claimed and pending claims for this page; the wallet's BTCNVDA balance may also come from buys, transfers in, or transfers out, and should be viewed separately from cumulative mining rewards.

References: EmissionModule, BlockModule, DifficultyModule.

06. Ordinary Trading and Pure Mining #

Ordinary buys exchange NVDA for BTCNVDA spot and record Work according to this instance's actual buy protocol fee. Sells exchange BTCNVDA back for NVDA, charging a sell protocol fee, but do not generate the same buy Work. The current Hook supports exact input paths; exact output calls will be rejected. The fee basis for buys comes from the specified input amount, while for sells it comes from the positive NVDA output amount returned by the pool; the final user payment and receipt are determined by the actual settled difference and execution fee rate.

The "pure mining" plan is carried by a standalone pure-mining tool site or local execution tools, which are not yet publicly open; it is a restricted path for auxiliary executors to use the official pool. The official BTCNVDA project site currently provides status queries for Work, yields, and treasury, with trading portals planned for normal buying and selling, providing guidance for independent tools rather than building in pure mining execution. The currently frozen BTCStockMiner minimizes spot exchanges through extremely tight price limits, dedicating the main actual expenditure to qualifying fee contributions. Pure mining records contributions through the same fee and settlement rules of the official pool and has no privileged minting or direct Work writing interfaces. It may still incur a small amount of spot exchange and fee slippage; the protocol does not require users to first purchase spot with a fixed USD amount.

Budgets, Attribution, and Refunds #

The auxiliary tool first uses 99.5% of the budget as the nominal fee target, then estimates a specified gross based on the read fee rate, and executes the buy using a price limit of sqrtNow − 1. This is an execution construction method, not a 99.5% guarantee of actual Work. beforeSwap may adjust the fee rate first, so the actual payment, minimum contribution, and refund are determined by the execution results.

Work attribution encodes the beneficiary via explicit Hook data. When this exact channel is not provided, the fallback attribution for ordinary buys is the transaction-initiating EOA; smart wallets, bundlers, or intent executors might differ from end-users, and using these paths requires explicitly binding the beneficiary. The tool also checks for fixed chains, callback origins, reentrancy states, and precise token transfer-in/refunds to restrict authorizations from being misappropriated.

The current official project site provides on-chain status queries, while normal trading and claiming portals are not yet open; the official Miner addresses and available portals for independent pure mining tools are yet to be verified. Users can check the functional availability via the corresponding pages.

References: BTCStockMiner, BTCStockHook.

07. Dynamic Fee Rates and Fee Splitting #

The contract's initial stored fee rate is 3%, with a permitted total fee rate range of 1%–10%. This is not a long-term average, nor is it a commitment to charge a fixed 3% on every transaction. A lazy adjustment is executed only once during the next qualifying swap after at least 144 rounds have elapsed; it does not automatically send a transaction in the background every 24 hours, nor does it loop to back-adjust for every vacant window.

The system divides the buy Work since the last adjustment by the actual elapsed rounds to obtain the average contribution density. This mean is directly adopted the first time, and subsequently averaged with the old value (EMA weights 1/2 each). Comparing this smoothed value to the current epoch's target calculates an adjustment factor of 0.5x to 2x, before capping the final fee rate between 1% and 10%. Exact integer sequencing is in the appendix.

A special point about the first public transaction: The frozen version sets lastRetargetBlockIndex to 144 at construction, excluding the closed genesis period. Thus, if the first successful public swap occurs between rounds 144–287, the adjustment window has not been reached, and 3% is still used; if there are no successful public swaps until round 288 or later for the first trade (with the epoch target Work still non-zero), a zero historical density will adjust the 3% by a 0.5x factor to 1.5% prior to charging. This difference stems from the contract's adjustment rules. Actual Work depends on the execution round and fee rate at the time of execution, which may differ from pre-submission estimates.

30/70 Within Total Fees, Not an Additional Surcharge #

Every actual protocol fee allocates 30% to the platform first, leaving the remaining 70% to the project. From the project's share, up to 2% replenishes the keeper reserve, while the rest enters the pending buy wall ledger; all proportions are rounded on raw integers. The platform does not add an additional "1%" layer outside of this.

Using 100 NVDA of protocol fees as an example to illustrate splitting, and showing the effect of the keeper reserve cap on actual amounts:

The second row occurs because the keeper cap for this instance is only 0.04527 NVDA, meaning 1.4 NVDA cannot be deposited into an empty reserve all at once. For smaller fees, the usual 30% / 68.6% / 1.4% split is reflected when sufficient space remains: for example, with a total fee of 1 NVDA and an originally 0 reserve, they would be 0.3, 0.686, and 0.014 NVDA respectively. After a keeper reward is paid out, subsequent fees can continue to replenish it, but cannot exceed the cap.

The platform share accumulates in platformAccrued. Anyone can trigger a withdrawal, but assets are only paid out to the platform payee address fixed at construction; successful withdrawals are recorded in platformPaidOut. There are currently no announced distribution rules for platform tokens, governance, or platform revenue buybacks, and the current protocol does not provide related dividends or buyback rights.

When charging, the Hook obtains NVDA-denominated claims from the PoolManager and splits them into platform, project, and keeper purposes within its own ledgers; recording 30% to the platform does not mean an immediate transfer to the payee wallet for every transaction. claimPlatformRevenue() performs an independent claim action, burning the corresponding claims, withdrawing NVDA, and checking the actual balance increment of the fixed payee address. The project's pending network share is used for liquidity settlement when walls are built; thus, fee ledgering and external wallet transfers represent different funding states.

References: TollModule, DifficultyModule.

08. Treasury and 7-Tier Buybacks #

The treasury uses the designated share of NVDA to buy back the concentrated liquidity ranges of BTCNVDA. The seven tiers form a price range around a reference price; they are not seven fixed-price limit orders. The nominal drawdown references are 5%, 10%, 15%, 20%, 30%, 40%, and 50%; tick spacing, price alignment, and range widths will cause actual boundaries to differ from exactly these percentages.

The buy wall coordinates reserve utilization with supply regulation, rather than endlessly hoarding NVDA to its full extent. Buyback executions will consume reserve assets and acquire protocol tokens; burns happen during successful harvest or maintenance paths, not automatically upon every user's individual sell transaction. It has no fixed price support, net asset value redemptions, or principal guarantees.

How 7-Tier Funds Are Allocated #

The seven tiers are divided into three levels: the top three tiers, the middle three tiers, and the deepest seventh tier. The allocation of new fees references a coverage metric κ₃ composed of the existing funds in the deepest tier, the anchor price, and the circulating supply, while constraining the proportion allocated to the deepest level. When coverage is insufficient, the deepest level is prioritized; when coverage is adequate, new funds favor the top two levels; this is ultimately subject to the 40%–80% deepest-level regulatory constraints and per-transaction integer rules. It does not reshuffle all old positions by a fixed proportion every time.

When the anchor migrates, existing tier funds migrate according to their original tiers; newly added pending network funds are allocated separately. Amounts that cannot be safely posted or conversion dust are returned to the pending network ledger and cannot artificially create virtual depth without funds. The complete allocation, tiering, rounding, and liquidity conversions are governed by DefenseNetMath and DefenseNetModule.

Anchor and Maintenance Constraints #

The initial anchor uses a sealed price observation and a 30-minute reference window, with the conservative candidate tick also restricted by an immutable genesis tick. If the current spot has already crossed the first tier's safety boundary, the first maintenance will be rejected; keeper rewards can only be earned after price conditions are met and valid positions are actually formed. The first maintenance must actually form non-zero fund positions.

Subsequent normal anchors migrate along the direction of upward value, with maximum step limits per movement; a new epoch recovery path is reserved for specific "entirely empty and stalled" conditions. A complete crossing of the deepest buyback tier can also end the old epoch. These are state transitions under limited conditions and do not imply that buy walls can be unconditionally reset during a downturn or guarantee market recovery.

poke() completes harvest/partial settlement, re-anchoring, necessary migrations, new fund injection, and finally the keeper reward. After initialization, normal successful heartbeats must be at least 144 rounds apart and still satisfy other conditions. harvest() is used for positions that have met harvest conditions and does not pay the identical keeper bounty. POKE is not a prerequisite for trading to open, nor is there a pre-enabled production unattended maintenance service.

Different Ledgers Cannot Be Summed as "Total Withdrawable Assets" #

The protocol provides ledger conservation checks; they indicate which ledgers fees are allocated to, but do not prove that all positions can currently be cashed out without slippage. Rebuilding positions also has to account for actual prices, partial executions, and rounding tolerances.

09. Keeper Rewards and Execution Availability #

This instance fixes a single keeper bounty at 0.001509 NVDA, and the keeper reserve cap is 30 times this amount, which is 0.04527 NVDA. The actual payment per successful heartbeat is the lesser of the fixed reward and the current keeper reserve; a zero reserve can pay zero, and it will not mint NVDA out of thin air or misappropriate the platform share.

Rewards are paid only after all maintenance steps succeed; antecedent failures will revert along with the reward. What is claimed are ERC6909 NVDA claims inside the PoolManager, not direct ETH deposits, nor are they necessarily NVDA ERC20 balances already in external wallets. Holders must cash out the corresponding assets through an appropriate settlement path to realize them as spot tokens in a wallet.

The fixed reward does not automatically reprice with Gas, NVDA price, or execution complexity. It does not guarantee covering a single maintenance cost, much less prove the existence of an autonomous, continuously running third-party keeper network. Maintenance results are subject to successful transaction receipts and corresponding ledger changes; a pending transaction hash does not mean maintenance has been completed.

References: TollModule, DefenseNetModule, BTCStockHook.

10. Technical Architecture and Verifiability #

Project identities are generated using the chain ID, factory address, creator, and project key, without relying on name uniqueness. Tokens with the same name cannot substitute for on-chain identity. The current factory has a fixed NVDA and version profile, and creation calls require direct initiation by an EOA; hiding the creation portal on the public website does not mean only administrators can create on-chain. Creation capability is determined by the actual conditions of create(), and page feature statuses are disclosed separately from on-chain creation permissions.

The read-only layer reads and verifies block hashes at fixed block heights, preserving on-chain time and local observation time respectively; it marks as expired if over 30 seconds. Personal histories are paginated to a maximum of 16 entries per page to prevent full scans from impacting availability. Webpage balances, Work, fees, and buy walls cannot be patched together from unrelated points in time to form a seemingly consistent "real-time total".

Events provide the basis for subsequent indexing, including ProjectCreated, GenesisSettled, PolDeposited, WorkRecorded, RewardsClaimed, TollCharged, Retarget, TierFunded, KeeperBountyPaid, and platform claim events. The current page does not yet provide round-by-round execution and fee event indexing; therefore, the corresponding fields are explicitly marked as unavailable, not substituted with zero.

11. Available Features and Risk Boundaries #

The BTCNVDA factory, Token, Hook, and official pool have been deployed, with verification records for contract identities, running code, and genesis starting points. The project site supports fixed instance status and public account queries. Web portals for pure mining, trading, claiming, and continuous execution are not yet open, and complete compatibility with real wallet operations remains to be verified.

Core constraints include: supply caps and issuance formulas are fixed; genesis is not allocated to the team; buy fees correspond with Work; total fees enforce raw integer split conservation; budget and minimum Work checks; processed claim records do not issue doubly; only defined callback origins can enter settlement. These constraints are used to limit specific operations and accounting risks.

The protocol relies on the existing issuance, custody, upgrades, and transfer availability of NVDA; stock prices and token exchange mechanisms also have their respective boundaries. Reserves do not equate to directly acquiring shareholder rights. Competition, market prices, liquidity depth, chain congestion, fee variations, available routing, and keeper funds will all impact actual experiences and outcomes. Neither stock nor BTCNVDA appreciation is a protocol promise.

The code, parameters, and asset identities of the deployed instance are fixed. Subsequent versions may adopt new contracts and parameter configurations; documentation updates will not retroactively alter the rules of existing BTCNVDA.

12. Versions, Addresses, and Status #

Whitepaper Version: 1.2; Update Date: 2026-09-06. Applicable to the actual BTCNVDA Robinhood instance corresponding to the frozen release package u4-release-candidate-v0.1. The following are identities and fixed values, not balance sheets that will change with operation.

13. Technical Appendix: Exact Math #

The following formulas are calculated on raw integers with 18 decimals of precision. floor means rounding down to the nearest integer; right shift >> is executed as an unsigned integer. Decimals shown do not participate in contract calculations.

Time, Schedules, and Targets #

W = 10^18
H = 21,000,000 × W
b = floor((block.timestamp − genesisTimestamp) / 600)
e = floor(b / 4320)
scheduled(b) = floor((H >> (e + 1)) / 4320)   [e < 96]
scheduled(b) = 0                              [e ≥ 96]
target(e) = 10777023386140748 >> e            [e < 256]
target(e) = 0                                [e ≥ 256]
reward(b,u) = floor(scheduled(b) × work(b,u) / max(totalWork(b), target(e)))

If individual Work or total Work is 0, the reward is directly 0, preventing zero-denominator division. The per-round reward has already been 0 due to integer division starting from epoch 72; 96 is the safe upper bound for the source code's calculation range. The target for this instance is 0 from epoch 54 onward, but one cannot thereby assert that issuance also stops at the same epoch. When the target is 0, rewards are still calculated proportional to actual total Work; fee rate measurement continues, and fee adjustment logic freezes the fee rate at that time.

Integer Sequencing for Lazy Fee Retargeting #

lastRetargetBlockIndex initial value = 144   [Closed genesis period is not counted in the demand window]
elapsed = b − lastRetargetBlockIndex
Only when elapsed ≥ 144:
  measured = floor(windowWork / elapsed)
  ema = measured                            [First time]
  ema = floor((old ema + measured) / 2)        [Subsequent]
  Clear windowWork, and set lastRetargetBlockIndex to b
  If target(e) = 0, keep fee rate unchanged
  ratio = floor(ema × W / target(e))
  If ratio ≥ W: factor = W + floor((ratio − W) / 2)
  Else:        factor = W − floor((W − ratio) / 2)
  factor = clamp(factor, W/2, 2W)
  rawRate = floor(old fee rate bps × factor / W)
  First constrain to uint16 representable range, then clamp to [100, 1000] bps

The _maybeRetarget for the current swap runs before charging fees, and the new Work from this trade enters the next measurement window. When there are no transactions, the wall clock will not proactively update the stored fee rate. The adjustment factor halves or doubles at most each time, interacting with the final 1%–10% boundary.

Fee Splitting, Maintenance, and Conservation #

toll = floor(gross × rateBps / 10000)
platform = floor(toll × 3000 / 10000)
project = toll − platform
room = max(0, 0.04527 × W − keeperEscrow)
keeper = min(floor(project × 200 / 10000), room)
net = project − keeper
bountyPaid = min(0.001509 × W, keeperEscrow)  [After the entire poke succeeds]

gross takes values for buys and sells as defined in Section 06; pure mining's nominal gross and actual expenditures are calculated separately. Fee splitting does not shrink buy Work; the Work increment for qualifying buys remains the entire actual toll.

totalTollCollected = totalUnfilledEth + totalEthConverted + pendingToNet
                   + keeperEscrow + keeperPaidOut
                   + platformAccrued + platformPaidOut

Every term in this conservation equation uses the raw units of the NVDA ledger; burning BTCNVDA is not directly added into the NVDA equation. The network accumulation of fresh fees and recovered remainders are handled separately to prevent repeatedly re-posting and counting the same funds as new revenue.

7-Tier Prices and Deep Coverage #

Nominal drawdown d: 5%, 10%, 15%, 20%, 30%, 40%, 50%
Corresponding tick offsets: 540, 1080, 1680, 2280, 3600, 5160, 6960
lower_i = alignUp(anchorTick + offset_i, 60)
upper_i = lower_i + 60
F = max(0, totalSupply − totalPendingHbtc)
κ₃_WAD = floor(L3 existing NVDA × 2 × anchorPriceWad / F)   [F > 0]

When F is 0, execution branches to the maximal coverage value from the source code. Coverage reads the snapshot of existing positions before maintenance; the calculation of F does not deduct the cumulative polReserve, because tokens in the POL might have already been traded on the market. Price direction uses ticks of BTCNVDA per NVDA, meaning a drop in BTCNVDA price corresponds to a tick increase; the initial anchor constraint is also understood in this direction.

14. Terminology, FAQs, and References #

Will rewards be obtained automatically after the genesis period ends? No. Genesis time continuously elapses, but minting, POL injection, public participation, and claiming all require actual transactions meeting contract conditions. Public rewards depend on valid Work.

Must all users receive the same reward? No. Rewards depend on each round's schedule, valid Work, total round competition, and rounding; yields are not promised.

Is 3% the long-term fee and the fee for the very first trade? No. It is an initialization value; adjustments may trigger before execution, and the actual fee rate is subject to transaction execution results.

Does the buy wall guarantee that price or reserves only increase and never decrease? No guarantee. The buy wall uses reserve assets to buy back protocol tokens, hence the buyback itself consumes NVDA. Treasury activities and personal team holdings are recorded separately.

Is trading exclusively possible on the official website? The current Token is an ERC20, with protocol fees and Work tied to the official Hook path. The web portal does not constitute a market-wide exclusive restriction.

What features will be opened next? See Roadmap and Feature Opening Conditions, including pure mining participation, reward claiming, buying and selling, continuous execution, and treasury maintenance. Official trading and claiming statuses are on the project site; the availability of independent tools is subject to their separately announced portals and instructions.

The following source code corresponds to the issuance, fee, and treasury rules for this instance, and can be used to verify technical details:

• Factory, Token, Hook, Auxiliary Miner.
• Emission, Block, Genesis, Difficulty, Toll.
• DefenseNetModule, DefenseNetMath.

BTCStockFactory, BTCStockToken, BTCStockHook, and BTCStockMiner are technical identifiers in the source code and interfaces, retained by their actual names. Asset and contract identities are subject to their networks and addresses.

External background materials: Uniswap v4 Official Hooks Documentation, ERC-6909 Original Standard. These materials explain basic components and do not represent external institutions' certification or endorsement of BTC Stock Protocol.

This repository delivers the protocol reading pages; source code filenames are retained as rule references, and the contract and auxiliary tool source code is not included in this site package. When independent project site links and real-time data interfaces are unconfigured, the page provides no available external links or real-time readings.