Documentation

Reserve Holdings (RHOLD) is a fixed-supply BEP-20 on BNB Chain. At launch, the token contract itself opened the PancakeSwap V3 pool and seeded 100% of the initial liquidity — not a deployer wallet, not a locker service, and not through a position-manager NFT that could later be transferred or sold. Every claim in this section and the next is checked against the launch transaction (tx 0x9444fa2a…d44355) and the pool's own event log.

This isn't a DAO, and the treasury isn't community-operated day to day. "Vote the next bStock" (see Governance below) is a real, on-chain, non-binding signal — not a claim that holders decide what gets bought.

One qualifier that applies to every claim in this document, stated up front rather than buried: see Upgradeability directly below before treating anything else here as permanent.

0x5C8fB70C1Ec327434F0AC05FcE3791c10436Cb60 is a proxy, not a standalone contract — confirmed by BscScan's own proxy detection, which shows its implementation living at a separate address, 0x776d3A522a9F61FD40eDE4604e870Ff288b53AeB. Every call to the token routes through to whatever contract that address currently points at.

That matters for everything else on this page: a proxy's admin can redeploy the implementation at any time, changing what burn() does, whether a mint function exists, how the liquidity position is handled — anything — while the token's address, balance history and holder base stay exactly the same. Every claim described elsewhere in these docs as "confirmed" or "verified" describes what the current implementation does, checked against a real cited transaction. None of it is a claim about what the contract can be made to do in the future.

As of this writing, upgrade control has not been renounced. The project has stated this is deliberate, not an oversight: the proxy is being kept upgradeable while testing is still underway, with the stated intent to renounce it once that's complete. We'd rather say that plainly here than let the confident, cited tone of the rest of this page imply more permanence than currently exists. This section will be updated the moment renouncement happens, cited the same way as everything else in this file.

RHOLD's entire supply — 1,000,000,000 — was minted exactly once, directly into the PancakeSwap V3 pool, as part of the single launch transaction. No RHOLD has been minted before or since that transaction.

