How it works

Everything on this site runs on XPHX. You can stake it in a pool, hold a liquidity pair of it, supply it to a lending market, lock it for a VIP tier, or deposit it into the sXPHX vault. Each is a different contract with a different action, and the same XPHX can only be in one of them at a time.

Every figure the site shows for any of them is read from the contract on the request that shows it. There is no database of balances, no cached rate and no estimate standing in for a read that failed. When a read fails the figure is absent and says so.

Non-custodial throughout: your tokens sit in the contract you chose until you take them out, and no contract here has an owner function that can move them.

Deposit XPHX, or a PancakeSwap pair token that contains it, into a pool and it pays a second token per second for as long as it is in there. There are 12 pools and each names what it takes and what it pays.

A pool is funded before it opens. The whole reward budget is transferred into the contract first, and the rate is the budget divided by the duration; it does not mint as it goes. The budget is held there but not locked: the owner can recover the reward token, and cannot recover the staking token. There is no minimum and no lock. Harvest collects what you have earned so far without touching your deposit. Withdraw takes the deposit out and stops the accrual. Exit does both in one transaction.

The contracts are Synthetix StakingRewards with the changes the Solidity 0.8 migration forced and nothing else; the reward maths is pinned byte for byte. Rates, budgets and countdowns are on the staking page, readable without a wallet.

A campaign pays you for holding a PancakeSwap pair token in your own wallet. There is no deposit, no approval and nothing to withdraw. The campaign records your balance of the pair when your wallet is checkpointed and pays its budget out per second to every checkpointed wallet, in proportion to the balances recorded. It is not sXPHX, which takes a deposit and pays through an exchange rate.

Like a pool, a campaign is a fixed sum funded before it opened. It stops at an end date fixed when it was created, and budget that nobody earned goes back to the funder afterwards. Unlike a pool, nothing leaves your wallet. Adding liquidity on PancakeSwap is the only way in, and selling the pair token is the only way out.

Accrual is lazy: the contract writes nothing until somebody touches it, so the figure it reports as settled can lag the figure it would pay. The site reads the second, and a claim pays exactly that. A wallet the campaign has never seen earns nothing until it is checkpointed; the page offers to do that in one signature, or a keeper does it on its own schedule. Each campaign, its budget draining and your share, is on the hold to earn page.

Supply an asset to one of the 24 markets and it earns interest from whoever borrows it. You receive a receipt token, a pToken, that represents your share of the market and grows against the asset as interest accrues. Withdrawing burns the receipt for the asset plus what it earned.

To borrow, switch a supplied asset on as collateral first. That is a separate step, on the market row, and it is the one that surprises people.

Supplying is not enabling collateral. An account that supplied but never switched it on has a balance, zero collateral, and every borrow fails. Borrowing an asset switches that same asset on automatically; borrowing a different one does not.

Each market prices itself from one number, utilisation: the share of the supplied pool currently borrowed, along a curve the admin chooses for that market and can replace. Below a kink the rate rises gently; above it a steeper multiplier takes over, which pushes utilisation back down. Most markets have two kinks, and the formula below shows the shape with one. The supply rate is the borrow rate scaled by utilisation and by what the protocol keeps as reserve. Every market’s own curve, kinks and reserve factor are on its page, read from the contract.

borrow = base + min(u, kink) × multiplier + max(0, u − kink) × jump
supply = borrow × u × (1 − reserve factor)

One number describes a borrowing position: Risk, your debt against the point where liquidation begins. Higher is worse, and above 100% a third party may repay part of your debt and take the corresponding collateral plus a bonus. Your VIP rung moves that point a little further out. New borrowing and collateral withdrawals stop at your rung’s borrowing limit, which sits close to 100% at the higher rungs and well below it with no rung, and nothing is liquidated there; only a price fall or accruing interest carries a position the rest of the way. The interface suggests a Safe borrow that stops at 85% Risk. You can rescue the position at any point before 100% by repaying or supplying more.

Some markets carry a supply reward: a second token, paid from a separate contract with a fixed budget, on top of the interest, for holding the pToken. It appears on the market row and is claimed from the top of the markets page.

Nothing has to be locked to supply or borrow. Locking XPHX buys better terms: a higher maximum loan-to-value in every market at once, and more room before the liquidation trigger. There are 5 rungs above no tier, from Bronze to Gold, and the amount each requires is read from the risk engine on the VIP page.

