How Binance World Assets works

Binance World Assets (RWA) is an experimental protocol on BNB Chain (chain ID 56) where depositors place a tokenized stock together with USDT stablecoin backing into a shared Standard Pool. Acquirers pay a single acquisition price to receive one randomly selected position from the pool, and the depositor of that position is settled in return.

The protocol's defining feature is inverse weighting: the less USDT backing a position carries, the more likely it is to be selected. Backing therefore acts both as a self-set probability dial and as a guaranteed price floor (a "standing bid") for the depositor.

Figures in this app are derived with the same economic math as the deployed contracts, so everything stays internally consistent. Live oracle prices, onchain reads and transactions activate once the contracts are deployed; no specific randomness provider is claimed until an audited adapter is wired.

A depositor deposits a tokenized asset (for example NVDAB, TSLAB, MSFTB, CRCLB) plus USDT backing, minting a position that becomes eligible for selection once active. An acquirer submits an acquisition request and escrows the current acquisition price. Verifiable randomness selects one active position weighted by its inverse backing, and the position is allocated to the acquirer.

The acquirer then chooses within the settlement window whether to keep the underlying asset or to accept the depositor's standing bid; the depositor is paid accordingly. The two diagrams below summarise the deposit lifecycle and the pricing pipeline.

Stock Token + USDT
        │
        ▼
     Position ──────► Standard Pool
                            │
                     Random selection
                            │
              ┌─────────────┴─────────────┐
              ▼                           ▼
        Keep Asset               Take Standing Bid

Asset value
     │  × 98%  (2% haircut)
     ▼
Conservative value
     │
     ▼
Compare with standing bid  (backing × 95%)
     │
     ▼
Position payoff = max(conservativeValue, standingBid)
     │
     ▼
Weighted pool payoff = Σ(weightᵢ · payoffᵢ) / Σweight
     │  + 5% acquisition surcharge
     ▼
Acquisition price = expectedPayoff × 1.05

Depositors supply a whitelisted Stock Token and choose how much USDT to post as backing, within the pool's allowed backing ratio of 50%–150% of asset value. Lower backing raises selection probability but lowers the guaranteed standing bid; higher backing does the reverse. Positions target a notional value of $1 (band $0.5–$5).

While a position is active it can earn a share of protocol fees and can hold the Crown if it is the highest-backed position. Depositors may increase or decrease backing, or queue a withdrawal, subject to the pool's rules and any active allocation. When their position is selected and settled, depositors receive either the acquisition proceeds (asset kept) or their standing bid (bid accepted).

Acquirers pay one acquisition price to receive a random position — they do not choose which one. The price is derived from the whole pool's expected payoff plus a 5% surcharge, so on average acquirers pay slightly above the expected value of what they receive; the surcharge funds depositor rewards, the protocol and the Crown.

After an allocation, the acquirer has a decision window to either keepthe underlying tokenized asset or accept the depositor's standing bid in USDT. A rational acquirer keeps the asset when its conservative value exceeds the standing bid, and takes the bid otherwise — which is exactly how the position payoff is defined.

Each position is represented by an ERC-721 receipt and records its asset amount, oracle-priced asset value, conservative value, USDT backing, inverse weight, standing bid, payoff and status. A position moves through states such as STAGED → ACTIVE → ALLOCATED → SETTLED, or is withdrawn if the depositor exits.

Only ACTIVEpositions are eligible for selection and contribute to the pool's total weight. Because the receipt is a transferable NFT, a position's economic exposure can change hands without unwinding the underlying deposit.

Selection uses an inverse-weight scheme so that under-backed positions are more likely to be chosen. Each active position's weight is the fixed numerator 1e36 divided by its backing (in USD, 18 decimals), and its selection probability is its weight over the sum of all active weights.

Over repeated independent draws with probability p, the chance a position is selected at least once within K draws is:

Backing changes immediately update a position's weight and therefore every other position's probability, since the denominator shifts too.

Pricing starts from each position's asset value, discounted by a 2% haircut to a conservative value, and compared against the standing bid (95% of backing). The position payoff is whichever is larger, and the pool's expected payoff is the weight-averaged payoff across all active positions.

The acquisition price applies a 5% surcharge to the expected payoff and is rounded up, so the protocol never underprices a draw. Worked example: four positions backed 60 / 80 / 100 / 140 with a conservative value of 100 each yield an expected payoff of about 105.09 and an acquisition price of about 110.34.

Selection requires unbiased, verifiable randomness so that no party can predict or influence which position is drawn. When an acquisition request is processed, the protocol requests a random value through a RandomnessRouter and only finalises the allocation once that value is delivered.

The specific randomness provider is to be confirmed and will be documented, audited and independently verified before any mainnet use. This interface never claims a particular vendor (for example, it does not assert Chainlink VRF) until that integration is real and confirmed.

