Roadmap Only (Target Q2 2026). This document describes future design intentions. x-baskets do not exist today.
Overview
x-baskets are the physically-backed counterparts to synthetic s-baskets. Each x-basket token represents a proportional claim on audited warehouse inventory.
| Token | Underlying | Synthetic Pair |
|---|
| xSEMIS | Cu, Al, Si, Sn, Ag | sSEMIS |
| xDEFENSE | W, NdPr, U₃O₈, Ni, Sb | sDEFENSE |
| xAERO | Ti, Ni, Al, Cu, Co | sAERO |
| xENERGY | Brent, Mars, Naphtha, NdPr, Poly | sENERGY |
Architecture
┌─────────────────────────────────────────────────────────────────┐
│ Physical Layer │
├─────────────────────────────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Warehouse A │ │ Warehouse B │ │ Warehouse C │ │
│ │ (Cu, Al) │ │ (Ti, Ni) │ │ (Crude) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └────────────────┼─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Receipt Registry │ │
│ │ (Off-chain) │ │
│ └────────┬────────┘ │
└──────────────────────────┼──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Protocol Layer │
├─────────────────────────────────────────────────────────────────┤
│ ┌─────────────────┐ │
│ │ Inventory Ledger │ ◄── Auditor attestations │
│ │ (On-chain) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ xSEMIS │ │ xDEFENSE │ │ xAERO │ ... │
│ │ Token │ │ Token │ │ Token │ │
│ └────────────┘ └────────────┘ └────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ NAV Oracle │ │
│ │ (Price feeds + │ │
│ │ inventory) │ │
│ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Market Layer │
├─────────────────────────────────────────────────────────────────┤
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ AP Create/Redeem │ │ Secondary Market │ │
│ │ (Institutional) │ │ (Retail access) │ │
│ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Token Contract
Properties
| Property | Value |
|---|
| Standard | ERC-20 (or chain-native equivalent) |
| Decimals | 18 |
| Supply | Variable (mint/burn on AP actions) |
| Transfer | Unrestricted |
| Upgradeable | (TBD — confirm) |
Core Functions
// Pseudocode - actual implementation TBD
interface IXBasket is IERC20 {
// AP mints tokens by depositing physical
function mint(
address to,
uint256 amount,
bytes32 depositProof
) external onlyAuthorizedParticipant;
// AP burns tokens to redeem physical
function redeem(
uint256 amount
) external onlyAuthorizedParticipant returns (bytes32 withdrawalId);
// Current NAV per token
function nav() external view returns (uint256);
// Total value of inventory
function totalInventoryValue() external view returns (uint256);
// Check if address is AP
function isAuthorizedParticipant(address addr) external view returns (bool);
}
Inventory Ledger
The on-chain ledger tracks physical holdings with cryptographic proofs.
Data Structure
struct InventoryRecord {
uint256 commodityId; // Which commodity
uint256 quantity; // Amount (in base units)
bytes32 warehouseId; // Which facility
bytes32 receiptHash; // Hash of warehouse receipt
uint256 depositTimestamp; // When registered
bytes32 auditorAttestation; // Latest audit proof
bool active; // Still in inventory
}
struct CommodityTotals {
uint256 totalQuantity; // Sum of all active records
uint256 lastAuditTime; // When last verified
}
Verification Flow
Warehouse Receipt
Warehouse issues receipt for deposited commodities. Receipt includes quantity, grade, location, date.
AP Registration
AP submits receipt hash to inventory ledger with supporting documentation.
Verification
Protocol verifies receipt authenticity (mechanism TBD—may involve oracles, auditors, or warehouse APIs).
Ledger Update
If verified, ledger records the inventory addition.
Periodic Audit
Third-party auditors verify physical inventory matches ledger. Attestation hash recorded.
NAV Oracle
The NAV Oracle combines price feeds with inventory data:
Calculation
NAV(t)=S(t)∑i=1nQi(t)⋅Pi(t)
Implementation
interface INAVOracle {
// Get current NAV per token
function latestNAV() external view returns (
uint256 nav,
uint256 timestamp
);
// Get inventory value breakdown
function inventoryBreakdown() external view returns (
uint256[] commodityIds,
uint256[] quantities,
uint256[] prices,
uint256[] values
);
// Total shares outstanding
function totalShares() external view returns (uint256);
}
Price Sources
NAV calculation requires commodity prices:
- Same Oracle Provider (TBD) as s-baskets
- Institutional-grade reference prices
- Update frequency: (TBD — confirm)
AP Network
Becoming an AP
Requirements (TBD — confirm):
| Requirement | Description |
|---|
| Capital | Minimum capital threshold |
| Compliance | KYC/AML and regulatory compliance |
| Operations | Ability to handle physical logistics |
| Agreement | Legal agreement with Scape |
| Technical | Integration with protocol systems |
AP Obligations
| Obligation | Description |
|---|
| Deposit verification | Ensure physical matches claimed |
| Timely settlement | Complete mint/redeem within SLA |
| Arbitrage | Help keep token price near NAV |
| Reporting | Provide required disclosures |
AP Incentives
| Incentive | Description |
|---|
| Arbitrage profit | Profit from price/NAV discrepancies |
| Fee rebates | Reduced mint/redeem fees (TBD) |
| Priority access | First mover on creation/redemption |
Mint/Redeem Mechanics
Mint (Create New Tokens)
AP Protocol Warehouse
│ │ │
│───Deposit physical────┼─────────────────────►│
│ │ │
│◄──────────────────────┼───Receipt issued─────│
│ │ │
│───Submit receipt hash─►│ │
│ │ │
│ │──Verify receipt──────►│
│ │ │
│ │◄─────Confirmed───────│
│ │ │
│◄───Tokens minted──────│ │
│ │ │
- Tokens minted = Deposit value / NAV
- Value based on commodity prices at mint time
- Mint fee deducted (TBD — confirm rate)
Redeem (Burn Tokens for Physical)
AP Protocol Warehouse
│ │ │
│───Submit redemption───►│ │
│ request + tokens │ │
│ │ │
│ │──Tokens burned───────►│ (token supply decreases)
│ │ │
│ │──Authorize withdrawal─►│
│ │ │
│◄──────────────────────┼──Physical released───│
│ │ │
- Physical returned = Tokens × NAV × (1 - fee)
- Specific commodities based on current inventory weights
- Redeem fee deducted (TBD — confirm rate)
Comparison: x-basket vs s-basket
| Aspect | x-basket | s-basket |
|---|
| Backing | Physical inventory | None (synthetic) |
| Pricing | NAV from inventory | Oracle feed |
| Instrument | Spot token | Perpetual contract |
| Leverage | None (1x only) | Available |
| Funding cost | None | Funding rate |
| Physical access | Via APs | None |
| Storage cost | Built into NAV | None |
| Venue | Secondary market | HIP-3 on Hyperliquid |
Risks
x-baskets have unique risks beyond s-baskets.
| Risk | Description |
|---|
| Physical loss | Warehouse fire, theft, damage |
| Custody failure | Custodian insolvency or fraud |
| Verification failure | False attestations or audit failures |
| Redemption delay | Physical delivery logistics |
| NAV manipulation | Incorrect price or inventory data |
| Illiquidity | Thin secondary market |
| Regulatory | Commodity-specific regulations |
