🔀 Integrating as a Distributor? (Wallets, DEX Aggregators) → LINK

📈 Integrating as a Market Maker? (RFQ, Executor Contract) → LINK

📖 Need general reference? (Contract addresses, token support, flow overview) → LINK

1. Overview & Common Reference

Simple flow of PCSX

  1. The Filler responds to RFQ requests from the PCSX Order Price API.
  2. The PCSX Order Price API replies the Swapper with the best order quote
  3. The Swapper approves Permit2 to move their funds
  4. The Swapper signs the order, including the Permit2 signature and submits to the PCSX Order Handler API
  5. The Filler receives the order over the RFQ interface, checks if the order is correct and profitable, and submits to the Filler contract (Executor)
  6. The Executor calls the Router's typed by-type entry point executeByTypeWithCallback(reactorType, order, callbackData) (selector-stable) with the order info
  7. The Router checks the order info and the signature, and transfers the input token from the Swapper to the Executor. (PCSX does not accept native token as input)
  8. The Router then calls the Executor reactorCallback and performs the Executor swap logic
  9. The Executor should allow the Router to transfer the output token from the Executor to the Router (or transfer the native token to the Router at the end of the swap logic)
  10. The Router transfers the output tokens from Executor to its own, checks if the output amount is correct and transfers the output token to the corresponding recipients

Exclusivity

Order Time Person eligible to fill
User signs the order → decayStartTime Exclusive filler only (or filler willing to pay the exclusivityOverrideBps penalty)
decayStartTime → decayEndTime (decay starts) Anyone can fill
decayEndTime → deadline (decay stops) Anyone can fill

Native token support

PCSX only supports Wrapped native token as input. When a user swaps from native tokens to any tokens, our frontend will wrap the native token, get quote on the Wrap native token and send the token to the PCSX contracts. Therefore, in order to maximise the gain, we suggest all Market Makers to support both native token and Wrap native token pairs.

What's new: MultiReactor Router + V4Dutch

One Router address per wallet family now fills every order type. PCSX is migrating from per-version reactor addresses (a separate address for each of ExclusiveDutch / V3Dutch / V4Dutch) to a single stable MultiReactor Router per family. The Router fills all current and future order types, and its address never changes across upgrades or when new types are added.

Because one address serves several order types, the address no longer tells you the order type — resolve the type by decoding the order (below), and every on-chain call selects the function for that type.