These docs describe the current implementation. A local preview or an older deployment can use different contracts and pool fees. The market ticket, rewards status and configured deployment manifest ↗ identify the environment you are using. Local test tokens and balances are not public assets.
Your first trade
Shangpin Market lets you trade commodity-themed tokens and user-created launch tokens on BNB Smart Chain. You can browse without connecting a wallet. A token is a tradable crypto asset, not a claim to physical coffee, gold, oil or any other product.
Connect and check the network
Use the single Connect wallet button. Choose an installed Ethereum-compatible wallet. Connection requests your public address; transactions need separate wallet approval. Use the network requested by this site; BSC mainnet is chain 56. An Anvil test fork may use the same chain ID, so it still needs the matching local RPC. On mobile, open this site in your wallet’s browser.
Have the right assets
Trade forms default to BNB, with USDT also available. To sell, hold the commodity coin or launch token. Keep BNB for network gas in addition to your purchase amount. This site does not provide a fiat on-ramp or bridge.
Choose a deployed market
Open Markets, search by name or symbol and select a deployed entry. A catalogue listing alone is not a trading pool. Compare the reference price, pool price and USDT sell-side depth. For a launch, choose the commodity leg you want to trade through.
Review the quote
Enter a plain decimal amount. Review Estimated received, Minimum received and the displayed pool fee. The default slippage tolerance is 0.5%; the interface accepts 0.1–5%. A quote can change before execution. Slippage limits the transaction output, not the future value of your tokens.
Approve, then trade
If required, approve the specific spending amount requested by the router. Approval gives that contract permission to spend tokens; it is separate from the trade. Check both wallet requests. The interface refreshes the quote, simulates the action, checks the wallet and sends the trade with a minimum output and deadline.
Wait for the receipt
Use the transaction status to distinguish wallet approval, submission and confirmation. Public-network receipts can be inspected in the explorer. Indexed trades and balances may update after additional blocks. If a transaction is already pending, check its receipt before submitting another.
Commodity markets begin with coin inventory and no prefunded USDT bid. Buyers create the USDT reserves that sellers use. Low depth may cause partial fills or make the requested minimum output impossible. A reference price is not a promise that you can sell any amount at that price.
Create a launch
Open Create a launch. Creation deploys a fixed-supply token and creates its liquidity pools, then makes your first purchase in one transaction.
Set the identity
Enter the token name, symbol and description, then upload a required PNG, JPEG or WebP image no larger than 4 MiB. You can optionally add a website and an X handle or path after the displayed
x.com/prefix. On submission, the site generates and pins the image and metadata, including those links; there is no manual metadata-URI input. Metadata pinning must be available to create through this form. Review everything before signing: the token’s recorded identity, metadata URI and launch fee settings are permanent.Choose the basket
Search the scrollable pair list by commodity name or ticker and select one to five enabled pairs. Each leg needs at least 5% weight and the weights must total 100%. These weights divide the launch’s initial token liquidity among its pools; they do not create a redeemable basket of goods.
Choose the optional tax
Type a whole number from 0 to 10; the input enforces this limit and rejects fractional percentages. The fixed 1% envelope is added, giving a 1–11% launch-pool fee. If the optional tax is positive, choose either holder dividends or creator fees. At 0%, neither exists and the recipient selector is hidden.
Make the first buy
Select a leg and enter your BNB amount. The app simulates the complete creation and first buy, then automatically sets a minimum output 1% below the simulated token amount. If simulation fails or the protected output is zero, signing is blocked. The contract requires a first purchase worth at least $1 in the selected commodity; allow for conversion fees.
Review and sign
BNB creation needs no token approval. The protected transaction is simulated again before you sign. After confirmation, the page shows the token contract address; wait for indexing to see the launch in the directory. Direct commodity funding and atomic whole-basket trades are not exposed in the UI.
Find your rewards
| You are… | Where to look | What to do |
|---|---|---|
| A holder of a dividend-mode launch | The launch’s Holder dividends panel | Hold eligible launch tokens. Payments are automatic when allocation, credit and cost rules are met; no staking or claim is needed. |
| The creator of a creator-mode launch | Your launch’s Creator fees panel | Connect the original creator wallet and claim. You pay BNB gas and receive the original fee assets. |
| A holder of the platform token | Rewards | If the configured deployment is enabled, stake platform tokens, claim accrued rewards, or unstake principal. |
| Holding a zero-tax launch | The launch’s fee explanation | There are no optional holder dividends or creator fees. |
These are separate systems. Owning a commodity coin does not by itself earn launch-token dividends. Holding a launch token does not automatically stake the platform token.
Back to contents ↑Three kinds of token
| Token | Purpose | Supply and backing |
|---|---|---|
| Commodity-themed coin | A themed trading asset, paired with USDT and usable as a launch quote asset. | The liquidity manager can mint inventory. It is not fixed supply, physically backed or redeemable. |
| User launch token | A creator’s token with one or more commodity-coin pools. | One billion tokens at creation; fixed supply. The commodity pairing does not guarantee a dollar valuation. |
| Main / platform token | The token selected for protocol buybacks, burns and platform staking. | Final public identity and allocations are launch-time choices. The optional issuance contract is fixed supply and burnable, with no transfer tax or later minting. |
The catalogue currently contains 83 themes, including Lao Gan Ma. Names and imagery identify themes, not a relationship with the referenced manufacturer, commodity exchange or brand. A locally deployed token named LOCAL is test infrastructure, not a selected public platform token.
How commodity pools work
Each deployed commodity coin trades against USDT in a PancakeSwap V3 concentrated-liquidity pool. Concentrated liquidity places assets in selected price ranges rather than spreading them across every possible price.
- Ask range: commodity coins available to buy, placed around the tick boundary at or above the set reference.
- Bid range: accumulated USDT available to sellers, placed around the boundary at or below the reference.
- Inventory target: a configurable target controls coin replenishment. Deployment examples use $100,000 of reference-valued coin inventory; this is not $100,000 of deposited USDT.
- Maintenance: the keeper recentres ranges when needed, including a changed reference boundary, an exhausted range or ask inventory below half the target.
New commodity pools use the 0.25% tier with tick spacing 50. A tick is a discrete price step; spacing constrains where a range can begin. Alignment and range width mean execution can differ from the reference even before fees and trade size are considered. Older deployed pools may use a different tier, which the ticket displays.
Repricing removes and reinstalls the manager’s ranges atomically. The current reset path rejects any USDT charge during the price-reset swap, while allowing existing USDT to be redeposited into bid liquidity. Outside liquidity can therefore block a reset. Coin-input resets can still consume coin inventory; the gas budget does not cap that inventory use.
The fee-only collection path does not extract liquidity principal. Separately, the peg administrator has a withdrawal function that can remove managed liquidity. This administrative authority is an important custody and availability assumption.
Set prices, pool prices, quotes
| Value | What it means |
|---|---|
| Reference price | An operator-set benchmark used for range placement and protocol calculations. It may be a configured themed-token value rather than an external market quote. |
| Pool price | The current ratio implied by the pool state. It changes with trades and liquidity placement. |
| Executable quote | An estimate for your particular input, route and available liquidity. The signed minimum output is the transaction constraint. |
Read the price chart
Commodity and launch detail pages show indexed pool spot prices after swaps. These are observations of pool state after each indexed trade, not the average execution price paid by that trader. Launch charts are separate for each basket leg and quote one launch token in that leg’s commodity coin; the commodity chart quotes in USDT. Select a leg to inspect its own history.
The 24H, 7D, 30D and ALL controls select history ending at the latest indexed trade. Lines connect recorded observations; they do not invent trades between them. The chart identifies when older observations are omitted. If no verified history is available, it shows an empty state and, where available, a labelled reference-only value rather than a fabricated price line. That reference is not a historical trade or executable quote.
A catalogue card can show a saved Starting reference when no live market reading is available. That fallback is the configured catalogue value, not a fresh pool quote or proof of deployment. A deployed market’s reference comes from its on-chain feed; the pool price and executable quote remain separate.
On the current commodity feed, a valid set price remains in use indefinitely until replaced. Its observation date is preserved. An old timestamp alone does not expire it or stop repricing; maxAge remains legacy metadata. Optional external checks may run daily, retaining the set value when no update is available.
Missing, disabled or paused references still prevent feed-dependent keeper operations. Public pools can continue trading at existing ranges. An old contract that explicitly reports expiry support may behave differently from the current feed.
For example, LGM’s configured starting reference is $5 per themed token. This is a product setting, not a verified retail jar price or redemption value. Reference-valued portfolio and dividend amounts are not guaranteed cash proceeds.
The BNB gas-cost oracle is different: it still needs a usable, fresh BNB/USD round to value keeper processing costs. Persistent commodity prices do not disable the oracle’s freshness checks.
Back to contents ↑Launch pools and basket legs
A launch is a real PancakeSwap Infinity concentrated-liquidity pool from creation. Each selected commodity leg has its own pool against the same launch token. The launchpad installs the positions and executes the initial buy; there is no later migration transaction.
| Property | Current implementation |
|---|---|
| Token supply | 1,000,000,000 tokens total. |
| Curve allocation | 800,000,000 tokens distributed among the selected legs by weight. |
| Reserve allocation | 200,000,000 tokens distributed into ranges above the curve’s cap boundary. |
| Opening / cap references | $5,000 / $35,000 default whole-supply valuation references at creation, expressed through the selected commodity units. |
| Basket limits | 1–5 legs, minimum 5% per leg, total 100%. |
| Launch tick spacing | 200; this is separate from commodity/USDT pool spacing. |
The displayed curve progress is the share of the 800 million curve tokens that have left the initial curve ranges, summed across all legs. It can move backward when tokens are sold back. It is not a fundraising milestone or a redemption balance. The reserve range can continue trading above the boundary. Commodity reference changes and pool trading affect later dollar valuations; the opening and cap figures are creation-time terms.
Five-pool example: choosing five commodities at 20% each creates five pools for the same launch token. Each receives its weighted share of the initial liquidity, not a separate billion-token supply. Prices can diverge as users trade different pools; there is no promise to restore the original weights automatically.
Find and compare launches
The launch directory supports newest first, oldest first and highest indexed volume sorting. Its commodity-pair filter matches any leg of a launch’s basket. Displayed volume is all-time indexed quote-side trading volume, valued using the commodity reference recorded for each trade. It is not 24-hour volume or a current-price revaluation. Missing volume is shown as —, rather than an assumed zero; indexing and reference availability limit what can be compared.
In a multi-leg launch, your trade uses a particular commodity pool. The current form lets you pick that leg. Fees, depth and execution may differ by leg. Basket weights describe initial allocation, not an obligation to rebalance your wallet or deliver underlying commodities.
Back to contents ↑What you pay, and where it goes
Commodity / USDT trading
The configured tier for new pools is 0.25% of swap input. At PancakeSwap’s current 32% protocol cut, a 1,000 USDT swap generates 2.50 USDT of pool fees: 0.80 to PancakeSwap and 1.70 to active liquidity providers. This example excludes price impact and network gas.
Where Shangpin’s operating allocation is supported, 5/17 of fees actually earned by its positions go to operations and 12/17 remain available for liquidity. If those positions supplied all active liquidity in the example, 0.50 USDT goes to operations and 1.20 USDT is retained. Other liquidity providers retain their own earned share. A changed PancakeSwap protocol cut changes the effective percentages of volume.
Collection leaves fees in their original coin or USDT denomination. The market’s cumulative allocation totals are receipts over time, not the treasury’s remaining spendable balance. Operating funds have a separate reserve and manual administrator withdrawal path; they are not holder rewards or buyback funds.
Launch trading
| Optional tax | Fixed envelope | Total launch-pool fee | Optional beneficiary |
|---|---|---|---|
| 0% | 1% | 1% | None |
| 1% | 1% | 2% | Creator or holders |
| 2% | 1% | 3% | Creator or holders |
| 3–9%, whole numbers | 1% | 4–10% | Creator or holders |
| 10% | 1% | 11% | Creator or holders |
The fixed 1% envelope includes the DEX cut; it is not 1% plus a second launch-pool DEX fee. The optional portion goes to exactly one selected group. Fee terms are fixed at launch. Fractional optional percentages and values outside 0–10 are rejected.
A USDT launch buy first converts USDT to the chosen commodity, then buys the launch token. The commodity-pool fee and the launch-pool fee both apply to their respective hops. They are applied sequentially, not simply charged twice on the original amount. The quote reflects the route. BNB network gas is separate; the frontend adds no surcharge.
For a 2% total launch-pool fee, 1% is the fixed envelope and 1% is the chosen optional tax. If that tax is for holders, it funds distribution costs before net credits. If it is for the creator, the creator claims the accrued share and pays gas separately.
Back to contents ↑Automatic holder dividends
Holder-mode launch fees accumulate in reserves for holders of that launch token. Commodity fees keep their basket-leg denomination. Collected launch-token fees are converted into the first leg’s commodity, with the resulting beneficiary shares accounted separately.
| Rule | Current default and meaning |
|---|---|
| Evaluation interval | 15 minutes; a check schedule, not a guaranteed payment. |
| New allocation threshold | $100 gross unallocated optional-tax value per leg, based on configured references. |
| Holder eligibility | At least $5 of launch tokens at the indexed allocation snapshot; known infrastructure and burn addresses excluded. |
| Transfer minimum | $10 of accumulated net credit per recipient, plus an economical batch. |
| Cost gate | Previously incurred costs being reimbursed plus estimated payout gas must fit within 1% of net payout. This is a maximum-cost check, not an extra 1% tax. |
Collect and record real costs
The keeper fronts BNB for collection, sweep, conversion and payout. Successful processing receipts record actual gas used, effective gas price and a fresh BNB/USD value. Failed transactions consume the keeper’s budget but are not charged as dividend-processing receipts.
Allocate the net amount
When a new gross pot qualifies, outstanding processing costs and a conservative future-payout gas holdback are taken from unallocated optional tax before new holder credits are created. Existing earned credits are not reduced to pay later costs.
Accumulate, then pay
Credits smaller than $10 remain owed, including after the holder sells. Existing credits can be paid without a fresh $100 pot or a current $5 holding, provided the transfer and economic rules are met. The ledger carries small balances forward.
Separate the reimbursement
A payment batch transfers holder amounts and a separately recorded keeper reimbursement in the commodity coin. The keeper does not receive the estimated future-gas holdback as profit. Unused holdbacks remain in the same reserve; the actual gas for this payout becomes a cost for a later batch.
Example: $100 gross optional tax minus $0.50 in recorded costs and a $0.10 future-gas reserve leaves $99.40 for new credits. A wallet credited $9 waits and accumulates; a wallet at $10 still needs an economical batch. Commodity price changes can change a credit’s reference-valued dollar amount.
The launch page separates unpaid reserves, already-earned credits, lifetime reimbursements and the last keeper estimate. Estimates include a timestamp and may be unavailable before a cycle. Holder eligibility is based on a snapshot, not time-weighted ownership: tokens temporarily held across that snapshot can qualify. The keeper’s entitlement selection and expense policy are trusted off-chain logic, not an on-chain proof that each holder deserves a particular amount.
Back to contents ↑Creator claims: your gas, your fees
In creator mode, the original launch creator calls claimCreatorFees(id). The call first collects pending pool fees, then transfers unclaimed creator amounts in every original commodity coin and the launch token.
- The creator signs and pays BNB transaction gas from their own wallet.
- There is no keeper payout, processing deduction, automatic asset conversion or $10 claim minimum.
- The interface shows recorded accrual minus previously claimed counters; pending pool collection can make the final receipt larger.
- Claim counters prevent previously claimed fees from being paid again. A claim with no new fees can still cost gas.
- At zero optional tax there are no creator fees, and the claim control is hidden.
Creator fees do not come from holder reserves. The current accounting version is 3; earlier local creator-keeper experiments are superseded and must not be treated as the current payout mechanism.
Back to contents ↑Main-token buybacks and staking
The main/platform token has a separate reward system. When a compatible token, funded pool and contracts are configured, protocol launch-fee reserves can buy that token. Holding a launch token is not participation in this staking program.
The current main-token integration uses a funded WBNB/token Infinity pool. The three-hop buyback checks separate minimum outputs and a deadline in one transaction. A failed hop rolls back the purchase. Holder reserves and the separate operating reserve cannot fund it.
The deployment default burns 50% of tokens bought and funds staking with 50%. The share is an explicit deployment choice, not a hardcoded promise for every environment. Settlement totals show the declared asset and decimals; an old USDT input is not relabelled WBNB when historical WBNB data is missing.
What staking actually earns
Stake the selected platform token to receive funded rewards in that same token. The default streaming duration is 7 days; supported deployments choose between 1 hour and 30 days. New funding combines with the remaining scheduled reward and starts a new duration. Rewards that accrue while nobody is staked are queued for later streaming.
Rewards depend on funded buybacks, time and your share of total stake. There is no fixed APR or inflationary emissions promise. Staking and unstaking in the same block do not grant an immediate lump-sum reward.
- Stake: approve the exact requested token amount and deposit it into the verified staking contract.
- Claim: receive accrued reward tokens.
- Unstake: withdraw available principal independently of a reward claim; there is no contract lockup or admin unlock.
Principal and reward reserves are accounted separately even though they use the same asset. The staking contract has no admin sweep of either balance. Small rounding dust can remain. Frontend deposits require current API and deployment checks; verified withdrawals and claims can continue through an API outage if the wallet, RPC and configured contract remain available.
Activation is explicit
Production buyback automation is disabled by default. It needs a selected token, funded pool, per-purchase spend limit, retained protocol revenue per asset, maximum acceptable token price, slippage and cooldown settings. Pairing a token with BNB does not automatically generate keeper revenue. Initial main-token liquidity and automatic WBNB-to-BNB gas top-ups are not supplied by the rewards deployment script.
Back to contents ↑The keeper: maintenance with a budget
The keeper is an operator-run service that reads the chain and submits maintenance transactions. It updates configured references, recentres commodity liquidity, processes fees, distributes eligible holder credits and performs explicitly enabled buybacks. Browsing and quoting do not require the keeper to be in your wallet.
| Limit | Default | Consequence |
|---|---|---|
| Total gas budget | 0.003 BNB per rolling 24 hours | All automated sends share the cap, including pending maximum gas liability and failed mined transactions. |
| Gas-price ceiling | 0.1 gwei | Defer sends above the ceiling. |
| Pool maintenance cooldown | 15 minutes between attempts | Limits repeated work on one pool; it does not guarantee that every pool receives a transaction each interval. |
| Estimate headroom | 20% | Reserve a conservative possible gas cost before broadcasting. |
These are implemented operator settings, not spending limits enforced by every smart contract. They survive service restarts through the persistent transaction journal. Before broadcasting, the sender records the signed transaction and its reserved cost. A timeout is not treated as free: an unresolved transaction retains its liability and blocks subsequent writes until reconciled.
Receipts replace estimates with actual costs. Discretionary buybacks run after holder payouts and maintenance. A depleted budget defers writes rather than erasing holder credits. Reads and simulations use RPC resources without spending chain gas; a transaction that reverts after mining still consumes gas.
For standalone commodity fee collection, projected gas must also be economical relative to the expected operating revenue. It is not billed to launch holders. The keeper’s native BNB is topped up manually; receiving commodity reimbursements does not itself refill the native gas balance.
These budgets do not cover deployment costs, hosting, main-token liquidity or commodity inventory consumed by an allowed coin-input reset. The operator must retain the database, use an exclusive keeper wallet, monitor gas and RPC health, and reconcile unexpected chain reorganizations.
Back to contents ↑Contract map and authority
The frontend reads a deployment manifest and matching contract ABIs. An ABI describes the functions and events the interface can encode. Contract names below describe roles; they are not a list of verified public addresses. Read the current manifest ↗ and verify the chain before interacting.
| Contract | Responsibility | Authority / boundary |
|---|---|---|
CommodityPriceFeed | Stores set prices, observation dates, enabled state and pause controls. | Authorized keeper sets prices; admin configures assets and limits; pauser can halt feed availability. Age alone does not expire current-feed prices. |
CommodityCoin | ERC-20 commodity-themed token, identity and metadata. | Authorized minting supplies the manager’s coin inventory; it is not redeemable backing. |
PegLiquidityV3 | Manages commodity/USDT ask and bid ranges; collects actual LP fees. | Keeper reprices and collects. Admin can adjust the inventory target and withdraw managed liquidity. Operating destination is immutable. |
LaunchpadV6 | Creates launch pools and accounts for creator, holder and protocol shares. | Version 3 creator claims collect and pay the original creator. Launch terms and destination bindings must match the deployment. |
LaunchToken | Fixed-supply token cloned for each launch. | Recorded token identity, metadata URI and supply are established at creation. |
DynamicFeeHook | Applies the launch’s configured fee to its Infinity pools. | Launch fee settings are separate from commodity-pool and external conversion fees. |
LaunchRouter / PairSwapRouter / BasketRouter | Fund creation and route launch purchases/sales through selected assets or legs. | Minimum outputs, deadlines, approvals and transaction simulation matter. Not all contract routes have frontend controls. |
Treasury | Separates holder, protocol and operating reserves; executes payouts and buybacks. | Authorized keeper disburses holder batches; admin has bounded protocol/operating withdrawals. Holder reserves cannot be spent as ordinary admin withdrawals or buybacks. |
ProtocolBuyback | Buys the configured platform token and sends output to burn and staking. | Configured token/pool/split are fixed; only new purchase output counts toward the minimum and distribution. |
PlatformStaking | Holds stake and streams funded rewards in the same token. | Authorized notifier funds rewards. Users unstake/claim; admin cannot sweep accounted principal or reward reserves. |
PlatformToken | Optional fixed-supply, burnable main-token implementation. | No later mint, transfer tax or token owner; supply and initial recipient are deployment inputs. Another compatible token can be selected. |
PancakeSwap V3 and Infinity provide the external pool infrastructure; routers and pool managers are separate from the Shangpin contracts. BNB gas pricing uses a separately configured oracle. Wallet connections use installed browser providers through wagmi; the app does not store private keys or require a login signature.
What is enforced where?
- On chain: access control, reserve separation, claim counters, batch-ID replay protection, transaction output minima and staking accounting.
- Keeper policy: holder snapshots, expense attribution, economic batching, daily gas cap, buyback price ceiling, cooldowns and asset rotation. A compromised privileged signer remains a material risk.
- Frontend: network/fork identity, manifest matching, approval amounts, refreshed quotes and simulations. These help detect mistakes but cannot make a hostile RPC, wallet or contract safe.
Data, metadata and transaction checks
On-chain contracts hold assets and transaction state. The API combines chain reads with an indexed database for histories, holder snapshots and durable dividend credits. A block index can lag a confirmed receipt; a changed checkpoint hash halts financial processing for reconciliation rather than silently replaying payments.
| Endpoint | Information |
|---|---|
GET /health | Network/local-fork status and capabilities such as metadata pinning. |
GET /deployment | Deployment contract bindings; the frontend may also use its independently hosted static manifest. |
GET /markets/:symbol | Reference, pool state, inventory and optional cumulative operating-fee allocation. |
GET /launches/:id | Launch identity, basket, pool data and creator accrual/claimed counters. |
GET /launches/:id/rewards?wallet=… | Per-leg holder credits, timestamped economics and payout history; creator mode is identified as a direct claim. |
GET /platform-rewards | Enabled status, settlement denomination, buyback history, staking totals and binding checks. |
Launch metadata stores an immutable URI, but an HTTPS server or unpinned resource can still disappear or serve different content. An IPFS content identifier identifies content; continued availability still depends on hosting/pinning. The interface restricts link schemes and validates metadata responses, but a logo or token name is not authentication of a brand.
Before signing, the interface checks the selected account and chain, verifies configured contracts and simulates the transaction. Commodity routing reads the deployed pool’s fee and refuses a mismatch with market data. Required ERC-20 approvals use the requested amount. A local fork also needs the correct RPC provenance; a chain ID of 56 alone does not establish that a contract is on public BSC.
Check the transaction receipt, network, available gas, API/RPC status and current quote. An API outage does not mean an on-chain transaction failed. Do not delete an indexer or reward ledger to resolve a payment problem: earned credits and already-paid batch IDs need reconciliation.
Implemented is not the same as launched
| Area | Current position |
|---|---|
| Application and core mechanics | Implemented and exercised on isolated BSC forks, including commodity trades, launch creation, holder payouts, manual creator claims and platform staking. |
| Latest contract changes | Persistent references, 0.25% commodity pools, operating allocations, keeper budgets and WBNB buyback routing exist in current code. Earlier preview contracts do not gain these changes automatically. |
| Public deployment | Pending. Local manifests, addresses, gas examples and test balances are not public-launch evidence. |
| Main token and venue | Final token identity, supply/allocation, opening liquidity and venue configuration are launch-time decisions. Any alternative venue integration needs its own verification. |
| Automatic features | Require an operating, funded keeper and the relevant enabled configuration. Production buybacks are disabled by default. |
| Security review | Internal review and regression tests exist. Independent external audit and a sustained public pilot remain outstanding. |
| Additional UI routes | Creation uses BNB. Trading supports BNB and USDT; direct commodity launch funding and atomic basket controls remain outside the interface. |
Check the live interface for feature availability. These docs do not promise a launch date, a yield, a continuous peg, guaranteed liquidity, or a payout at a particular time.
Back to contents ↑The short version
- Basis point / bps
- One hundredth of one percent. 25 bps = 0.25%; 100 bps = 1%.
- LP
- Liquidity provider: a position that supplies assets for swaps and can earn pool fees.
- Tick / range
- A discrete price step / an interval in which concentrated liquidity is active.
- FDV
- Fully diluted valuation: price multiplied by total token supply. It is not the amount of money available to sellers.
- Slippage / minimum output
- Your permitted difference from a quote / the least output the transaction is allowed to deliver.
- Reference value
- A calculation using configured benchmark prices, which can differ from executable cash value.
- Gross pot / net credit
- Optional-tax revenue before new processing deductions / the amount already allocated and owed to a holder.
- WBNB
- Wrapped BNB, the ERC-20 representation used in the main-token pool. Native BNB pays chain gas.
- Keeper / indexer
- The operator service that submits maintenance / the service that records chain events and snapshots.
- Manifest / ABI
- The configured contract-address map / the interface used to encode calls and interpret events.