Risk Disclosure
Last updated: September 7, 2026
You can lose the full amount committed to an Amoeba product, together with associated costs. Bounded option payoffs and advance collateralization reduce particular risks in the intended contract design; they do not guarantee profit, protect writer principal, guarantee access to funds, or eliminate technology and legal risks.
This page describes the current synthetic-market design and related participation risks. Availability depends on the specific network, deployment, market, and operational state. A publicly accessible website, a visible market, or successful Devnet activity is not proof of mainnet availability, regulatory approval, or readiness for real-money participation. Test deployments may use seeded or deterministic data and test tokens with no right to real-money redemption or future token allocation.
Read this page together with the Terms of Use, Privacy Policy, and the rules and transaction details for the particular feature you intend to use. This is not personalized investment, trading, legal, tax, procurement, or accounting advice.
1. Fixed risk does not mean no risk
1.1 Buyer loss. A purchased capped option can expire worthless. A favorable movement in the underlying benchmark does not necessarily cover the premium and costs you paid. You can lose the full purchase price even when the benchmark moved in the direction you expected.
1.2 Writer loss. Writers and Flat holders fund residual settlement exposure. Premium collection does not guarantee positive returns, and the applicable book can expose committed writer principal to substantial or total loss. The reserve protects the intended funding of buyer claims; it is not insurance for writers.
1.3 No routine liquidation. The intended fully funded structure does not depend on continuous mark-to-market margin calls to meet its bounded payouts. That does not guarantee an early exit, prevent a decline in a position's market value, or stop a pause, software failure, or other event from blocking access.
1.4 Limits of a payoff description. A ticket's maximum loss describes the intended position economics and the costs included in that display. It does not cap every consequence of a stolen wallet, malicious approval, counterfeit asset, contract exploit, or unauthorized transaction involving other assets.
2. What the benchmarks represent
2.1 RAMX. The current governed RAMX v1 product manifest contains 52 terminal SKU identities for the specified memory-module product. It is not a comprehensive index of all DRAM, HBM, GPU hardware, manufacturers, or transactions in the memory industry. Read the applicable manifest rather than inferring coverage from a product name or a market illustration.
2.2 NANDX. The current governed NANDX v1 registry contains 48 terminal manufacturer part numbers. Its separate benchmark basket contains 22 rows: 18 item-addressable rows and four assessment-only raw-wafer rows. SKU identities, basket rows, and observation sources are different units; their counts should not be used interchangeably.
2.3 NANDX composition. The current v1 product basket assigns 30% to channel-market SSD gauges, 25% to industry/OEM SSD gauges, 25% to raw NAND wafer gauges, 10% to eMMC 5.1 gauges, and 10% to UFS 2.2 gauges. These are product-definition weights, not a statement of market share and not cash-purchased source influence. A later product version requires its own identified methodology.
2.4 Synthetic exposure. These contracts settle financially against a defined benchmark. They do not reserve components, guarantee a supplier's price, provide title to inventory, fund an insured production order, or entitle a holder to physical delivery. Proposed future industrial or inventory products are not rights attached to a current synthetic position.
3. Coverage, basis, and concentration risk
3.1 Basis risk. Your actual purchasing or selling price may move differently from RAMX or NANDX because of specifications, quantity, geography, currency, supplier relationships, condition, taxes, shipping, credit, delivery timing, or negotiated terms. A benchmark position is not a guarantee of procurement cost or an exact hedge of a specific invoice.
3.2 Concentration. A limited basket can be sensitive to particular technologies, product rows, channels, or source publishers. Multiple pages can depend on the same supplier or underlying assessment and therefore provide less independent information than their number suggests.
3.3 Data is not necessarily an executable price. Listings and assessments can be stale, unavailable for the displayed quantity, or unrelated to a completed transaction. A normalized index level or an option premium is not the cash price of a physical module or drive.
3.4 Coverage gates. Incomplete or disputed source coverage can delay activation, listing, issuance, or settlement workflows. Under the current ladder, a late effective listing does not move the immutable expiry, so a delay can shorten the period available for trading.
4. Oracle and settlement risk
4.1 Source-local measurement. The oracle follows accepted changes relative to each source's own opening state. A wrong opening value, wrong field, SKU mismatch, or incorrectly identified source can distort subsequent movement even when later arithmetic is correct.
4.2 Median aggregation. The current oracle uses deterministic medians within governed SKU buckets rather than weights proportional to source-backing cash. Fixed product weights apply at their defined basket level. A median can resist some isolated outliers but does not guarantee truth when sources share errors, are manipulated together, or fail to represent the intended market.
4.3 Settlement window. Current final settlement takes each source's temporal median over the applicable inclusive five-business-day expiry window and then the cross-source bucket median before the required product aggregation. The final value can differ from the last live print, an intraday extreme, a chart, or a value you observed outside the eligible window.
4.4 Unchanged sources. The current carry-forward rule applies when the eligible settlement window contains no accepted observations for an unchanged source, using the qualifying prior accepted state. It does not insert an extra sample into a nonempty window or create a paid update. A carried-forward observation can nevertheless be economically stale.
4.5 Disputes and fallbacks. Source challenges, update challenges, a permitted one-time lookback extension, and emergency procedures can affect timing and the eventual accepted value. A lookback extension is not an extension of the contract's expiry. Evidence may be inaccessible or ambiguous, a valid challenge may be missed, and an emergency result can be wrong.
4.6 Publication and claims. Settlement requires the applicable authorized publication and on-chain checks. The current implementation makes settlement eligible only after a post-expiry delay; it does not promise payment at expiry or immediately when eligibility begins. Publishing a settlement and receiving funds through a claim or redemption can be separate operations.
4.7 Security assumptions. An oracle-security exposure cap limits permitted activity under its defined assumptions; it is not a guaranteed minimum cost of manipulation or insurance against an attack. Source independence, bond economics, dispute participation, and the actual deployed configuration remain important. Testnet budgets and seeded activity do not establish a production security budget.
5. Option issuance, trading, and liquidity
5.1 Writer liquidity. Backed options are offered through writer-owned liquidity in the DLMM. Inventory can remain unsold or partially sold; a liquidity deposit is not a completed sale. Fills remain subject to pricing, risk-policy, reserve, security-cap, expiry, and other checks. Writer-funded buybacks must satisfy the frozen valuation and spending limits and reduce the exact reserve; they are not a guaranteed exit or price-support promise. Funds committed to earlier auctions may still require a separate refund or claim operation.
5.2 Native trading venue. The Amoeba DLMM is a finite, program-owned additive quote grid for option issuance and trading. Liquidity exists only where it has been provided and is eligible for the requested fill. Management follows the position's authorized owner or manager. Holding Flat does not grant control over pooled liquidity, and third-party LP assets do not become writer collateral.
5.3 Price and execution. Quotes can change before execution, and a displayed midpoint, reference premium, or estimated position value may not be executable for your size. Thin depth, a price gap, trade-size limits, minimum-output protection, or the finite traversal limit can cause slippage or rejection. A protective limit can prevent an unacceptable fill but cannot create liquidity.
5.4 Trading can stop. A market pause, governance freeze, stale preparation, infrastructure failure, or settlement transition can prevent trading. Final settlement disables further swaps for the relevant pool. You may have to hold a position through settlement even when you would prefer to sell it.
5.5 No standing buyer. There is no assurance that Amoeba, a writer sleeve, or a liquidity manager will buy your options or Flat. A theoretical arbitrage relationship, transferable token, or suggested buyback design is not a redemption promise.
6. Contribution, bond, and reward risk
6.1 Assets at risk. Source support, claims, and challenges can require assets to be committed. Incorrect work, a failed challenge, missed deadlines, an invalid evidence format, or an adverse dispute result can result in losses or forfeited rewards. Being sincere is not the same as satisfying the protocol's validity rules.
6.2 Rewards are conditional. Reward budgets are finite and subject to funding, eligibility, and finalization. Ordinary cash challenges are participant-funded contests, not risk-free tasks. An advertised bounty is not a salary, investment yield, or guaranteed payment, and an unchanged-source observation is not automatically a rewarded update.
6.3 Evidence risk. Web pages can change, archives can fail, dynamic prices can be misread, and source publishers can block access. Do not assume that a live page remains available throughout a challenge or that a screenshot proves the required product, field, and time.
6.4 Public exposure. Evidence, wallet activity, disputes, and outcomes may become public and durable. Do not submit private credentials, unnecessary personal information, confidential correspondence, or information you are not permitted to disclose.
7. Wallet, infrastructure, and settlement-asset risk
7.1 Wallet and identity security. A compromised device, email account, embedded-wallet login, private key, or recovery mechanism can cause loss. A convincing website or support message may be fraudulent. Confirm the origin and inspect each signature and approval.
7.2 Software and dependencies. Smart contracts, transaction builders, proofs, clients, databases, APIs, RPC services, and wallets can contain errors or be compromised. Formal checks and reproducible builds cover particular properties and artifacts, not every source of operational or economic risk.
7.3 Compression and access. Light-based hot/cold accounts and token representations depend on the required loading, proof, indexing, and network services. Compression reduces particular storage costs; it does not promise instant availability, zero transaction costs, or private transactions.
7.4 Transaction lifecycle. Preparation, signing, submission, confirmation, and finality can fail at different stages. Separate operations in a multi-step workflow are not all reversed merely because a later operation fails. Verify existing status before retrying, and retain the relevant transaction references.
7.5 Stablecoins and networks. A USDC-denominated amount is a claim involving the specified token and network, not cash held in your bank account. Token value, issuer restrictions, transfer freezes, redemption access, and network disruption can affect usability and value. A token with the same name on Devnet or with a different mint address is not interchangeable with production USDC.
7.6 No assumed insurance. Do not assume that a position, writer deposit, staking balance, or blockchain wallet is protected by deposit insurance, investor compensation, or an Amoeba guarantee. Any actual protection would need to be expressly identified and applicable to your situation.
8. Understanding payout, cost, and sizing
8.1 Gross payoff. For a simple capped call, the economic per-contract payout is min(max(alpha × (X − K), 0), C). For a capped put it is min(max(alpha × (K − X), 0), C). Here X is the accepted settlement value, K the strike, alpha the participation rate, and C the maximum gross payout. The specific contract controls its units and integer rounding.
8.2 Net outcome. For a buyer holding q contracts to settlement, the simplified net result is q × (per-contract payout − per-contract premium) − applicable costs. A quantity measured in contract atoms must be converted using the actual contract scale. A chosen cash budget is not automatically an underlying notional exposure of the same amount.
8.3 Example, not a quote. For an illustrative 100-strike call with alpha 1 and a 12-unit payout cap, settlement at 106 produces a gross payout of 6 per contract; settlement at or above 112 produces 12. If the premium was 4, the maximum net profit before costs is 8, not 12. Settlement at or below 100 loses the 4 premium, plus costs. Actual markets may have different terms.
8.4 Capped hedges. A capped call stops gaining after its cap is reached even if your physical procurement cost keeps rising. Buying a capped put likewise does not create unlimited protection against a fall in the value of inventory. Holding a capped contract is not equivalent to holding the underlying or an uncapped forward.
8.5 Models and probabilities. Estimated fair values, scenario distributions, projected yields, and payoff-region probabilities depend on assumptions and data. Do not treat a model estimate or the ratio of premium to maximum payout as a forecast of realized collective-writer return. Neither a particular return multiple nor a displayed probability is guaranteed.
9. Collective writers and Flat
9.1 Residual exposure. A collective writer sleeve owns settlement assets and owes the aggregate payout on its external option claims. Flat holders receive the applicable residual economic value, not a guaranteed return of principal. Buyer premiums remain assets supporting that same book; they are not immediately distributable profit.
9.2 Solvency is not profitability. The reserve calculation seeks to ensure sufficient assets for the worst aggregate settlement payout. A book can satisfy that condition while selling claims too cheaply, earning a poor risk-adjusted return, or consuming all committed writer principal in an adverse outcome. Economic-policy checks reduce selected risks but do not eliminate model error or loss.
9.3 An evolving book. Eligible issuance and close operations can change the sleeve's exposures within its applicable policy. A deposit is not necessarily a fixed short position in one strike. Review the current assets, external liabilities, reserve, principal, locked premiums, and policy version rather than relying only on a headline yield or total option count.
9.4 Withdrawal restrictions. An unused Funding-stage sleeve can permit withdrawal only under its specified conditions. During active exposure, ordinary on-demand redemption is unavailable. Ownership transfer leaves the sleeve's assets committed, and the transfer price may be far below the original deposit value.
9.5 Early close costs and limits. The current early-close mechanism requires a permitted amount of Flat and a proportional basket of outstanding long-option claims. You must obtain and deliver the required claims, meet deadlines and amount limits, and satisfy the final checks. A necessary claim may be unavailable or expensive. A close can be uneconomic, incomplete, or cancelled, and locked primary premiums remain in the sleeve rather than being paid to the early exiter.
9.6 No control right or liquidity guarantee. Flat does not itself confer a council vote or the right to change issuance, pricing, or risk policy. Transferability does not establish an active Flat market, and neither an ordinary withdrawal route nor a pooled buyback should be assumed merely because it appears in a research proposal.
10. AMBA, sAMBA, and emergency voting
10.1 Different assets and entitlements. AMBA is distinct from settlement collateral. sAMBA is a transferable share of the applicable AMBA staking pool, not a dollar-pegged deposit. A rising amount of AMBA backing each share does not guarantee a rising cash value of either token.
10.2 Waiting periods. The current staking design has a seven-day activation delay and a seven-day unstaking cooldown. Queued activation principal does not earn staking rewards or provide voting power. Unstaking burns shares and fixes an AMBA redemption amount under the current share ratio, with completion and withdrawal following the required steps.
10.3 Reward and access risk. Staking rewards depend on actual contributions to the reward mechanism, not a promised annual percentage yield. Required operations can be delayed or blocked by network conditions, protocol gates, or an unresolved emergency dispute. An unresolved dispute can restrict share-supply changes under its rules.
10.4 Voting risk. Emergency votes escrow sAMBA and require a valid reveal. In a decisive outcome, losing and unrevealed commitments can be redistributed to the winners. The specified failed-consensus path refunds commitments, but claiming the result can require additional operations. A vote is not a guaranteed return, and wealth concentration or coordinated voting can produce an incorrect result.
11. Governance, upgrades, and operational control
11.1 Council control. The current Devnet governance design uses a five-seat council with a three-seat approval threshold for its governed actions. The controller and registered target programs retain upgrade mechanisms. This is not a claim that the entire system is immutable, governed by all tokenholders, or free of concentrated control.
11.2 Freezes and changes. Governance or safety gates can block operations, and an upgrade can change executable behavior. Published checks, delays, and separated activation steps reduce selected risks but cannot guarantee that an authorized decision is beneficial or free of defects.
11.3 Frozen terms versus software. A versioned product definition or frozen oracle recipe is not the same thing as immutable application code, immutable governance, or permanent availability of an API. Review the actual deployment and applicable authority model. Do not assume that an old document or test receipt describes the current operational state.
12. Legal, tax, and participation restrictions
12.1 Legal treatment can differ by instrument, user, jurisdiction, and role. Synthetic options, collective residual claims, staking, and paid oracle participation need not have the same classification or requirements. The words "decentralized," "fully funded," "non-liquidating," or "software" do not themselves establish permission to offer or use a product.
12.2 Access restrictions, provider decisions, regulatory action, or a legal dispute can interrupt services or affect transfers, claims, and continued operation. A wallet connection is not a completed eligibility review. Do not bypass restrictions or treat an enabled button as legal authorization.
12.3 You are responsible for your own reporting and other applicable obligations. Transactions, rewards, token conversions, and dispositions may have tax or accounting consequences. Interface summaries are not a substitute for complete records or qualified advice.
13. Before committing assets
13.1 Confirm that you are eligible and that the environment is appropriate for the intended activity. Verify the network, program, token mint, benchmark version, UTC expiry timestamp, position size, premium, cap, fees, and maximum output or loss calculation. Distinguish test assets from real settlement assets.
13.2 Check the current market, oracle, governance, and claim status; the available liquidity; and any lockup, voting, challenge, or transaction deadline. For Flat or staking, review the separate exit rules rather than assuming a token can be redeemed on demand.
13.3 Use only assets you can afford to put at risk. If you cannot verify the product, understand the signed operation, or tolerate a loss or an extended inability to exit, do not enter the commitment. Contact [email protected] for a service issue without sending credentials; contacting support does not stop a protocol clock.
