<aside> 🔀

A newer router-based guide is available → PCSX Tech Integration Guide V4. This V3 guide stays valid for legacy standalone reactors and in-flight orders during the phased MultiReactor Router rollout.

</aside>

🔀 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 Reactor executeWithCallback with the order info
  7. The Reactor 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 Reactor then calls the Executor reactorCallback and performs the Executor swap logic
  9. The Executor should allow the Reactor to transfer the output token from the Executor to the Reactor (or transfer the native token to the Reactor at the end of the swap logic)
  10. The Reactor 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: V4 reactor (long-duration orders)

V4 is V3 with a much longer decay window. An order can now decay over days or weeks instead of hours — enabling e.g. 30-day limit orders. The order fields, signing flow, and fill mechanics are identical to V3; only the EIP-712 struct names (V4DutchOrder / V4DutchInput / V4DutchOutput) and the internal curve encoding changed. V4 is live on BSC first (addresses below); V3 stays live on all chains and the two run side by side. Everywhere else in this guide, what is said about V3 applies to V4 too unless noted.