The lock is a separate contract from the lending markets. Locked XPHX still receives the transfer-tax reflection, and the locker can pay that out through its own claim; a campaign also pays XPHX by amount locked, through a different claim. The VIP page keeps the two apart because each is its own contract.

Unlocking can drop your tier, which lowers your maximum loan-to-value everywhere at the same moment. If your debt would then be above your borrowing limit, the lending risk engine refuses the unlock, and the interface says so before you sign. With no borrowing, an unlock always succeeds.

Deposit XPHX into the vault and receive sXPHX, a receipt that redeems for more XPHX over time. It does not rebase: your sXPHX count never changes, and each one redeems for more. The vault does not stake or lend the XPHX it holds, and nothing is minted to pay it. Its balance rises because one leg of the XPHX transfer tax is routed to it, it receives reflections, anyone can donate XPHX to it, and the revenue router sends it a share of the XPHX it pays out. It is not hold to earn, which takes no deposit.

The rate is a share of a flow, not a yield on your deposit. The amount arriving depends on how much XPHX moves, not on how much is in the vault, and it is split across every sXPHX in existence. The rate is high while the vault is small and falls as deposits grow. Early depositors earn more, and no annualised figure on the vault page will survive the vault getting bigger.

Redeeming burns your sXPHX and returns XPHX at the current rate, on demand, with no queue and no unbonding delay. Every mechanic is answered on its docs page. The receipt is also listed as a lending market, so it can be supplied and borrowed against while it keeps compounding. Rate, holdings and history are on the vault page.

XPHX charges a fee on transfers between parties that are not exempt, in two separate legs: one percent reflected to every holder in proportion to what they hold, and one percent routed to the sXPHX vault. Both are automatic and neither is claimable. Most contracts on this site are exempt, so the amount you enter is usually the amount that arrives; before you sign, the interface asks the token whether the destination is exempt and warns only when the answer is no.

Supplying XPHX to the lending market stops its reflections, because that market’s pToken is excluded from rewards. The sXPHX vault and the VIP lock are not excluded, which is a real difference between the places XPHX can sit.

Claim fees reach one splitter, which passes their buyback share to one router. Lending reserves are different: they stay in each market until the admin withdraws them, and nothing routes them to the router. The router keeps a share of each non-XPHX fee to buy XPHX on PancakeSwap and sends the rest to the treasury, and splits the XPHX it holds between the protocol’s staking contract and the sXPHX vault, where it raises the rate. The router names each of those addresses when asked, and the splitter points back at the router. The picture is on the home page and the addresses are on the transparency page.

TomanX, IRTX, is a privately issued instrument that tracks the Iranian toman rather than the dollar. PhoenixCo publishes its rate, and nothing tradable moves that rate back. It supplies and borrows here like any other market, and its interest is paid in IRTX.

A positive rate on IRTX can still be a substantial loss in dollar terms, and its percentage cannot be compared with the other markets’, which are dollar returns. That is why its row names the unit beside the rate.

If the published rate is not refreshed in time, borrowing that relies on it halts and IRTX counts for less borrowing power; only after a much longer lapse does the oracle stop valuing it. How the rate is published and bounded is on the TomanX docs page.

A number on this site comes from a contract on the request that shows it, from a committed configuration file, or from arithmetic over those two. It never comes from an inference about what a contract probably means. Where a contract has two views that can disagree, the site reads the one a transaction would actually pay.

Counts are never typed into copy: the number of markets, pools, campaigns and tiers on this page are the same values the pages that list them are built from. A build check fails if one is written by hand.

There is no utilisation history. Past utilisation lives in event logs, and the public RPC endpoints this site can reach refuse eth_getLogs over any useful range. The rate curve is the live formula and is exact; a history chart would have to be invented, so there is not one.

Some figures are withheld rather than estimated. When a read fails, the number it would have produced is replaced by a dash and a note, not by a stale or approximated value.

Audit status. The staking contracts and the lending engine are forks of audited bases, with every change documented; our changes have been reviewed internally and not yet by a third party. The source of every lending market, staking pool and reward campaign is shown on BscScan: contracts built from the same code are verified at a single address, and BscScan matches the others to it as a similar match. The tier locker and the sXPHX vault are verified at their own addresses. The source of the XPHX token and of the sXPHX vault is also matched on Sourcify.