Architecture — why it's built this way

• Two contracts, not one.

  VellichorVault.sol handles primary sale, bottle data, and redemption. VellichorMarket.sol handles secondary resale, with units escrowed in the market contract while listed. Separating them keeps redemption logic (which only needs to know about outstanding balances) independent from marketplace logic (which needs escrow, listings, and fees).

• ERC-1155, not ERC-721.

  Vault Units are fungible fractions of one bottle, not unique collectibles — ERC-1155 supports many units under one token ID natively, without needing 100 separate ERC-721 tokens per bottle.

• Off-chain redemption fulfillment.

  Covered in the Redemption page — shipping/KYC data doesn't belong on a public, permanent ledger.

• View-function reads, not indexing, at current scale.

  getAllBottles(), getPortfolio(), getActiveListings(), and getListingsBySeller() loop on-chain data directly. This is fine at Genesis Vault scale (a handful of bottles and listings) and free to call (view functions, no gas for reads) — but should move to an off-chain indexer if the catalog grows large enough that looping gets expensive to query.

• Payment token is swappable.

  Both contracts take paymentToken as a constructor parameter rather than hardcoding a token address — live on mainnet using the real USDG token, after testing against TSLA on testnet during development.