Explanation

Trading architecture decisions and limitations

Trading is deliberately small. This page records why each decision was made and which features are out of scope, so that future work does not weaken the pair's one hard invariant.

Decisions

  1. Two reserves only. YES × NO avoids the three-way quadratic and does not price INVALID.
  2. Exact SecurityPool identity. A pair is keyed by the pool address, validated through both factory lineage and the ShareToken's universe mapping. SecurityPool address → factory → one deterministic pair is the market identity; parent and child branch pools always map to different pairs even when they share one ShareToken. The pair derives token IDs from its pool's universe using the local ordering Invalid, Yes, No.
  3. One immutable fee per factory. There is no owner, protocol fee switch, or mutable parameter.
  4. Balance-delta integration. Complete-set creation and redemption use actual observed balance and attoETH deltas because Zoltar collateral retention changes the ETH-to-share rate. The router never assumes a fixed ratio, preserves pre-existing forced ETH and token balances, and restores its starting share balances before completing an operation.
  5. Minimum-reserve LP scale. The initializer receives min(YES, NO) − 1,000 LP units, and another 1,000 units are permanently locked. Total initial supply is min(YES, NO). Proportional ownership, not the absolute token count, is authoritative.
  6. Donations accrue to LPs. State-changing paths synchronize higher actual balances; balances below recorded reserves revert. The pair rejects INVALID and foreign shares in ERC-1155 callbacks, uses uint256 reserves, and keeps fees in reserves. Its constructor quarantines canonical shares sent to the predictable CREATE2 address before deployment.
  7. No automatic fork behavior. Parent liquidity is removed as parent shares. The user explicitly chooses migration targets and initializes distinct child pairs.

Limitations and non-goals

The MVP intentionally does not implement a three-way invariant, INVALID trading, an invalidity-probability oracle, weighted reserves, quadratic solvers, flash swaps, a protocol fee, governance controls, upgradeable proxies, automatic branch selection, automatic LP migration, an insured-position NFT, or per-user on-chain position accounting.

It also has no TWAP, routing across markets, guaranteed deep liquidity, or mechanism to withdraw more early ETH than complete-set insurance and reserves permit. Spot prices are manipulable and must not be used as protocol oracles. Live mode derives and verifies the deterministic trading contracts on a supported canonical core network. Public deployments require gas benchmarks against a real-core funded lifecycle fixture, adversarial integration testing, and an external audit; see the Trading security model.

Future work may add separate INVALID markets, safer oracle observations, routing, or bounded convenience flows. Those are distinct designs and must not weaken the invariant that this pair never accepts or holds INVALID.