• No transfer tax. Trading costs only the pool's own swap fee — the pool's PoolCreated event confirms a fee of 100 (PancakeSwap V3's units, equal to 0.01%) — not anything charged by the token itself on top.
• Calling burn(uint256) on your own balance does more than remove RHOLD from supply: the contract pays out a pro-rata share of every bStock the treasury holds, to you, in that same transaction — confirmed by a real, executed burn (tx 0xaa57e40d…ead9fb). See Treasury below for what that transaction actually shows.

A typical launch mints a position through PancakeSwap's NonfungiblePositionManager, which hands back an NFT. Whoever holds that NFT can remove the liquidity, and an NFT can be transferred, lost, or stolen like any other asset. RHOLD skipped that path: the token contract called the pool's mint() function directly, naming itself as the position's owner rather than routing through a position manager. This is confirmed directly by the pool's own Mint event in the launch transaction, which names owner as the RHOLD token contract's address — not a wallet, not a locker contract, not an NFT.

The position was seeded single-sided — RHOLD only, no BNB — from just above the launch price up to the maximum tick PancakeSwap V3 allows. BNB coming in from buys accumulates as trading fees rather than sitting idle in the position.

The token contract collects those trading fees itself, directly, in BNB. On the very first trade after launch, in that same transaction, it called the pool's burn(0) — a zero-amount call that updates accrued fees without removing any liquidity (amount, amount0 and amount1 in that Burn event were all exactly 0, meaning nothing was withdrawn) — then collect(), pulling the fee out as WBNB. That sequence is live and automatic, not a manual or planned step.

What that one transaction doesn't settle by itself: whether this same contract could ever call burn() with a non-zero amount — meaning withdrawing the underlying liquidity itself, not just collecting fees earned on it — for anyone, including an owner, or whether that's not possible for anyone at all. The position is confirmed owned by the contract rather than a wallet; whether the contract's code exposes any path to move the principal is a separate question addressed honestly in Security below, not rounded up here.

bStocks the treasury acquires are held directly at RHOLD's own contract address — there is no separate vault contract. That means anyone can check exactly what's held, and how much, on BscScan's "Tokens" tab for that address, at any time, rather than trusting a claimed figure.

The design: every trade against the RHOLD pool generates a swap fee, the token contract harvests that fee in BNB (confirmed live and automatic, from the very first trade — see Liquidity above), and that BNB is what funds buying a basket of bStocks, landing at the same treasury address anyone can already check. Fee in, bStocks out, same contract the whole way — not a separate keeper wallet or a converter contract handling money in between.

What's independently confirmed on-chain versus what's the documented design, stated plainly: fee harvesting into BNB is proven, cited above. bStocks arriving at the treasury is proven — the redeem transaction below shows four of them sitting there and being paid out. That the harvested BNB specifically is what purchases those bStocks — as opposed to some other funding source — hasn't yet been observed in a cited transaction the way everything else on this page has. We'll cite that transaction the first time we see it, the same way as everywhere else here, rather than round the design up to a confirmed fact ahead of proof.

Redemption is confirmed live. In tx 0xaa57e40d…ead9fb, a holder called burn(185,458.208224…) on their own RHOLD balance, and in that same transaction the token contract sent them a pro-rata share of every bStock the treasury held at the time — CRCLB, NVDAB, SNDKB and MUB all moved from the treasury address to the burner's wallet, cited directly from that transaction's logs, not described ahead of proof. This site's Redeem button calls the same burn(uint256) function.

One thing that transaction doesn't settle: the exact formula the contract uses (share of supply at the instant of the burn, rounding behavior, and so on). The site's own "you will receive" preview is a client-side estimate computed the same simple way — your balance's share of total supply, times current holdings — not a call into the contract's own math, so treat it as an estimate rather than a guaranteed quote.

Any wallet holding at least 100,000 RHOLD can cast a non-binding, on-chain vote for which blue-chip stock the reserve should prioritize once Binance issues a bStock for it. Voting is gated by balance at the time of the vote, not by staking or locking tokens — you keep full custody and control throughout.

This is a signal, not a binding instruction: the governance contract has no access to RHOLD or the treasury, and can't cause anything to actually be bought. It only reads RHOLD's balance to decide who's eligible to vote.

Directly verified on-chain, cited by transaction above: the liquidity position is owned by the token contract's own address, not a wallet or an NFT; fee collection into BNB happens automatically, confirmed on the first trade after launch; the full supply was minted exactly once, at launch, straight into the pool; burning RHOLD pays out a pro-rata share of the treasury's bStock holdings to the burner, confirmed by a real executed burn. See Upgradeability above first, though: every item in this list describes the current implementation behind the token's proxy, not a permanent guarantee, until upgrade control is renounced.

Not yet independently confirmed: the contract's source hasn't been reviewed line-by-line here, so stronger claims — "no owner can ever withdraw the liquidity," "no mint function exists," "nothing is pausable" — aren't things this page stands behind with the same confidence as the paragraph above. We'd rather list that as an open question than round it up to something it isn't yet.

Also open: a professional third-party security audit, and securities-classification legal review. Neither has happened. Read everything on this page as "verified against a cited on-chain transaction where a citation appears" — not as a completed audit.

• The token is upgradeable and upgrade control has not been renounced yet (see Upgradeability above) — until it is, an admin key can change how this contract behaves, including everything else described on this page.
• Custodial trust, one layer up: bStocks are ultimately backed by Binance/BTech Holdings' Abu Dhabi SPV custody, tracked via Binance's Proof of Collateral — this is "verifiable," not "trustless."
• PancakeSwap liquidity for individual bStock pairs may be thin, especially for newly issued ones — large trades can have real price impact regardless of the on-chain behavior described above.
• Not community-governed beyond the non-binding vote described above.
• Redemption pays out whatever the treasury holds at the moment you burn — if it holds little or nothing of a given bStock, your share of that asset is little or nothing too. See Treasury above for how to check current holdings before redeeming.
• RHOLD represents a claim on a reserve of tokenized-equity exposure. This page is informational only, not financial or legal advice, and nothing here is an offer to sell securities.