Venue
Why Phoenix
A deterministic strategy needs a venue the program can read.
PerpTokens strategies are rules, not opinions: a vault has a target, and the program walks it back into band. A rule like that is only as good as the venue it runs on. If the program can't see the true cost of a trade before it makes it, "deterministic" is a label, not a property.
Most perp venues don't let the program see that cost. An oracle-priced pool prices your fill off an external feed's opinion of the market, and the impact of your own size is opaque until after the fact. An off-chain-matched book is worse for a program: your fill is a sequencer's promise, settled somewhere the on-chain logic can't inspect. In both cases the venue is a black box the contract has to trust.
Phoenix is different. It is a real central limit order book that lives entirely on-chain: the book is account state, the bids and asks are data the runtime can read. So the PerpTokens program reads the live order book in the same transaction it trades it. It doesn't ask an oracle what the price should be; it reads what the market actually is.
Exact mint and redeem
Because the book is readable, the vault walks real depth and computes the exact cost of resizing before it trades a single lot. That is what makes trader-paid maintenance honest. You can only charge the trader the true execution cost of their mint or redeem if the program can compute the true execution cost, and it can only compute it if it can read the book. An oracle-priced venue would force the protocol to guess; reading depth means it doesn't have to.
NAV you can verify
A vault's equity is marked against executable liquidity, not a feed's opinion of fair value. The price used to value your position is the price you could actually trade at, taken from the same book the vault trades on. The "read the program, don't trust the issuer" promise extends one layer down: read the program, and read the book the program reads.
Determinism end to end
Deterministic rules on a non-deterministic venue would be theater. If fills arrived as off-chain promises, the program could enforce nothing, because it couldn't see what it was enforcing against. Reading the book on-chain is what lets slippage bounds be real bounds: the vault knows the worst price it will accept, and the transaction fails rather than fills badly. The guardrail is enforced by the chain, not by trust in a matching engine.
Honest note
Phoenix is the execution venue, and it is in private beta. PerpTokens is the strategy asset layer built on top of it; it does not replace Phoenix. Read the Overview for how the two layers fit together.