Acquisition requests are processed in order through a queue so that concurrent requests settle deterministically and fairly. A request first waits for its randomness to be delivered, then advances through the queue to be matched with a selected position and allocated.

Because the pool state (weights, prices) can move between submission and processing, each request escrows at its submission price and the interface tracks both the initial and current acquisition price. Requests that cannot be filled or that expire are refunded from escrow.

Once a position is allocated, the acquirer has a 24-hour decision window to keep the asset or take the standing bid. If the acquirer does not act, a 7-day finalization window allows the allocation to be resolved to a safe default so funds and assets are never left stranded.

On keep, the acquirer receives the asset and the depositor is paid from the acquisition proceeds; on take-bid, the acquirer receives the standing bid in USDT and the asset flow reverses accordingly.

The 5% acquisition surcharge is split between active depositors, the protocol treasury and the Crown, rewarding participation and funding operations. Settlement discounts (the gap between backing and the 95% standing-bid payout) are likewise split among positions, the protocol and the Crown.

Depositor fee shares accrue against a running accumulator and are claimable independently of settlement.

The Crown is held by the single highest-backed active position in a pool. The Crown holder earns an extra share of protocol fees for as long as it reigns, rewarding the position that most strengthens the pool's price floor.

To take the Crown, a challenger must exceed the current holder's backing by at least the 10% threshold — a small margin that prevents constant, gas-wasting flip-flopping between near-equal positions.

The MVP asset set is NVDAB, TSLAB, MSFTB, CRCLB — ERC-20 tokenized equities/ETFs (18 decimals) on BNB Chain, each priced by its own on-chain feed. Backing is denominated in USDT, whose canonical address is 0x55d398326f99059fF775485246999027B3197955.

Token and feed addresses are intentionally left empty until fetched from the official Asset Registry — they are never invented here.

Every asset value is computed from an on-chain price feed. For Binance tokenized equities the feed price already includes the UI multiplier, so the protocol never multiplies by it again; the multiplier is used only to display a shares-equivalent figure.

Feeds are checked for freshness — a price older than the maximum age of 60 minutes, or a paused / invalid feed, marks the oracle unhealthy and pauses affected operations rather than trading on a stale number. Conservative valuation (98% of asset value) adds a further margin of safety against short-term price noise.

Tokenized equities are subject to corporate actions — stock splits, reverse splits, dividends, ticker changes and delistings — that can change token balances, prices or eligibility. The indexer tracks announced actions and their effective dates so positions and valuations can be reconciled correctly.

When an action materially affects an asset, the protocol may pause deposits or selection for that asset until the registry and oracle state reflect the new reality, protecting depositors and acquirers from settling on outdated terms.

• Random selection: you cannot choose which position you acquire; outcomes vary draw to draw.
• Backing is a floor, not a guarantee: the standing bid is only as good as the posted USDT and the protocol's solvency.
• Oracle risk: stale, paused or manipulated feeds can misprice assets despite freshness checks.
• Randomness risk: the provider is unconfirmed; selection integrity depends on it being sound and verifiable.
• Smart-contract risk: contracts are deployed and verified on BNB Chain but have had no third-party audit; bugs can cause loss.
• Market & liquidity risk: tokenized-equity prices move and may be illiquid or halted around corporate actions.
• Regulatory risk: tokenized securities exist in an evolving legal environment.

The protocol is a set of focused contracts, all deployed and verified on BNB Chain. Read them before you trust them — every address below links to verified source.

Explorer: https://bscscan.com · RPC: https://bsc-dataseed.binance.org

A read-only JSON API is exposed under /api/v1. Every response uses a standard envelope with a data payload and a metadata object (chain ID, indexing timestamp, data mode and an isEstimated flag); list endpoints add a pagination block and accept filters such as ticker, status, wallet and backing bounds.

Security is layered: conservative valuation, oracle freshness checks, exposure caps (TVL $25,000, ≤ 35% per ticker), a queue for deterministic ordering, and settlement windows that guarantee every allocation resolves. Randomness is treated as security-critical and will not be wired to any provider until that provider is confirmed and verified.

The off-chain indexer is reorg-aware — it records block hashes and parent hashes so a chain reorganisation prunes and replaces affected rows rather than serving stale data. Contracts remain unaudited and unproven until deployment; treat all parameters shown here as indicative beta values.

Binance World Assets is an independent, experimental software project. It is not affiliated with, endorsed by, or connected to Binance, "Fake World Assets", Chainlink, any asset issuer, or any randomness vendor. Any names or marks are the property of their respective owners and are used only for identification.

Nothing in this interface constitutes financial, investment, legal or tax advice, a solicitation, or an offer to buy or sell any security or token. Tokenized-asset mechanisms are highly experimental and risky, and you may lose some or all of your funds. Values are derived from the protocol math; live oracle prices and onchain reads activate once contracts are deployed and balances, contracts or yields.

Use of this software is at your own risk and subject to applicable law in your jurisdiction. No warranty of any kind is provided.