Trading router

Entrypoints

TwoWayConstantProductRouter(factory) fixes the only eligible factory. All user mutations enforce a deadline and a reentrancy guard. The router's receiver callbacks accept only the active pool's canonical share token and universe IDs. receive() accepts ETH only during redemption and only from the expected SecurityPool.

• enterPosition(pair, longOutcome, minLongSharesOut, recipient, deadline) is payable. It creates actual complete-set shares from msg.value, verifies equal INVALID/YES/NO deltas, swaps all opposite shares, and delivers long shares plus INVALID. It returns ETH spent, complete sets, swap amounts, fee, and before/after Conditional YES prices.
• createPairAndInitializeWithEth(pool, conditionalYesBps, minLiquidity, recipient, deadline) creates or reuses the deterministic pair and requires it to be uninitialized before atomically seeding it.
• initializeWithEth(pair, conditionalYesBps, minLiquidity, recipient, deadline) initializes an already created canonical pair.
• addLiquidityWithEth(pair, maxYesUsed, maxNoUsed, minLiquidity, recipient, deadline) creates complete sets, deposits the authoritative proportional maximum, and returns INVALID and unused shares. It reverts with Liquidity price slippage when yesUsed > maxYesUsed or noUsed > maxNoUsed. minLiquidity alone does not bound the price: a swap toward even odds before the call raises both the deposit of the side with the smaller reserve and the minted LP.
• removeLiquidityWithPermit(pair, liquidity, minYesOut, minNoOut, recipient, deadline, v, r, s) tries the exact-amount ERC-2612 permit, requires an existing allowance if the permit fails, pulls LP, and returns raw YES/NO directly to the recipient.
• factory() exposes the immutable factory.
• onERC1155Received, onERC1155BatchReceived, and supportsInterface exist only for the receive-based operations described below and for the pair callbacks inside an operation.

Successful share-custody operations assert that all three router balances equal their starting values, preserving pre-existing forced shares.

Exits and complete-set redemption by share transfer

The router has no exitPosition or redeemCompleteSet entrypoint. Users exit and redeem by calling the ShareToken's safeBatchTransferFrom with themselves as both caller and owner, the router as recipient, and an encoded request in the data field. No setApprovalForAll is required. The versioned payload binds the operation, ShareToken, canonical SecurityPool and pair, universe, question, exact INVALID/YES/NO token IDs, transferred and maximum input, minimum ETH output, payout and refund recipients, and deadline. The router accepts only owner-initiated top-level transfers (operator == from); internal pair callbacks are distinguished from top-level user callbacks.

• Insured exit. The transfer carries exactly q INVALID and maxLongSharesIn long shares. The router buys exactly q opposite shares with an exact-output swap, redeems q complete sets at the pool, and returns any unused long shares to the bound refund recipient. It emits PositionExitedByTransfer.
• Complete-set redemption. The transfer carries exactly ordered, equal INVALID, YES, and NO amounts with no long outcome or maximum input. The router redeems them at the exact canonical SecurityPool and emits CompleteSetRedeemedByTransfer.

Both operations measure the ETH the redemption produced, require that delta to be positive and at least minEthOut, and forward exactly that delta to the payout recipient. Pre-existing forced ETH in the router is never mixed into a payout. Every operation also proves that it leaves the router's share balances unchanged.

For LP removal through the router, Safes and integrations without signature support may use ordinary exact allowances instead of a permit. The first-party UI calls the pair directly and needs no router allowance.