— Contents 11 sections
- 01 Is the Phoenix referral code “TFJA22W2” still active?
- 02 What the Phoenix referral code “TFJA22W2” gets you
- 03 Phoenix sign-up steps with the referral code
- 04 What to do after connecting to Phoenix
- 05 The Phoenix referral code cannot be added after sign-up
- 06 Phoenix settles on Solana and charges every trader the same fee
- 07 Phoenix ranks 33rd by perpetuals volume and 17th by protocol fees
- 08 Phoenix excludes three named countries and reserves the right to add more
- 09 The US and the UK are closed; Singapore, Australia and India are not
- 10 The perpetuals program is unaudited, unpublished, and upgradeable by a single key
- 11 The code is live, and the open questions are audit coverage, gating and scale
chainhelm’s exclusive Phoenix referral code is .
As of 2026-08-08, we connected a new wallet and confirmed that the referral code was applied.
The code rides on the referral link, so it applies as you connect your wallet: an ongoing 10% discount on your trading fees, not a one-time perk. What matters is opening the link before you connect.
This article covers the sign-up process (wallet connection) with the Phoenix referral code, Phoenix’s distinguishing features, availability in the United States, the United Kingdom, Singapore, Australia and India, and the risks to acknowledge — with the connection flow and code application verified first-hand by chainhelm’s editorial team.
Is the Phoenix referral code “TFJA22W2” still active?
The chainhelm editorial team connected to Phoenix with a fresh wallet on 2026-08-08 and confirmed that the referral code “TFJA22W2” is still active.
Here is the actual screen captured during verification.
chainhelm continuously verifies the validity of the code and confirms it remains usable.
The code has two surfaces and one identity. TFJA22W2 is the string; https://phoenix.trade/?code=TFJA22W2 is the same code carried inside a URL. Both point at the same attribution, and in practice you only ever handle the link.
That is not a stylistic preference. No code entry field appeared at any point of our walkthrough on 2026-08-08, so on that route there was nothing to type. Attribution is automatic and it rides on the URL: open the link, connect a wallet, and the code is attached to that wallet.
The flow also shows you nothing back. Through the whole walkthrough on 2026-08-08 there was no “referred by” line and no confirmation screen at any point of sign-up. The referral page inside the app is a referrer-side view that a newly referred user has no way to reach, so there is no display to inspect afterwards either. That is why the entire verification burden sits on the one action at the start — opening the link — rather than on checking a screen once you are through.
One more gate sits above all of this. The venue’s own status endpoint reported gated=true on 2026-08-06, meaning access is invite-gated at the application layer, and Phoenix opened as a waitlisted private beta on 2025-12-11 with no announcement of a fully open launch since. Connecting a wallet is not the same thing as being admitted to trade, and in practice the referral link doubles as the access path.
What the Phoenix referral code “TFJA22W2” gets you
Apply this code when you connect to receive the following benefits on Phoenix:
The benefits ride on the referral link, so start from that link rather than from the bare site address when you connect your wallet.
One piece of context makes that discount easier to place. Phoenix charges every trader the same published rate: there is no volume tier to climb toward and no staking tier to buy into, so the discount comes off a flat schedule rather than off a rate you would first have to earn. The schedule itself is further down, in the section on what a trade costs.
Phoenix sign-up steps with the referral code
We cover the connection process separately for PC/browser and smartphone (mobile).
PC/browser connection steps
- First, open the Phoenix official page (the link applies the referral code). When you open it, you’ll see a screen like the one below.
The code travels inside that URL, so opening the link is the whole of applying it. It is also how you reach the sign-in screen at all while the venue is invite-gated.
2. Choose “Connect new wallet”
Click “Connect new wallet” at the top of the sign-in options to sign in with a crypto wallet rather than an email address, and the wallet picker opens next. The bar above the options tracks the three stages of onboarding — “Sign In”, “Create account”, and “Access Phoenix” — with the first one lit.
3. Pick “Phantom” as your wallet
In the “Select your wallet” dialog, click “Phantom” to hand the connection over to that wallet, and Phoenix waits for it to respond. “Solflare” is the other wallet offered here, so choose that one instead if it is what you already use.
Those two are what the picker offered on the day we walked it. Phoenix routes wallet connection through Privy, which also supports signing in with an email address or another provider and provisioning an embedded wallet for you rather than requiring you to bring one. That route exists; it is not the one we tested, so treat it as an option rather than as a verified path.
4. Wait for Phantom to answer
Hold off for a moment while “Waiting for Phantom” is on screen — Phoenix is passing the request across, and Phantom opens its approval window on its own. The same screen asks you to keep only one wallet connected at a time.
5. Approve the connection in Phantom
Check that the request comes from “phoenix.trade”, then click “Connect” to approve it and return to Phoenix. Phantom spells out what you are granting — the site can view the balances and activity of the selected account — and “Cancel” backs out if the domain is not the one you opened.
6. Switch to Phantom to sign
When “Sign message to continue” comes up, switch to Phantom and approve the signature request waiting there. Phoenix sits on this screen until the wallet replies, with the stage bar now on “Create account”.
7. Confirm the “Sign Message” request
Click “Confirm” on the “Sign Message” request to sign it and finish signing in. Phantom names “phoenix.trade” and explains that the signature proves you own the selected account, so check the domain before you confirm; “Cancel” turns the request down.
If you have not signed a message before: this is not a transaction. Signing proves that you control the wallet address, and that is all it does. It moves no funds and it grants no permission to spend anything.
Smartphone (iOS / Android) connection steps
- First, open the Phoenix official page in your mobile browser or your wallet app’s in-app browser (the link applies the referral code). When you open it, you’ll see a screen like the one below.
2. Tap “Connect new wallet”
Tap “Connect new wallet” at the top of the sign-in sheet to sign in with a crypto wallet rather than an email address, and the wallet picker comes up next. The bar above the options marks the three stages — “Sign In”, “Create account”, and “Access Phoenix” — with the first one active.
3. Tap “Phantom” in the picker
Tap “Phantom” in the “Select your wallet” sheet to hand the connection over to that wallet, and Phoenix waits for it to respond. The other choice, “Solflare”, works the same way if that is the wallet you keep on your phone.
Those two are what the sheet offered on the day we walked it. Phoenix routes wallet connection through Privy, which also supports signing in with an email address or another provider and provisioning an embedded wallet for you rather than requiring you to bring one. That route exists; it is not the one we tested, so treat it as an option rather than as a verified path.
4. Wait for Phantom to answer
Leave the “Waiting for Phantom” sheet as it is while the request travels across to the wallet, and Phantom takes over with its approval prompt. The sheet also asks you to keep only one wallet connected at a time.
5. Approve the connection in Phantom
Check that the request comes from “phoenix.trade”, then tap “Connect” to approve it and go back to Phoenix. Phantom states the scope up front — the site can view the balances and activity of the selected account — and “Cancel” backs out if anything looks off.
6. Switch to Phantom to sign
When “Sign message to continue” appears, switch over to Phantom and approve the signature request waiting there. Phoenix keeps this sheet up until the wallet replies, and the stage bar has moved on to “Create account”.
7. Confirm the “Sign Message” request
Tap “Confirm” on the “Sign Message” request to sign it and finish signing in. Phantom names “phoenix.trade” and explains that the signature proves you own the selected account, so check the domain before confirming; “Cancel” turns the request down.
If you have not signed a message before: this is not a transaction. Signing proves that you control the wallet address, and that is all it does. It moves no funds and it grants no permission to spend anything.
What to do after connecting to Phoenix
We cover the deposit process separately for PC/browser and smartphone (mobile).
PC/browser deposit steps
Click “Deposit” in the top bar to open the “Deposit USDC” dialog, which already has your “Connected wallet” set as the source.
Type the amount into the “Amount” field, or click “MAX” to pull in everything the wallet holds, then send it with “Submit Deposit”. The “Available funds” line under the field reads $0.00 USDC here, so the button stays gray until there is USDC to move.
If your stablecoins sit on another chain, take the “Deposit from Anywhere” route at the foot of the dialog, which sends stablecoins from Solana or another chain to a deposit address.
USDC is the only thing the venue accepts as collateral. What you deposit does not stay as ordinary Solana USDC either: it is wrapped one-for-one through Ember into the venue’s own Phoenix USD mint before it reaches the exchange. The documentation says other collateral assets may be added later, without naming any or giving a date.
Funding from another chain is the one deposit detail with a live cost attached. Deposits can start on Solana, Ethereum, Base, Arbitrum or HyperEVM, but Phoenix runs no bridge of its own — cross-chain deposits are routed through the third-party Relay integration, which does both the swap and the bridging. The quote you see in the dialog comes from Relay and moves with source-chain gas at the moment you ask for it, so the amount that lands can differ from the figure you were first shown. Read the quote at the moment you submit, not the one you read a few minutes earlier.
There is no published floor. As of 2026-08-06 the official documentation states no minimum deposit.
Smartphone (iOS / Android) deposit steps
Tap “Deposit” to open the “Deposit USDC” sheet, which already has your “Connected wallet” set as the source.
Enter the amount in the “Amount” field, or tap “MAX” to pull in everything the wallet holds, then send it with “Submit Deposit”. The “Available funds” line reads $0.00 USDC here, so the button stays gray until there is USDC to move.
If your stablecoins sit on another chain, take the “Deposit from Anywhere” route at the bottom of the sheet, which sends stablecoins from Solana or another chain to a deposit address.
Once the deposit is credited, the funds are available in the account and you can start trading.
The Phoenix referral code cannot be added after sign-up
The referral code can only be applied once — the first time you connect your wallet.
If you complete the connection without the code applied, there is no way to link it to that wallet afterwards, and the only route left is to start over with a new wallet.
There is not much for you to check, and that is the honest position rather than thin advice. No code entry field appeared at any point of the 2026-08-08 walkthrough, so a reader who suspects they missed a box on that route has not missed one. And nothing is confirmed back to you afterwards: no referee-side confirmation appeared anywhere in that walkthrough, and the referral page inside the app is a referrer-side view rather than an answer for a new account. The only reliable control you hold is the one at the very start, which is opening the link itself.
◆ ◇ ◆
Phoenix settles on Solana and charges every trader the same fee
Phoenix has been a perpetuals venue for about eight months, it settles every order on Solana itself rather than beside it, and it charges the same rate to a first-day trader as to its largest market maker. Those three facts carry most of what follows.
The operator, the developer, and how the venue got here
First, which Phoenix. Search results for the bare name turn up several unrelated companies that share it. The one this article is about is the perpetual futures venue at phoenix.trade, built by Ellipsis Labs and running on Solana.
Two entities sit behind it, doing different jobs. The Terms of Service name Solstice Technologies S. de R.L., a company organized under the laws of the Republic of Panama, as the operator that runs the frontend and the related services. Ellipsis Labs is the protocol developer. Ellipsis Labs’ own jurisdiction of incorporation is not disclosed on its site and no primary source for it was located, so this article does not assert one.
The dating matters more than the sequence. Measured from that private beta, the perpetuals venue was roughly eight months old at the research date, and the sections below on scale and on risk should both be read against that number rather than against the 2023 spot launch.
An order book that lives on Solana, not beside it
The matching engine is a program deployed on Solana mainnet-beta itself. Not an appchain, not a rollup, not a separate layer built on top — the code runs on the same chain your wallet already talks to, which is why orders, fills and cancellations all end up recorded on the Solana ledger.
What that program runs is a central limit order book with first-in, first-out price-time priority: the ordinary exchange model, with the order book itself held on chain. Settlement is crankless, meaning matching and settlement finish inside a single Solana transaction rather than being swept up afterwards by an external process. On venues that do use such a process, the trade and its settlement are two separate on-chain events; here they are one.
Alongside ordinary resting orders, Phoenix accepts what it calls spline liquidity. A market maker publishes a mid price plus bid and ask regions with a density per tick, and the engine turns those regions into visible price levels when it builds the book. Spline liquidity matters because it accounts for a book that looks deeper than the transaction count would suggest: one instruction can express what would otherwise be dozens of separate orders. It is a statement about how quotes get posted, not a claim about the execution you will get.
Sixty-two markets, one collateral asset
The equity side is where Phoenix stops looking like every other perpetuals venue. It is mostly US-listed names, plus one pre-IPO name and one listing from outside the United States, and it is the single largest source of the regulatory exposure discussed further down. The commodity markets are gold, silver, copper and WTI crude.
Accounts are addressed as a pair: a portfolio index and a subaccount index. Subaccount 0 is the cross account, with one shared collateral pool backing up to 128 open positions at once. Any subaccount above 0 is isolated: it holds a single position, and once collateral is allocated to it, losses there do not automatically reach back into the cross account. Six markets can only be traded in an isolated account — GOLD, SILVER, COPPER, WTIOIL, ANSEM and SKR. That is the whole of what you need to pick an account type; the margin arithmetic sits in the risk section.
A flat fee schedule, plus funding and builder costs
0.5 bps maker and 3.5 bps taker, identical across all 62 markets, with no volume tiers, no staking tiers and no token to holdPhoenix documentation and markets API, 2026-08-06
The documentation puts the same schedule in money: a USD 10,000 trade incurs USD 3.50 in taker fees, or USD 0.50 if you are the maker. The live API returns the identical maker and taker figures for every active market, so this is not an entry rate that someone else has already beaten.
That flatness is the whole point. On most perpetuals venues the lowest rate sits behind a volume tier, a staking tier or a market-maker agreement, and the rate a new account pays is not the rate the venue advertises. Here the entry rate is the only rate, and the referral discount is the one documented way below it. There is also no protocol token as of 2026-08-06, so there is no token-linked discount to chase either.
Funding is separate from fees and is where a held position quietly costs or earns money. It accrues on hourly snapshots and settles over a 24-hour period, uniformly across every market. When the mark price sits above the index, longs pay shorts; when it sits below, the flow reverses. The rate is clamped per market, and on 2026-08-06 the live per-interval cap ranged from 0.172% to 0.433%.
Gas is the simplest line. Solana network fees are the base-layer cost, and because settlement is crankless there is no separate settlement or crank charge on top; no protocol-level gas surcharge is documented.
The cost fact most likely to trip you up is the last one. Phoenix’s Flight builder codes let any registered third-party interface set its own fee in basis points, and that fee stacks additively on the base taker fee, applying only to trades that take liquidity. The documentation publishes no cap and no permitted range for it. So the schedule quoted above is the cost of trading directly at phoenix.trade, and not necessarily the cost of the same trade routed through somebody else’s terminal.
Phoenix ranks 33rd by perpetuals volume and 17th by protocol fees
Where Phoenix sits on the public tables
Against a whole-market total of USD 17.742 billion in 24-hour perpetuals volume, that puts Phoenix at 0.25% of the category. Small, and worth saying plainly.
The gap between the two ranks is the interesting part. Sitting 33rd by volume and 17th by fee revenue on the same day means the venue earns more per unit of volume than its volume position implies — a consequence of what it lists and who trades it, not of a higher published rate.
Open interest gets no rank here because none is published: DefiLlama’s perpetuals table is ordered by volume, and its open-interest ordering sits behind a paid API tier. Rather than substitute an estimate, this article leaves the rank absent and gives the figure itself. Open interest, not total value locked, is the metric that answers how big this venue actually is — the reason for that is in the qualifiers below.
One absence is worth reading correctly. Phoenix does not appear among the 135 derivatives exchanges returned by CoinGecko’s derivatives endpoint, and no CoinMarketCap derivatives-exchange listing was located as of 2026-08-06. That is a coverage gap on the aggregator sites, not a finding about the venue.
The design choices that set it apart
Two of the differences are worth a proper explanation, because they are what a choice between venues actually turns on.
The first is the crankless on-chain order book. Plenty of perpetuals venues run their matching engine off chain and settle to a chain periodically; others have no book at all and price positions from an oracle against a pool. Phoenix does neither: the book is a Solana program, and matching and settlement complete in one transaction. That design is not free — everything is bounded by what a Solana transaction can do — but the resulting record is fully on chain.
The second is the real-world-asset markets and the pricing mechanism underneath them. Equity and commodity perpetuals keep trading after the market they reference has closed for the day. Index prices for equities aggregate pre-market, regular, post-market and overnight sessions, and when external pricing is unavailable the venue switches to Impact Pricing, an internal mechanism derived from Phoenix’s own order book. That fallback is what makes round-the-clock trading of a closed market possible at all, and it is what gives rise to both the regulatory exposure and the oracle risk described later.
Three more differences round out the picture. Spline liquidity lets a market maker express a shaped curve in far fewer transactions than posting discrete orders at every level would take. The flat schedule is not merely low but singular — one rate for everyone, rather than a ladder. And Flight builder codes are permissionless, which turns any third-party frontend into a distribution channel without a business agreement, and is why the cost of a trade depends on where you place it from.
Two reasons to read those numbers down
Activity measured inside a paid window is inflated by an unknown amount, and none of it should be extrapolated past 2026-08-23. For a sense of the venue outside the window, cumulative unincentivized perpetual volume was reported to have crossed USD 1 billion around 2026-07-28.
The second qualifier concerns a number this article deliberately does not use. DefiLlama shows USD 908,384 of total value locked for Phoenix, but that is the parent-level figure and it tracks spot order book liquidity; DefiLlama publishes no such series for the perpetuals venue at all. It is not perpetuals collateral and it is not a measure of the perpetuals venue’s size. If you see it quoted as either, the quote is wrong. Open interest is the number that answers that question.
◆ ◇ ◆
Phoenix excludes three named countries and reserves the right to add more
Two tiers of exclusion, and a clause that widens both
- Named jurisdictions
- United States, Canada, United Kingdom. Restricted Person status attaches to being located in, incorporated or organized in, established in, or a resident or citizen of any of them.
- Sanctioned territories
- Cuba, Iran, North Korea, Syria, Russia and Belarus, together with the Crimea region and the non-government-controlled areas of the Donetsk, Luhansk, Kherson and Zaporizhzhia regions of Ukraine. Ukraine is a partial exclusion of listed regions, not a country-wide one.
- The residual clause
- A further limb reaches any jurisdiction where offering, providing, accessing or using perpetual futures, derivatives, or margin or leveraged trading is prohibited or restricted, or where offering the service would subject the operator to a licensing, registration, authorization or approval requirement.
That residual clause is what makes this section worth reading rather than skimming. The countries written into the Terms are a floor, not a complete answer: a jurisdiction can be captured by the residual clause without ever being named in the document. So “my country is not on the list” is a weaker piece of information than it appears, and it is the hinge into the country-by-country section below.
One housekeeping note, in case you check the source yourself. The getting-started documentation still carries a shorter sentence naming only the United States and sanctioned jurisdictions, which leaves out both Canada and the United Kingdom. The Terms are the operative and more recent document, and that documentation line is stale — it should not be read as a current statement of where the venue is available.
A representation at every visit, plus an invite gate
Enforcement is contractual first. Each time you access or use the services, you are representing that you are not a Restricted Person, and separately that you are at least 18. Nothing in the official documentation describes wallet screening or any attestation mechanism behind that representation — the representation is the mechanism.
Enforcement is technical second. The exchange status endpoint reported gated=true on 2026-08-06, so venue access is invite-gated at the application layer independently of any country question. It is the same gate the referral link passes through at sign-up.
One structural point is worth stating precisely. The geographic restrictions in the Terms are framed as applying to the operator’s own interface and app. But Restricted Person status attaches to the person, not to the access path, which means the restriction is not a property of which door you walk through. This article describes no route in either direction and says nothing about how any restriction could be affected by anything a reader does.
Where the frontend ends and the program begins
The split between the two layers is real. Solstice Technologies S. de R.L. (Panama) operates the phoenix.trade frontend and the related services, and it is that operator’s Terms that carry both the restricted-region regime and the invite gating. Matching and settlement, meanwhile, run as a program on Solana.
Most coverage stops there and concludes that only the frontend is permissioned. That conclusion does not hold for this venue. The program layer is itself permissioned: it is upgradeable by a single key, and it runs under a seven-role authority set covering risk, market listing, oracle, auto-deleveraging, cancel and backstop functions. The protocol layer is therefore not independent of the operator in the way a frontend-only framing would imply. This is a fact about where control sits, and nothing more.
No regulatory action anywhere, on an eight-month record
No regulatory action, warning, enforcement proceeding or license grant involving Phoenix, Phoenix Perpetuals, Solstice Technologies or Ellipsis Labs was located as of 2026-08-06, in any jurisdiction. The venue holds no licenses anywhere either.
The window that finding covers belongs in the same breath as the finding itself, because otherwise it misleads. The perpetuals venue has been public only since 2025-12-11 and remains in beta, so a clean record here reflects roughly eight months of exposure rather than a long history of compliance. That is the difference between an honest negative and a flattering one.
The posture is preemptive rather than reactive: an offshore operating entity, no licenses sought, and exclusion of the three jurisdictions where retail perpetual futures face the most direct prohibition, plus the sanctioned territories.
What is worth watching is product-driven rather than event-driven. Since June 2026 the venue has listed perpetuals referencing listed equities — a regulated derivative product in most major markets — and the equity catalog grew from three names in mid-June to 23 by early August 2026. The official documentation states these settle on chain and confer no share ownership. No securities-law action against Phoenix or Ellipsis Labs was located. It is a standing exposure, not something that has happened.
◆ ◇ ◆
The US and the UK are closed; Singapore, Australia and India are not
Two of the five markets covered here are closed by Phoenix’s own contract. The other three are open on the venue’s side while sitting entirely outside the reach of their own financial regulator. Those are different answers with different consequences, so find your own country below rather than assuming one answer covers all five.
The United States: barred by Phoenix’s own Terms of Use
The operative fact is contractual: the United States is a named Restricted Person jurisdiction in the Phoenix Terms of Use. That is the first thing a US reader needs, and it settles the question on its own.
The exclusion is venue-wide rather than product-by-product. US persons are barred from the services as a whole, so every listed market — crypto, equity and commodity perpetuals alike — is equally unavailable. There is no US-specific partial arrangement, no reduced leverage cap and no permitted subset of markets.
There is a technical layer as well, and its limits matter. The site is served with server-side geographic gating, and chainhelm confirmed from its own research environment on 2026-08-06 that the machinery exists, in the form of a Vercel edge cookie named phoenix-geo-blocked. What chainhelm did not observe is the blocked screen itself, as a US visitor would see it: the research connection resolves to Tokyo, so no US-origin test was performed. The Terms are what closes this market. The gating machinery corroborates that; it is not the finding.
Where the duty sits is the part most coverage blurs. US registration obligations under the Commodity Exchange Act attach to the platform or the operator, not to the individual retail trader, and no US primary source was found imposing a penalty on a US resident merely for trading on an unregistered offshore perpetuals venue. Separately, and independently of public law, the Terms place a contractual bar on US persons. Both layers are real and they are not the same thing; neither one reduces to “legal” or “illegal”.
The reason a venue like this takes that posture is on the record. In September 2023 the Commodity Futures Trading Commission (CFTC) settled charges against three DeFi protocol operators for offering leveraged and margined retail commodity transactions in digital assets without registration, with civil penalties of USD 250,000, USD 200,000 and USD 100,000. That is the closest analogue to this product category and the principal reason a non-US-registered perpetuals venue excludes US persons. That action does not name Phoenix.
There is a second, stricter dimension specific to the equity markets. Perpetuals referencing US-listed single stocks engage securities law as well as the commodities analysis: Exchange Act Section 6(l) makes it unlawful to effect a security-based swap with a person who is not an eligible contract participant unless it is effected on a registered national securities exchange, and Securities Act Section 5(e) prohibits such offers and sales absent an effective registration statement. No US authority has applied either framework to Phoenix by name. This is the generally applicable backdrop to the exclusion, not a finding about the venue.
The United Kingdom: closed by a terms revision in July 2026
The United Kingdom is a named Restricted Person jurisdiction in the Phoenix Terms of Use, on its own footing alongside the United States and Canada. It is not reached through the sanctions tier — the UK appears there only as a sanctions authority whose lists Phoenix respects. Those are two different things and they should not be run together.
The date is what matters most here: the exclusion took effect with the Terms revision dated 2026-07-27. That is recent enough that a great deal of existing material is now wrong.
Two days is how narrow the change window is. The practical consequence for a UK reader is blunt: any guide written from material older than August 2026 describes a UK position that no longer holds, however confident it sounds.
It happened through the Terms document alone. No press release, blog post, documentation update or social announcement accompanying the change was located, and no reason was given for it. This is a silent terms change — Phoenix issued no UK guidance, and this article asserts no cause for the revision.
The exclusion covers the whole service. Phoenix offers perpetual futures and nothing else, and the Terms bar UK residents and citizens from the services in their entirety, so there is no permitted UK subset: no reduced leverage, no view-only access.
On the public-law side, the Financial Conduct Authority (FCA) banned the sale, marketing and distribution of crypto derivatives to retail consumers in policy statement PS20/10, effective 2021-01-06. That prohibition binds firms acting in, or from, the UK — not consumers — and no UK provision was identified that addresses the consumer-side legality of using an overseas venue. What actually closes access here is Phoenix’s own exclusion, not the FCA rule. The FCA also confirmed during 2026 that the derivatives ban stays in place even as the ban on crypto exchange-traded notes was lifted.
One item points forward. The FCA published final rules for the new cryptoasset regime under the Financial Services and Markets Act on 2026-06-30, with the regime expected to come into force on 2027-10-25. The current closure is not necessarily permanent, but no authorization route opens before then.
Singapore: not excluded by Phoenix, not covered by MAS
Singapore is not a named Restricted Person jurisdiction in the Phoenix Terms of Use. A full-text search of the Terms dated 2026-07-27 returns zero occurrences of the word “Singapore”.
That verification has a limit. The page was never loaded from a Singapore address, so the operator’s actual server-side block list could not be checked; availability here is a documentary reading, not an observed one. And as the residual clause above makes clear, not being named is not the same as being confirmed as permitted, because a jurisdiction can be captured without being written into the list.
On the regulatory side, the Monetary Authority of Singapore (MAS) states directly that it does not license or regulate decentralized finance applications. The Singapore regime — the Payment Services Act 2019, the Securities and Futures Act 2001, the Financial Advisers Act 2001 and the Part 9 regime for digital token service providers under the Financial Services and Markets Act 2022 — is aimed at service providers rather than at users, and no Singapore law or MAS rule prohibiting a resident from accessing an unlicensed offshore venue was located. Phoenix holds no MAS license; that was checked against the MAS Financial Institutions Directory on 2026-08-06.
What that costs is best stated in MAS’s own words. MAS says it will not be able to help someone who loses money dealing with digital tokens that are not MAS-regulated products, and urges consumers not to deal with unregulated entities, including those based overseas. The absence of protection is the operative consequence here, and it is not a feature.
There is a live precedent worth knowing. MAS added a comparable non-custodial perpetuals venue to its Investor Alert List on 2026-06-26. Phoenix is not on that list, as verified on 2026-08-06. An Investor Alert List entry is a public caution that an entity is not licensed or regulated by MAS — not a ban, not an enforcement action, and not a finding of wrongdoing. The point is simply that MAS does act on this category, so Phoenix’s absence from the list is a point-in-time fact rather than a durable safe harbor.
Australia: open to sign up, outside ASIC’s licensing perimeter
Australia is not a named Restricted Person jurisdiction in the Phoenix Terms of Use. That holds for the current Terms and for every archived version examined: the string “Australia” appears zero times in all of them. As with Singapore, this is a documentary reading and was not verified by loading the page from an Australian address.
Phoenix holds no Australian financial services license, no Australian market license and no AUSTRAC digital currency exchange registration. That rests on the operator’s own disclosure that the protocol and the services are not regulated by any financial regulator in any jurisdiction; the AUSTRAC public register could not be queried from chainhelm’s research environment, so this is not a register check.
The Australian Securities and Investments Commission (ASIC) sets out where the duty sits in information sheet INFO 225, which lists perpetual futures referencing digital assets among the products that are likely to be derivatives and states that an issuer needs an Australian financial services license with appropriate authorizations. ASIC addresses offshore and decentralized structures head-on: using them does not mean Australian obligations stop applying. But every one of those obligations is addressed to the platform, not to the individual — and ASIC expressly declines to resolve decentralized-finance licensing in the abstract, so Phoenix’s specific position is not determined by that guidance.
For the individual the finding is narrower. No Australian law or ASIC statement was found making it an offense for a resident to access or trade on an unlicensed offshore derivatives venue, and ASIC frames the consequence for the individual as loss of protections — no internal dispute resolution, no client money protections — rather than as personal illegality. That is an absence of prohibition, not an affirmative permission, and the difference matters.
The most concrete Australian fact is a gap. ASIC limits leverage on certain crypto asset derivative products to 2:1 for retail investors, through a product intervention order that binds issuers and distributors dealing with retail clients. Phoenix’s live maximum is 40x on BTC, 25x on ETH, SOL, GOLD and SILVER, and 20x on the equity-referenced markets. Whether the 2:1 cap legally reaches Phoenix is not established by any primary source and should be treated as unverified. What is established is that an Australian retail user obtains leverage far above the level ASIC considers appropriate, and obtains it without any of the protections that would accompany it onshore. The missing protection is the point here — not the leverage.
India: not named as excluded, and not regulated either
India is not a named Restricted Person jurisdiction in the Phoenix Terms of Use — not in the jurisdictional tier and not in the sanctions tier.
One thing is genuinely unresolved. The frontend’s country block runs on the server and keys off your IP address, and the list of blocked countries is not in the code the browser downloads, so it cannot be read from outside India. Probing from chainhelm’s Tokyo connection returned an unblocked result for Japan, and setting the country through a request header was attempted and is not honored — a check run with countries the Terms already restrict. India’s frontend status is therefore unclear. What the documents say is that the Terms do not exclude India; a definitive answer needs a request from an Indian address, which was not available.
Where the duty sits is clearer. The Finance Ministry told Parliament on 2026-02-05 that virtual digital assets are currently not regulated in India — neither banned nor legal tender — and that no ban proposal was under consideration. There is no Indian statute prohibiting a resident from holding or trading virtual digital assets, and the Income-tax Act taxes transfers of them, which presupposes that such transfers are lawful.
The provider side is why “not prohibited” is not the end of the story. Guidelines from the Financial Intelligence Unit - India (FIU-IND), updated 2026-01-08, state that the obligations of virtual digital asset service providers are activity-based and apply irrespective of physical presence in India: any entity engaged in the notified activities must register as a Reporting Entity, and failing to register is itself a violation of the Prevention of Money Laundering Act. Phoenix is not registered and does not appear on any published FIU-IND list.
The enforcement record shows what that means in practice. FIU-IND issued show cause notices to nine offshore service providers on 2023-12-28 and to 25 more on 2025-10-01, and sought takedowns of their URLs and apps under section 79(3)(b) of the Information Technology Act. The 2025 list includes leveraged-derivatives venues, so the perpetuals segment is squarely inside FIU-IND’s focus. Phoenix appears on neither list — absence of published action as of 2026-08-06, which is not the same as a clearance.
What an Indian reader carries, then, is the risk that access or the platform itself goes away, not a personal prohibition. And whether a protocol that never takes custody and performs no identity checks falls within the notified activity categories at all has not been publicly adjudicated in India, for Phoenix or for any comparable venue. It is unadjudicated, not settled either way.
The perpetuals program is unaudited, unpublished, and upgradeable by a single key
Code you cannot inspect
Phoenix Legacy
Phoenix Perpetuals
This is the single most important gap for anyone weighing the venue. The audit that exists is real; it simply covers a different program from the one your collateral would sit in.
The absence was checked in three places rather than assumed from one. The 116-page documentation index contains no security or audit page, the public Ellipsis-Labs GitHub organization contains no audit directory for the perpetuals program, and DefiLlama records the perpetuals entry with an audit count of zero and no audit links. The repository README that mentions the OtterSec audit gives no date for it.
One key, and no delay
The perpetuals program is deployed under Solana’s BPF upgradeable loader and remains upgradeable. Its present upgrade authority is the same address as the protocol’s root authority.
The nature of that address is the part that matters. It is owned by the System Program and holds zero bytes of account data — in plain terms, an ordinary signer address rather than a program-owned multisig account. No on-chain multisig program mediates upgrades. Whether some off-chain key-management arrangement sits behind that address is not disclosed anywhere.
Nor is there a delay. The official documentation describes no timelock, upgrade delay or governance vote, and none is exposed by the exchange configuration as of 2026-08-06. An upgrade can land without a window in which anyone outside could see it coming.
One detail cuts the other way, though it does not undo the point above. Duties are separated across seven authority roles — root, risk, market, oracle, auto-deleveraging, cancel and backstop — and every pending-authority slot held the system default address on 2026-08-06, meaning no authority transfer was queued. That was verified directly against Solana mainnet-beta.
Who absorbs the loss
No insurance fund is described anywhere in the official documentation, and none is exposed by the exchange configuration endpoint. The honest answer is that this is unknown, not that there is none: absence of documentation is not proof that no backstop capital exists. What is documented is a different mechanism entirely.
- Cancel
- Risk-increasing resting limit orders are canceled first, at the cancel-order threshold of 75% of initial margin.
- Market liquidation
- The position is liquidated against order book liquidity. This may be partial, but it must either improve the trader’s health or fully close the position, and it is capped by a per-market maximum liquidation size.
- Backstop transfer
- When book liquidity is not sufficient, the position transfers to backstop accounts at the backstop requirement of 20% of initial margin.
- Auto-deleveraging
- As a last resort, the losing position is matched against the highest-priority profitable trader on the opposite side.
Around that ladder sit the other thresholds, uniform across all 62 markets on 2026-08-06: maintenance margin at 50% of initial margin and a high-risk threshold at 10%, with account health escalating through named tiers — Safe, AtRisk, Cancellable, Liquidatable, BackstopLiquidatable and HighRisk. No explicit liquidation penalty or fee is documented.
The consequence for you sits on the last rung. Residual losses are socialized onto profitable counterparties rather than absorbed by a disclosed fund, and a trader hit by auto-deleveraging may realize less profit than expected. That can happen to a reader who did nothing wrong and held a correct position — it is a property of the venue, not of the trade.
Prices from sources the docs do not name
Oracle providers are not individually named. The documentation says only that Phoenix uses a number of independent data providers for external real-world asset prices, and no provider is identified on any documentation page as of 2026-08-06. That limits how specifically this risk can be described, and inventing a name would be worse than saying so.
The construction itself is disclosed. Mark price is the median of three components: an adjusted oracle price, a book price taken as the median of best bid, best ask and last trade on Phoenix, and an exchange price computed as a weighted median of perpetual prices on major external venues. The oracle authority role is a permissioned key.
The fallback matters more here than it would at most venues. Twenty-seven of the 62 markets are equity or commodity perpetuals whose reference markets close on a schedule. When external pricing is unavailable, the venue switches to Impact Pricing, which derives the price from Phoenix’s own order book — so for those hours, the price of your contract comes from inside the venue rather than from an outside reference.
Getting money out, and what a trade really costs
Withdrawals are rate-limited rather than priced. No protocol-level withdrawal fee is documented, but the live withdrawal budget is capped at 2,000,000 Phoenix USDC and replenishes at 450 USDC per Solana slot, and the exchange status endpoint reported withdrawals as available on 2026-08-06. Read that as a throughput constraint rather than a charge: it exists, it is invisible in calm conditions, and it is the kind of limit that binds precisely when everyone wants out at once.
The cost of a trade can also exceed the published schedule by an amount nobody has capped. Flight builder fees stack additively on the base taker fee, and the documentation publishes no cap or permitted range for them. The schedule quoted earlier describes direct access at phoenix.trade; a trade placed through a third-party terminal carries whatever that terminal has set on top.
An empty incident log, read correctly
No exploit, oracle failure, outage or depeg affecting Phoenix was found in searches on 2026-08-06. The incident record is empty. The history behind it is also short: the perpetuals venue has only been live since 2025-12-11, so an empty list here reflects a brief operating history rather than a long clean one, and it should be weighed as such.
The app is a pre-release beta by the operator’s own description, provided for testing and evaluation, and access remains invite-gated.
One last risk sits behind everything above. The operator reserves the discretion to restrict, block, limit or disable access from any jurisdiction, in whole or in part, at any time. That is not hypothetical — it is exactly what happened to the United Kingdom on 2026-07-27, through a terms revision with no announcement attached. A reader in any of the open markets above holds their position on those terms.
◆ ◇ ◆
The code is live, and the open questions are audit coverage, gating and scale
The code TFJA22W2 is live, verified by chainhelm on 2026-08-08. It attaches automatically when a fresh wallet connects through the referral link, it cannot be added to that wallet afterwards, and what it changes is an ongoing 10% cut to trading fees charged on a schedule that is the same for every trader.
Where you can use it depends on where you are. The United States and the United Kingdom are closed by the venue’s own Terms of Use — the UK only since late July 2026, which is recent enough that older guides are wrong about it. Singapore, Australia and India are open on Phoenix’s side, and in all three the venue sits entirely outside your own regulator’s perimeter, with the loss of protection that implies.
Three findings would change the decision, and all three follow from what is above. The perpetuals program has no published audit and no published source, so the code holding your collateral cannot be independently reviewed by anyone. Access is still invite-gated and the app is a pre-release beta, so signing up and being admitted to trade are not the same event. And the venue is small in absolute terms, with today’s readings sitting inside an incentive window that ends 2026-08-23 — which makes them a snapshot rather than a stable picture.
None of that decides anything for you. A 10% cut on a schedule that is already flat is a real saving on a venue that publishes its mechanics in unusual detail, and it sits alongside an unaudited program under a single upgrade key. Whether that trade is worth making is a judgment about your own tolerance for risk, not a fact this article can settle — and deciding against it is a perfectly good outcome.
