Contracts

Plain Answer

Arenaton does need contracts, but not one new Solidity contract per Market.

Contracts are deployed per environment and version. A new Market is usually a condition prepared inside the Gnosis Conditional Tokens Framework contract. Preparing a condition is an on-chain transaction, but it is not a new contract deployment.

Contract Deployment Vs Market Creation

Action	What it means	Frequency
Deploy contract	Publish Solidity bytecode and get a contract address.	Per environment or contract version.
Prepare condition	Create a CTF record for one Market question and outcome set.	Per Market.
Publish registry	Make public clients and backend services agree on addresses.	Every environment update.

For binary Arenaton Markets, ArenatonCTFMarketFactory.prepareBinaryMarket(...) prepares a CTF condition with 2 outcome slots, stores immutable Market terms, and emits MarketPrepared for indexers.

Production And Paper Constraints

• Production chain: Polygon PoS 137.
• Production collateral: Polygon USDC from the production registry.
• Production CTF and resolver addresses: registry-controlled and production-gated.
• Paper chain: Polygon Amoy 80002.
• Paper collateral: PaperUSDC.
• Outcome Shares use Gnosis Conditional Tokens Framework concepts/contracts where possible.

What Gets Deployed

Environment	Chain	Collateral	Contract work
Local	Anvil 31337	Local PaperUSDC	Deploy locally only as needed for tests/dev.
Paper Trading	Polygon Amoy 80002	PaperUSDC	Deploy PaperUSDC, Conditional Tokens if no approved Amoy address is used, ArenatonCTFMarketFactory, ArenatonCTFSettlement, and ArenatonCTFResolver.
Production	Polygon PoS 137	Polygon USDC	Use audited/approved CTF deployment where possible. Deploy Arenaton-specific contracts only after production gates.

Registry

The app and server read environment-specific contract addresses from /api/contract-registry.

The registry must bind:

• Chain ID.
• Collateral token.
• Settlement/verifying contract.
• Conditional Tokens Framework addresses.
• ArenatonCTFMarketFactory.
• Paymaster adapter configuration.
• Environment name.

Published registry artifacts must validate chain/environment matches and reject active registries with missing PaperUSDC, Conditional Tokens, market factory, settlement, or resolver addresses. Apps should consume the same approved registry source rather than retyping addresses manually.

What The Factory Can And Cannot Do

ArenatonCTFMarketFactory can:

• Prepare binary CTF conditions.
• Store immutable Market terms.
• Emit MarketPrepared.
• Enforce the 0.25% Fee Ceiling.
• Restrict preparation to the owner or configured operators.

It cannot:

• Transfer user USDC.
• Transfer user Outcome Shares.
• Split, merge, or redeem Outcome Shares.
• Change Market terms after preparation.
• Create an Arenaton-held user balance.

User Collateral and Outcome Shares stay in Smart Accounts, Raw EOA Mode accounts, and audited CTF/settlement contracts.

Settlement Contract

ArenatonCTFSettlement is the first matched-fill settlement contract shape. It verifies Arenaton EIP-712 orders, supports Raw EOA signatures and ERC-1271 Smart Account signatures, validates Market/condition/collateral/chain/verifying-contract/live-state/fee fields, and then atomically transfers Collateral and Outcome Shares between user-controlled accounts.

It supports two settlement paths:

• Primary binary matching: complementary buy YES and buy NO orders settle by splitting Collateral into CTF YES/NO Outcome Shares.
• Secondary resale: same-outcome buy/sell orders settle by transferring existing Outcome Shares from seller to buyer.

It tracks partial fills by order digest, rejects duplicate fillId retries, rejects canceled/expired/stale orders, and emits settlement, account, signature, and position-delta events for indexers. It is still unaudited and is not real-money launch approval.

Read CTF Paper Mode for the paper-mode version of this flow.

Resolver Contract

ArenatonCTFResolver is the first resolver authority model. It should be the CTF oracle address for Arenaton-prepared Markets.

After the published correction window ends, an owner or configured resolver operator can report the final binary payout:

• YES: [1, 0].
• NO: [0, 1].
• Invalid: [1, 1].

The resolver records the source hash, source URI, correction-window end timestamp, finalization timestamp, resolver address, and payout vector. It cannot move user Collateral or Outcome Shares and cannot change finalized payouts.

Market Lifecycle Through Contracts

Market prepared
  CTF condition exists.

Trading open
  users sign EIP-712 orders off-chain.

Settlement
  primary fills split Collateral into CTF YES/NO Outcome Shares.
  resale fills transfer existing Outcome Shares.
  position-delta events feed indexer projections.

Resolution
  resolver/oracle reports payouts according to published rules.

Redemption
  users redeem directly from contracts.

Invalid Markets And Redemption

Invalid Markets are resolved through CTF payouts, not through an Arenaton internal refund balance.

For first-launch binary Markets:

• Valid YES outcome: [1, 0].
• Valid NO outcome: [0, 1].
• Invalid Market: [1, 1].

With [1, 1], each binary Outcome Share redeems for 50% of one unit of Collateral. Users redeem directly through CTF redeemPositions(...); Arenaton can prepare UX and transaction data, but direct redemption must remain available.

Production Readiness

No unaudited custom settlement contracts should be used for public real-money trading.

Minimum contract checks include unit tests, fuzz/invariant tests, Polygon fork tests, EIP-712 replay tests, fee-ceiling tests, Live State Version tests, paymaster abuse tests, and indexer reorg tests.

Contract evidence should include custody-boundary checks for the current factory, settlement, and resolver contracts before a registry is treated as launch-ready.

Deploying contracts on Polygon PoS does not by itself approve real-money launch. Production remains blocked until contract audits, fork tests, indexer, paymaster, geo/risk, data vendors, market-maker monitoring, and incident gates are complete.