FiatExDocs

Build & operate

Deployment & verification

Check what is published, what is still inactive, and what must be verified before funds enter the contracts.

Published software is not a contract deployment

This documentation is built from the same release as the app. The manifest’s deployment flag is false. There are no official FiatEx factory, hook, router, oracle, or vault addresses to use yet. Launch and swap controls remain disabled.

The website, launchpad, documentation, and API can run while contracts are inactive. The buyback worker is included as software but is not funded or enabled. IPFS uploads remain unavailable until the operator configures Pinata.

Read the current API configuration
Check upload availability

Network configuration

SettingCurrent configuration
NetworkArc Mainnet
Chain ID5042
Native assetUSDC, 18 decimals
RPChttps://rpc.mainnet.arc.io
Pool-facing USDC0x3600000000000000000000000000000000000000, 6 decimals

These are integration settings, not confirmation that FiatEx has deployed on the network. Verify network identity, third-party bytecode, and the official Arc references before deployment. Never substitute a testnet verifier into a mainnet manifest.

Visit the official Arc website

What has been checked

The local contract checks cover routing, fee splits, opening prices, permanent liquidity, bonding, buyback queues, price guards, and burns using the real v4 PoolManager implementation. Backend checks cover event accounting, node policy, upload validation, and keeper recovery. Production builds and browser checks cover the interface.

Those checks are not an independent audit. They also do not prove Arc precompile behavior, live UniversalRouter/Permit2 integration, wallet batching, oracle availability, or a deployed contract’s identity.

Before activation, verify deployment receipts, bytecode, hook flags, contract wiring, oracle feeds, vault, deposit, start block, and matching ABIs. Exercise create, buy, sell, refund, gas, and transfer-restriction behavior on the actual Arc runtime.

Release and rollback boundaries

Web releases use a new directory and preserve the previous version. A schema change uses a fresh database schema, with the old data retained. The frontend only enables transactions when the app and API agree on the deployment and buyback support.

Rolling back a website does not roll back immutable onchain pools. Stop and reconcile any keeper transaction before an operational rollback, then restore a matching app, API, manifest, and schema.