@FermiTrade utilises Application-level ACE design on Solana L1, to enforce FCFS execution of transactions, and bypass validator ordering. As this is a novel design, It's useful to clarify what this means for you as a user, in terms of trust assumptions and guarantees offered: 1. Which components are onchain, and which are offchain? A: The full program execution logic, including order placements, cancellations, margin/health computation, matching, settlements, and liquidations lives onchain. We provide two additional offchain components - a transaction ordering service; and a simulation layer for fast pre-confirmations of transactions before a block has been built 2. What are the offchain components for? A: Currently on Solana, tx. ordering and inclusion are entirely dependent on the leader. Our ordering service is an opt-in deterministic ordering route. Using it allows you to get fast preconfirmations, and guaranteed sequencing onchain. The queue position is then enforced via an Asynchronous Market Queue on Solana. 3. How does this design override validator behavior? A: AMQs utilize a two-step (enqueue, then execute) execution model. This means, say for three transactions 1,2,3 - the validator can choose to add them to an onchain queue in any order - say 3,1,2. It does not matter, because when the "execute" step is called, the onchain program goes over the full queue, and executes it in the correct order (1,2,3) anyways. 4. Do all order placements, cancellations, risk checks, margin computations, matching logic, liquidation logic, and settlement logic, live onchain? A: Yes. Similar to many other fully onchain perpetuals exchanges, every action you take on our exchange is executed on the Solana L1. The state transition, as well as validity, collateral, and signature checks, are performed by the solana program for every action - and are visible on the L1 via your favorite block explorer. 5. How does this design offer low latency pre-confirmations? A: Normal solana programs cannot always predict what will happen to your transaction, as the execution result is dependant on the ordering decisions of the leader. By eliminating this leader discretion, we can predict the exact execution outcome of your transaction, as soon as the ordering service assigns it a sequence. Our high certainty comes from knowing that the onchain program will reject any out-of-order execution, so any other outcome is virtually impossible. This is the method behind the sub-5ms pre-confirmations; even before the block is built. 6. Does the relayer handle transaction delivery for me? A: Yes, for transactions routed through the ordering service, the relayer is the one actually delivering the transaction to the leader. This does two things - First, it abstracts away L1 delivery semantics, priority fees, and other issues from the user - the relayer handles all of it, including retries, so you never have to deal with failed transactions due to L1 jitter. Second, it ensures that users cannot use ordered transactions as an option after the fact, and ensures transactions execute in the promised order for all users. 7. Can the relayer censor my transaction? I. before preconfirmation - temporarily (for a few ms) at most - it's akin to a network drop, and you can always route around the sequencer. This is subject to blind inclusion rules below. II. after preconfirmation - not without leaving clear, onchain proof. Every preconfim is allocated a sequence and a relayer-signed receipt is provided to the user. To skip a sequence number, an onchain “emergencySkip” command would have to be invoked - if misused, visible to everyone. III. upon direct submission - never. Direct submission of all transaction types remains possible for all users. Subject to a small speedbump, the relayer cannot block execution of direct transactions in any circumstances. 8. Can the ordering service access my funds? A: Never. Your funds are secured purely by the onchain program logic, similar to any other fully onchain perpetuals exchange on solana. 9. Can any of the offchain components halt the protocol? A: No. The MEV-resistant ordering service is designed as a fast-path convenience; the protocol continues to operate if it goes offline. All the liveness critical components, such as keepers, executors or liquidators are permissionless, and can be operated by anyone. Expired or failing orders that are blocking the queue head can also be dropped permissionlessly. 10. Can the relayer modify my transaction, or otherwise execute a trade I did not intend, on my behalf? A: No. All order intents are signed by you, and the signatures are verified onchain on solana. If the relayer attempted to spoof a transaction, it would simply fail. Transaction intents also come with replay protection built in by default. 11. Can the relayer/sequencer frontrun my orders? A: This is a trust assumption of all other single sequencers, as well as leaders in blockchains today. Fermi aims to minimize this risk by offering timelock encryption on transactions - so that even the sequencer cannot see the content of your transaction before ordering & preconfirming it. This provides the highest degree of frontrunning resistance available in the market today. 12. Can I skip using the ordering service in order submission? Can I place orders via a CPI? A: Yes. You may choose to entirely ignore the ordering service and simulation layer, forgo the deterministic ordering, and transact directly with the fermi programs onchain - subject to a small speedbump. All existing program functions may be accessed via this route. You can dive into our docs for more info. Always happy to clarify any other specific questions!

"No frontrunning" is a critical property for a world exchange. Recent events on Solana[1], Fomo[2], and other exchanges[3] show that plaintext orderflow can and will be exploited by actors across the supply chain. Encryption is one option - eg. BTX on monad[4]. However threshold encryption comes with a major latency penalty. We bet on timelock encryption as the ideal middle ground between fast execution and secure transaction privacy. [1]xitter.cf/andreivacariu_/status/… , xitter.cf/TheDEFIac/status/20983… [2]xitter.cf/AmirOrmu/status/210358… [3]xitter.cf/0xngmi/status/21000259… [4]xitter.cf/keoneHD/status/2074621…