What is Swift?

Trading is one way in. Participation goes further.

Swift is a novel experiment in shared exchange economics, inspired by Papertrade. It brings traders and token stakers into the same ecosystem, with different ways to participate in the revenue the protocol generates.

The idea is simple: participation should extend beyond the people opening trades. Some users want leveraged market exposure. Others want to stake a token and share in the platform’s activity. Swift gives both a way in.

More revenue goes to participants

Swift allocates 55% of eligible protocol fees to participants, while the platform retains 45%. The participant allocation is divided between two staking pools:

Each user earns proportionally to their eligible stake within the relevant pool. The allocation shares protocol fees; it does not divert user deposits or give token stakers priority over unpaid winning claims.

Trade and earn swiftX

Eligible realised trading losses mint swiftX according to the protocol’s emission curve. Users can stake swiftX to participate in the larger fee pool and qualifying bankroll-surplus distributions. This creates ongoing participation after a losing trade; it does not refund the loss.

Stake SWIFT

SWIFT is the fixed-supply token on Ethereum mainnet. Staking gives users access to protocol revenue without requiring a leveraged position or a trading loss. Staking does not burn SWIFT. Tokens remain tradable after withdrawal under the staking rules; unstaked holdings do not earn the staking allocation.

Burn SWIFT to receive swiftX

Users can permanently convert some or all of their SWIFT into swiftX. The burn route issues 50% of the swiftX that an equivalent qualifying trading loss would mint, based on SWIFT’s reference value at conversion. The discount applies to the quantity minted, not to the rewards each token earns. Once staked, burn-earned and loss-earned swiftX have identical rights per unit.

Users can combine these routes: keep part of their SWIFT staked and convert another part into swiftX. Burned SWIFT permanently leaves the supply and stops earning SWIFT rewards. Conversion is one-way; neither token appreciation nor higher individual earnings is guaranteed.

Trade for market exposure. Stake for protocol participation. Convert by choice.

Frequently asked questions

How trading, staking and conversion fit together.

Am I trading real Hyperliquid perpetual positions?

No. Swift positions are synthetic contracts against the protocol bankroll. Hyperliquid supplies the reference price and infrastructure, not automatic backing for Swift payouts.

What does trading cost?

There is no notional trading fee, funding payment or execution spread. Winning closes apply a deadband, asymmetric profit reduction and 2% win fee. Applicable losing-close fees come from the bankroll’s gain, not an extra charge to the trader.

Who receives protocol fees?

Eligible fees are divided 44% to swiftX stakers, 11% to SWIFT stakers and 45% to the platform. Each staker earns proportionally within their pool. Qualifying LP surplus is a separate swiftX distribution.

Can I participate without trading?

Yes. Acquire and stake SWIFT to enter its fee pool. Unstaked holdings do not earn this allocation. Staking does not burn SWIFT; withdrawal rules apply before selling staked tokens. Returns and market liquidity are not guaranteed.

What do trading losses mint?

Eligible realised losses and liquidations mint swiftX, never SWIFT. Winning closes produce net trading profit, paid or queued. Unrealised losses do not mint tokens. swiftX participates in future distributions; it does not refund the trading loss.

What happens when I burn SWIFT?

The burn permanently removes SWIFT and mints half the current loss-curve quote for its reference value at conversion. There is no reverse conversion, new bankroll cash or debt cancellation.

Does burn-earned swiftX receive half the rewards?

No. The 50% factor reduces mint quantity only. Once staked, each swiftX unit earns the same proportional share regardless of whether it came from a loss or a burn.

Can I keep both types of stake?

Yes. Convert part of your SWIFT and retain the rest. The burned portion stops earning SWIFT rewards. Remaining staked SWIFT and newly staked swiftX can earn from their respective pools.

Can I edit positions or withdraw queued claims?

Positions have fixed margin and leverage and close in full. There are no margin top-ups or partial closes. Queued claims become withdrawable only after payment; using them for another trade puts the claims at risk.

Is every action permissionless?

No. Ordinary trading and specified account actions use configured relayers. Wallet-authorised withdrawals and certain maintenance calls have public paths. Ethereum staking and conversion have separate interfaces. Administrative and upgrade powers are described in Section 19.

Quick start

Connect, fund a trading balance and understand the first position.

Before trading

Use a supported EVM wallet and a funding route enabled in the Swift interface. The deposit process requires at least 10 USDC to arrive after route fees and includes a one-time 1 USDC first-deposit activation charge. The interface must show the required gross amount and any native transaction or bridge fees before confirmation.

Connect and authorise

Connect the wallet and sign a session-key authorisation. The session key permits trading on the account without a new wallet prompt for every open or close. It does not authorise withdrawals or swiftX staking and reward claims.

Deposit

Select an enabled origin network and use the deposit address generated for that wallet. Wait until the transfer has been swept and credited to the trading balance. Sending funds and receiving an internal trading credit are separate states; do not treat an uncredited deposit as spendable.

Open a position

Choose BTC or ETH, select long or short, enter the margin and leverage, and review notional exposure and the displayed bust price. Use available USDC for a cash-funded position. Using a queued balance instead creates a claim-funded position, with different collateral settlement on close.

Monitor and close

The ordinary trade submission uses the relayer, which pays the trading transaction’s gas. The execution price is read when the transaction executes, not guaranteed at the instant of clicking. A voluntary close exits the full position. Check whether the result is available cash, a queued claim, or swiftX minted on a realised loss.

Participate without opening a trade

SWIFT is the fixed-supply token on Ethereum mainnet. Acquire it through verified market routes and stake it in the verified SWIFT staking contract to join the 11% protocol-fee pool. Unstaked holdings do not earn that staking allocation. No trading loss is required; token-price risk, staking access and applicable token-market charges remain relevant.

A separate, optional conversion burns SWIFT for swiftX at half the current loss-curve mint quote for the burned amount’s reference value. Review the irreversible burn, current value, expected output and pending cross-chain settlement conditions before signing. Conversion output only participates in the larger pool once staked.

Use only verified Swift application links, token contracts and deposit routes. Launch addresses and enabled networks will be published in the deployment registry; they are not supplied by this document.

Trades and pricing

Fixed-margin positions settled against a protocol counterparty.

Every position records a market, direction, entry price, committed margin and leverage. Notional exposure is margin multiplied by leverage. Each position is isolated from other positions; losses on one do not automatically draw on another position’s margin.

notional = margin × leverage
executionPrice = (bestBid + bestAsk) / 2

At opening, the Exchange reads the reference BBO midpoint and records the position. At closing, it reads the applicable midpoint again and calculates the directional change. The bankroll pays successful positions and receives realised losses, subject to the payout queue and fee rules.

Position controls

The position cannot be resized or re-margined after opening. A voluntary close is full-size only. Opening another position adds exposure; closing and reopening smaller reduces it. There is no funding timer and no cross-margin toggle.

Markets and limits

The initial market specification covers BTC and ETH, up to 1,000× leverage and up to $10 million notional for one position. Separate per-instrument, per-side open-interest caps and trade minimums also apply. New markets require configuration by the owner and a supported Hyperliquid reference market.

What “no slippage” means

The protocol does not walk an order book to fill its own position, so the execution formula does not worsen with that position’s size. The price can still move between signing and inclusion. Relayer availability, execution ordering and block timing remain relevant.

Settlement currency

User accounting and payable trading outcomes are denominated in USDC. SWIFT and swiftX are participation tokens, not substitutes for cash collateral or automatic collateral assets in the trading engine.

Wins and losses

Profit adjustments, loss accounting and which balance changes.

Winning closes

A positive price move first passes through the 0.2-basis-point deadband. The remaining gain is reduced by the asymmetric impact curve. A 2% win fee is then deducted from the adjusted gain. The resulting net profit is paid from available bankroll cash or recorded in the payout queue.

For a cash-funded winning position, the original cash margin returns to the available balance separately. Only the unfunded profit is queued. For a claim-funded position, the bankroll owes the whole surviving claim, which may include the original claim collateral plus net profit.

Voluntary losing closes

A cash-funded voluntary loss reduces the committed margin by the raw trading loss. No additional charge is taken from the trader above that loss. When the applicable funding conditions permit the 2% loss-side fee, it is carved out of the bankroll’s gain. If the payout queue is active, that fee is waived and the cash loss is earmarked for queue repayment.

A claim-funded loss cancels part of a previous unpaid claim. It introduces no new cash. Any surviving claim is paid or queued under the same priority rules; a loss-side fee is payable only when the queue is empty and free cash can fund both the surviving claim and the fee.

Why results are asymmetric

Positive outcomes are scaled down before the win fee. Ordinary losing outcomes are not scaled upward: they pay the loss itself. Hard liquidation is a separate full-margin forfeiture rule, not a voluntary close at the bust price.

Loss rewards

Eligible realised losses and liquidations mint swiftX. The mint basis depends on whether the position was voluntarily closed or liquidated and whether a loss-side fee applied. Winning closes do not mint loss rewards. swiftX does not reimburse the loss in USDC.

Liquidations

A hard-bust trigger is not the same as zero voluntary-close equity.

The displayed bust price is a trigger for a separate hard-liquidation path. Once the position is eligible and liquidation executes, the entire isolated margin is forfeited. A voluntary close immediately before that trigger can still have returned remaining equity.

The fixed buffer

The design places the bust trigger approximately 5 basis points closer to entry than the reference zero-equity price. This is a price-distance buffer, so its importance as a fraction of margin increases with leverage. At 1,000×, the approximate trigger in the documented example is an adverse move of 0.052%, not a full 0.1% move.

Illustration: $100 of margin at 1,000× represents $100,000 notional. A 0.052% adverse move corresponds to about $52 of ordinary trading loss, yet the hard-bust rule can forfeit the full $100. The example illustrates the distinction; the contract’s precise trigger and rounding govern execution.

Where the forfeited value goes

For a cash-funded position, forfeited margin becomes bankroll cash when the queue is empty, net of any applicable liquidation fee. With an active queue, the fee is waived and the proceeds are earmarked in sideBucket for older payout claims. A claim-funded liquidation cancels the whole pledged claim, charges no liquidation fee and creates no new USDC.

swiftX on liquidation

The loss-emission basis is the full forfeited margin or destroyed claim. When a cash liquidation fee applies, tracked LP advances by the retained amount even though token minting uses the full margin. That difference must remain explicit.

Keeper execution

An operator-run keeper monitors eligible positions and submits liquidations. The design also exposes liquidation maintenance publicly. A keeper cannot eliminate price gaps, transaction-ordering effects or infrastructure delays. Normal voluntary closes still use the relayer path.

The bankroll and payout queue

What backs trades and what happens when a close cannot be paid immediately.

The bankroll is the protocol counterparty’s USDC backing, not the sum of all user deposits. It begins without seed LP capital and has no ordinary direct LP deposit route. The bankroll develops from settled trading outcomes rather than an upfront external LP raise.

Available balance versus queued balance

Available balance is funded value credited to the user and not committed to an open position. Queued balance is an unpaid obligation recorded by the protocol. The interface must not label an unpaid queue claim as immediately withdrawable cash.

A cash-funded position returns its remaining collateral independently of unpaid profit. On a profitable close, the profit that cannot be funded enters the queue. Once any claim is queued, later winning closes cannot skip ahead of it.

First-in, first-out repayment

Harvest pays from the front using available queue-backing cash. An entry may be paid partially when funds are insufficient. Subsequent cash losses can help finance future harvests. Continued trading does not by itself guarantee the speed or eventual completion of repayment.

Trading with queued claims

A user may consume queued balance as collateral for a new position, subject to the queue-processing and market limits. The consumed claim is not money the protocol has newly received. A loss destroys some of that claim; liquidation destroys all of the pledged claim. A surviving claim may be appended back to the queue when the position closes.

Participation comes after payout priority

Protocol fee recipients do not receive new trading-fee payouts ahead of an active winning-claim queue. The 45/44/11 recipient allocation applies only when the fee is eligible for distribution; it neither increases the trading charge nor changes the queue’s priority.

swiftX loss emissions

Eligible losses issue participation tokens through the curve.

swiftX is minted to a trader when an eligible loss is realised or a position is liquidated. An unrealised negative position does not mint a token. A profitable close does not mint swiftX. Converting SWIFT is the distinct second issuance route described in Section 25.

Eligible basis

For a voluntary loss, the basis is the realised loss after any applicable LP-side loss-fee carve. For a liquidation, the basis is the full forfeited margin. A claim-funded loss can qualify through cancellation of existing queue debt, even though no new cash enters the protocol.

Early and later issuance

The flat region issues 100 swiftX per $1 of eligible basis while tracked LP is below $2 million, including negative tracked LP. Above the threshold, the loss-emission rate declines according to the historical tail-progress curve. Distributing surplus does not erase the tail-progress counter.

What a reward represents

swiftX is a unit of participation in future designated distributions when staked. It is not an entitlement to withdraw the original loss, a guaranteed dollar value or a fixed yield. New swiftX issuance can reduce an existing holder’s proportion of the eligible total.

Two routes, one token

Loss-minted and burn-minted swiftX are the same participation token and have identical reward rights per staked unit. Eligible trading losses use the calculation in Section 16. A SWIFT burn instead mints 50% of the loss-curve quote for the burned amount’s reference value at conversion. This is half the mint quantity, not a reduction in rewards per unit.

Conversion is not a realised trading loss, bankroll funding or debt cancellation. It cannot advance tracked LP or historical trading progress as though a loss had settled. Neither issuance route mints SWIFT; that token has fixed initial supply and burns only reduce it.

swiftX starts at zero supply with no premine. Eligible trading losses and SWIFT burns are its two issuance routes. SWIFT’s fixed initial supply and launch allocations are disclosed separately.

Fees and revenue allocation

55% to participants. 45% to the platform. One fee budget. Two staking pools.

Swift directs 55% of eligible protocol fees to participants and 45% to the platform. Within the participant allocation, 80% goes to swiftX stakers and 20% to SWIFT stakers. These allocations sit downstream of the trading charges and settlement conditions described in this document.

F = eligible protocol-fee amount
Participant allocation = 0.55 × F
swiftX staking pool     = 0.80 × 0.55 × F = 0.44 × F
SWIFT staking pool      = 0.20 × 0.55 × F = 0.11 × F
Platform allocation    = 0.45 × F
Total allocations      = F

These are collective pools. A staker’s entitlement is proportional to their eligible stake within the relevant pool. A user does not personally receive 44% or 11% of protocol fees simply by staking one token.

What is—and is not—being divided

The allocation applies to the existing eligible protocol fee, not gross trading losses, user deposits, position notional or all treasury assets. The asymmetric profit reduction is also distinct from the 2% fee. Changing the fee recipients does not change the trading payout calculation or introduce a new charge to the trader.

In the winning example, the trader’s profit claim remains $98. In the cash-loss example, the bankroll retains $98. The same $2 is divided among different recipients; no 55% share of the trader’s $100 loss is paid out.

LP surplus remains a separate stream

Qualifying tracked-LP excess above the $5 million threshold is fully distributable to swiftX stakers, subject to the bankroll’s funding and settlement rules. The 45/44/11 fee allocation is not applied to that surplus. SWIFT stakers receive the 11% fee pool, not an additional share of LP surplus under this specification.

Payout priority

A win fee is deducted from adjusted profit even when a close is queued; that deduction does not authorise an immediate fee payout. Fee distributions retain the cash and queue conditions. Applicable loss and liquidation fees are waived while the queue is active. Neither token’s pool can bypass winning claims or use protected user balances.

Deposits and withdrawals

Funding routes, crediting and wallet-authorised exits.

Deposit routes

The funding specification covers USDC routes from Hyperliquid/HyperCore, HyperEVM, Ethereum, Arbitrum and Solana, plus a USDG route from Robinhood Chain. Availability is confirmed per route in the launch registry. Use only the assets, bridge providers and destinations enabled by the Swift interface; a route described here is not a claim of live integration.

Funds are sent to the user-specific deposit address and credited after the required transfer, sweep and finalization. At least 10 USDC must arrive after route fees. The first-deposit flow includes a one-time 1 USDC activation charge. The interface must calculate the full amount required for the selected route.

Deposit state

An external confirmation is not the same as a credited Exchange balance. The display should distinguish a transfer in progress, funds at the proxy, sweep requested, funds moved and account credited. The app waits for one deposit to be credited before submitting another because overlapping arrivals can require reconciliation.

Withdrawals

Withdrawals use the wallet’s actual authority and are limited to available funds. Margin still committed to a position and unpaid queue claims are not part of that available amount. The minimum is 10 USDC. The underlying withdrawal path sends to the user’s HyperCore spot account; supported interface routes can additionally move funds to other enabled networks.

Direct wallet withdrawal is distinct from a wallet-signed withdrawal intent submitted by another caller. A session key cannot authorise a withdrawal. A claim from the swiftX staking flow credits the Exchange balance first; it is not itself a direct external withdrawal. The Ethereum-mainnet SWIFT staking payout and cross-chain fee-delivery path are separate implementation items and must not be assumed to use this same claim route.

Fees and failed credit

Show bridge and route fees before confirmation. Amounts below the sweep minimum wait at the deposit address. Some abnormal sweeps require owner reconciliation; the technical deposit section explains that dependency. Do not send an arbitrary ERC-20 token directly to the proxy and assume it will become a trading deposit.

Session keys

Delegated trade signing without giving the session withdrawal authority.

A session key is a scoped key authorised by a wallet signature. It signs ordinary opening and closing intents for that account, which a relayer submits on-chain. It can use the account’s available trading balance or eligible queued claims as margin.

Lifetime and intent expiry

The session lasts 30 days. Each trade intent signed by it has a one-hour validity window. The interface requests a replacement session when the current session has less than one hour left. Session expiry and individual intent expiry are separate checks.

Revocation

The user can revoke a session directly through SessionKeyManager using the actual wallet. This is a HyperEVM transaction and requires native gas. Pending trade intents signed by the revoked key can no longer execute under that authority. Revocation does not retrospectively reverse trades that already executed.

Compromise risk

A compromised session cannot directly withdraw to another wallet, but it can still submit damaging trades and lose the balance or claims placed at risk. Keep the permission scope visible and make revocation accessible. The delegated experience should not be described as risk-free because withdrawals are excluded.

Architecture overview

Contract state, HyperCore custody and relayed user intents.

The architecture separates on-chain trading state on HyperEVM from USDC held on HyperCore. The Exchange maintains per-user accounting, positions and queue obligations, and uses HyperCore interfaces for price reads and balance movement.

SWIFT staking and burn conversion connect the Ethereum token to the participation model. Component names describe responsibilities rather than verified ABIs or deployed addresses. Their implementation must preserve the rights and accounting boundaries set out here.

Network boundary: Ethereum and the trading protocol

SWIFT is specified on Ethereum mainnet. The trading, queue and swiftX-staking architecture remains on HyperEVM with USDC accounting on HyperCore. Staking-fee delivery and burn-to-swiftX issuance require their own cross-network settlement design. The deposit proxy flow does not perform either function.

The launch specification must identify the canonical SWIFT staking location, how its 11% fee allocation is delivered, the destination of newly minted swiftX, and how an Ethereum burn is recognised exactly once. It must cover finality, replay prevention, outages, fees and recovery after a burn whose destination mint is delayed. No bridge, message verifier or atomic cross-chain transaction is represented as selected here. An irreversible burn must not be enabled before that delivery and recovery path is specified and tested.

A trade through the system

Wallet or session signature → relayer → BatchExecutor
→ Exchange → BBO read / settlement
→ balances, queue, fee records and loss emissions

Only configured relayers submit ordinary trade batches. Individual user signatures are still verified, and multiple user intents may be processed in one EVM transaction. An alternative frontend can prepare compatible intents, but that does not make direct opens or closes publicly callable.

Other reference reads

The pricing architecture exposes BBO for execution, a mark read for analytics or future cross-checks, and an oracle read for forward compatibility. Merely exposing a mark or oracle read does not mean an independent deviation check is active in execution.

Pricing: BBO reads

The execution reference and the limits of reading it directly.

The pricing wrapper reads the current best bid and best ask for the configured HyperCore asset index and uses their midpoint. A static read exposes the reference state to the Exchange without a separate off-chain price signer.

price = (bid + ask) / 2

The specified mappings use BBO at the address ending 0x080e, mark at 0x0806 and oracle at 0x0807, with BTC/ETH asset indices 0 and 1. The deployment registry must confirm the full addresses, asset encoding and precision for the target environment before use.

Validation

The wrapper rejects zero values and a crossed book where ask is below bid. It does not include a maximum-deviation, lookback or time-weighted-price breaker in the design. A nonzero, uncrossed but economically distorted quote can still pass those checks.

Market availability

The reference must exist in Hyperliquid’s supported market infrastructure. The protocol cannot list an arbitrary asset merely by inventing a ticker. New instruments require an owner-configured mapping and their own parameters.

Market retirement

The pause guardian can retire an instrument ID. Retirement snapshots its BBO, blocks new opens and makes existing closes and liquidations use that frozen reference. The current implementation offers no unpause for the retired ID; a relisting uses a fresh ID. Upgrade authority qualifies any broader claim of immutability.

The global opens gate is different. It blocks new positions without freezing prices for existing closes or liquidations. The guardian can engage it; the owner controls lifting it. The market keeper can also stop new directional exposure through a zero cap, without changing the reference price.

Asymmetric impact PnL

The order of operations for every profitable close.

A profitable close is processed in a fixed order: apply the deadband, reduce the remaining gain with the impact curve, then deduct the 2% win fee. Losing closes do not pass through this profit-scaling formula.

Directional gain and deadband

N = position notional
r = favourable fractional move from entry
d = 1 / 50,000 = 0.00002
m = max(r − d, 0)
G = N × m

If m is zero, the deadband leaves no payable gain. This representation uses a direction-adjusted move, so a favourable short move is treated consistently with a favourable long move. It expresses the documented logic in ordinary units; fixed-point precision and contract rounding must match the implementation.

Impact and win fee

term1 = 1 / (m × rateMultiplier)
term2 = referenceNotional / (C × m × positionMultiplier)
scale = (1 − baseRate) / (1 + term1 + term2)
adjustedGain = G × scale
winFee = 0.02 × adjustedGain
netProfit = 0.98 × adjustedGain

C is the fixed power-of-ten normalisation for the formula’s encoded units. C = 10^6 is consistent with the BTC examples below when the displayed parameter units are used. Exact fixed-point encoding, normalisation and rounding must be verified in the contract before these explanatory equations are used for execution.

Economic properties

The percentage reduction depends on the move, not the actual position size: referenceNotional is fixed per instrument. Very small profitable moves retain the least. As m grows, the scale approaches 1 − baseRate; it does not approach 100% when baseRate is nonzero. A baseRate of 10% therefore implies an asymptotic 88.2% retained fraction after the win fee, before the diminishing relative effect of the deadband.

For orientation, the BTC examples retain about 88% of raw gain on a 1% favourable move and about 74% on a 0.1% move, before the 2% win fee. These are approximations, not execution quotes. The haircut is an economic friction, not proof of oracle-manipulation resistance.

Solvency and queue accounting

Three accounting categories and strict FIFO payment priority.

The accounting model

Treasury represents the Exchange’s USDC accounting. User available balances, committed cash margin and recognised fee obligations are not freely available bankroll cash. sideBucket earmarks cash loss proceeds for queue repayment; it is included within the relevant cash accounting, not an extra asset to add a second time. Queue entries record unpaid user claims.

net LP equity = LP cash (including sideBucket) − totalQueued
lpBankrollAvailable() = 0 whenever the payout queue is nonempty

Treasury and sideBucket are unsigned and cannot be negative. Net LP equity can be negative. A nonempty queue prevents a new winning close from bypassing earlier claims even when some cash is available to harvest the queue.

Winning closes

The win fee is calculated on adjusted profit. If the queue is empty, the user receives a direct payment up to the available payout budget; any shortfall is appended to the queue. If the queue already contains claims, the new payable amount is appended. A queued amount does not move cash at that instant. Fee distributions retain their original cash and queue conditions.

Cash-funded collateral is credited independently of unpaid profit. A claim-funded close is different: the surviving claim includes its original contingent collateral plus net profit, or less any loss, and the whole surviving claim must be paid or queued.

Losses and liquidations

Cash-funded losses while the queue is empty add the retained portion to LP cash. With an active queue, the applicable loss fee is waived and the cash is earmarked in sideBucket. Those losses still advance tracked LP when settled and still qualify for the applicable swiftX emissions.

Claim-funded losses and liquidations create no cash. They cancel debt. Nothing is deposited into sideBucket merely because a queued claim was destroyed. A voluntary claim-funded loss can carry the LP-side fee only when free cash covers the surviving claim and fee and the queue is empty.

Harvest

harvest(maxEntries) processes the queue head first, paying from available backing and debiting sideBucket first. A partly unpaid entry stays at the head. When the queue clears, residual earmarked cash is released to ordinary LP cash. Neither payment nor release counts the original trading loss again in tracked LP. Harvest is public and does not pay its caller; the standard keeper batch is 32 entries.

Distribution priority

The 45/44/11 fee-recipient allocation does not alter which claims are paid first, increase the total trading fee, or entitle either staking pool to protected balances. Fee and surplus distributions use their funding gates. SWIFT burns do not enter treasury, sideBucket, tracked LP or queued-debt cancellation as though a trading loss had occurred.

swiftX mint curve

A flat loss-emission region followed by a historical-progress tail.

The loss curve determines swiftX issuance from eligible trading losses. A read-only quote of the same calculation also determines SWIFT burn output in Section 25 without recording a fictitious loss. It does not determine SWIFT’s market reference price. Tracked LP, historical tail progress and eligible loss basis remain separate quantities and must not be collapsed into a cash-balance variable.

Flat region

When trackedLpUsd is below lpFlatThresholdUsd, including negative values, the documented marginal rate is flatRate. The specified values are lpFlatThresholdUsd = $2 million and flatRate = 100 swiftX per $1 of eligible basis.

Tail region

r(H) = flatRate × (S / (S + H))^a
H = tailProgressUsd
S = tailDecayScaleUsd = $120 million

H records the high-water progress of cumulative tail-region LP gain and does not decrease when surplus is distributed. The illustrative rate of roughly 30 tokens per dollar at H = $100 million is consistent with a = 2. The exponent and exact threshold-transition arithmetic remain contract-verification items in Appendix A.

One-way history

A surplus distribution reduces tracked LP but does not rewind H. The historical tail rate is not restored merely because the bankroll distributed gains. The flat-region condition separately depends on tracked LP. Its interaction with an advanced tail counter after a drawdown must be verified in the contract; it should not be inferred from the illustrative curve alone.

Loss-basis matrix

For events wholly inside the flat region, multiply eligible basis by 100. A loss spanning a boundary or materially advancing tail progress requires the verified contract calculation, not an assumed single-rate shortcut. Token decimal precision, rounding and cumulative-state updates belong in the verified parameter and test schedule.

A SWIFT burn mints 50% of a read-only loss-curve quote for the input’s reference value at conversion. Quoting does not make the burn a trading loss or permit it to advance tracked LP, queue backing, debt cancellation or the historical trading-progress counter. The quote must reproduce the same applicable curve calculation, including boundary handling, without persisting simulated trading-state changes.

Deposits: CREATE2 proxies

Deterministic addresses and asynchronous deposit reconciliation.

A per-user proxy address is derived deterministically from a factory, salt and fixed deployment bytecode. It can be predicted before deployment and can receive funds first. The interface registers the address with the relayer, which deploys the proxy after the required minimum has arrived.

Supported routing

The specified routing sends HyperCore transfers, Circle CCTP arrivals and Across fills to the HyperCore side of the user’s deposit address, where those routes are enabled. The guided HyperEVM path first moves native USDC through CoreDepositWallet. An ordinary ERC-20 transfer directly to the proxy is not automatically monitored as a trading deposit.

Deposit address receives eligible Core USDC
→ requestSweep(user) records balances and starts movement
→ Core transfer clears into the Exchange account
→ finalizeSweep(user) credits the internal user balance

The sweep looks across the proxy’s spot and withdrawable perpetual USDC balances. The minimum moved is 10 USDC. Amounts below that remain until more arrives. First-time credit also waits for proxy deployment.

When finalization cannot confirm a decrease

Credit is conditional on the proxy balance falling as expected. A failed transfer or an overlapping arrival can hide the decrease. The flow then drops the old snapshot without crediting it and requests a fresh sweep. Funds from the old sweep that really reached the Exchange can require owner credit through reconcileSweepCredit. This is why the app serializes deposits for each user.

Permissions and recovery

Sweep and finalization maintenance are public, while proxy deployment is restricted to the relayer. The proxy’s sweepAllToExchange function is callable only by the Exchange. Accidental ERC-20 deposits have a separate withdrawStuckToken recovery path for the proxy owner; they are not normal credited deposits.

What deterministic deployment guarantees

A changed deployment bytecode produces a different derived address; it does not silently assign different code to the same deterministic address. This helps verify the destination. It does not eliminate the need to validate the factory, token route, sweep accounting, reconciliation authority and actual deployed code.

Frontends and builder integration

Frontends submit authorised intents; they do not change protocol permissions.

An alternative frontend can prepare user intents compatible with Swift and send them through the configured relayer. It does not gain direct permission to open or close positions by changing the interface. User wallet or session signatures remain required.

Builder integration

A builder program can attribute originated trades to a frontend identifier. No Swift builder allocation, registration contract or payout interface is approved in this edition. Any future program must state its calculation base and funding source before activation.

Builder compensation must come from an explicitly disclosed recipient budget. It must not silently increase the trading charge, reduce either staking pool or add an allocation on top of the 45/44/11 fee split.

Integration specification

The verified integration package must include networks and contract addresses, ABIs, signed-message domains and fields, nonce and expiry rules, relayer endpoints, supported actions, indexed events and error behaviour. Wallet signatures must be checked regardless of which frontend originates the intent.

Frontends should distinguish signed, submitted, confirmed, paid and queued states. A successful signature or relayer submission is not proof that a trade has executed or that a payout has been funded.

Deployment identity

Swift interfaces must identify the Swift contracts and operators they use. This document does not imply an external partnership, permission to modify another deployment or completion of an audit. Any third-party code reuse requires the applicable permissions and licence compliance.

Risk and administrative control

Trading, token, operational and administrative risks.

Market and liquidation risk

Leverage magnifies small reference-price changes. Hard liquidation can forfeit margin that a voluntary close would still return. The reference midpoint can change before transaction execution, and normal trade submission depends on relayer availability.

Price-reference manipulation

The BBO is an executable reference, not an independently validated economic fair value. A small change at the inside quote can move the midpoint. The 0.2-basis-point deadband, asymmetric impact and directional limits reduce some payouts or exposure but do not establish that quote manipulation is impossible or unprofitable.

Directional open-interest policy

The specified launch policy targets each side’s current OI plus asset quantity worth about $1 billion at the current BBO, with a 10% headroom band around that target. This is moving headroom, not a $1 billion total-OI ceiling, loss limit, reserve balance or insurance guarantee. Swift must verify the actual keeper policy and limits before launch.

Liquidity and queue risk

An unpaid winning claim depends on future available backing. A permissionless harvest does not manufacture cash. Claim-funded trading can reduce debt without adding liquidity. Token distributions have no guaranteed size or frequency and remain subordinate to their funding conditions.

The contracts are upgradeable. Restricted ordinary functions do not establish that an owner-authorized upgrade can never change those rules. A live deployment must disclose owner addresses, upgrade controls and any timelock or multisignature safeguards actually in use.

Token, conversion and operations

SWIFT price, any token-market charge, staking access and swiftX dilution add risks. Fixed supply and burning do not guarantee appreciation; tradability does not guarantee market liquidity. Staked SWIFT must satisfy withdrawal rules before becoming transferable.

Burn pricing, stale-price checks, manipulation controls and output protections remain to be specified. The trading BBO is not automatically a valid SWIFT price source. Ethereum burns require verified cross-network recognition and destination minting: one burn must not mint twice, and delayed delivery must not be reported as complete. Conversion creates no bankroll cash or debt cancellation and can dilute existing swiftX stake despite the mint discount.

Keeper and relayer delays can affect deposits, trades, distributions and claims. Bugs or compromised authority can defeat documented intentions. Completed audit scopes and findings must be published separately from this specification.

Self-bootstrapping bankroll

A bankroll built through activity, with explicit obligations when payouts must wait.

Swift’s bankroll can begin without prefunded LP capital because settlement distinguishes a trading obligation from its immediate payment. A winning close may create an on-chain accounting claim before enough cash exists to pay it. That claim stays recorded until paid, or until the user puts it at risk again through claim-funded trading.

Paying a winning settlement

When the queue is empty and enough free payout cash exists, the close is paid directly. Otherwise, the unpaid amount enters the queue. Existing entries remain ahead of new claims, and harvest pays from the front as backing becomes available. The queue establishes priority, not a promised payment date.

Why loss emissions exist

Eligible realised losses mint swiftX, giving traders participation in designated future distributions when those tokens are staked. This prospective participation can encourage activity while the bankroll is small or indebted. It does not replace the cash required to pay winners.

Participation beyond trading

SWIFT staking opens a separate route to the 11% fee pool without requiring a leveraged position. A permanent SWIFT burn provides an optional route into swiftX at half the equivalent loss-curve mint quote. Neither buying SWIFT nor burning it is recorded as trading-bankroll funding.

Boundaries of the model

A recorded liability is not a guarantee that sufficient cash will arrive. A revenue-participation token can distribute less than the cost or loss that produced it. Positive expected returns, guaranteed recovery and a fixed payout schedule are not implied.

Yield-bearing collateral, automatic redemption of queued claims through another asset and an alternative queue-redemption escape route are not part of this specification.

SWIFT overview

A fixed-supply Ethereum token with optional staking participation.

SWIFT is the native token of Swift and is issued on Ethereum mainnet with a fixed initial supply. Users stake SWIFT to participate in the smaller revenue pool: 20% of the 55% participant allocation, equivalent to 11% of total eligible protocol fees.

Supply

Trading losses do not mint SWIFT. They mint swiftX under the loss-emission rules. The conversion route also does not mint SWIFT: it permanently burns SWIFT to issue swiftX. The launch specification must publish the initial quantity and verify that no subsequent inflationary mint authority exists.

Current SWIFT total supply = fixed initial supply − cumulative SWIFT burned

Transfers and staking do not themselves reduce total supply. A transfer of collected fees to a treasury is not a burn. Total supply, freely circulating supply and the amount staked are different measures.

Stake without taking a leveraged position

SWIFT staking provides a purchasable route into protocol-fee participation. The staker need not trade or realise a loss to join this pool. Merely holding SWIFT outside the eligible staking system does not earn the 11% allocation.

The reward is proportional to eligible SWIFT stake, not a fixed personal percentage of the platform, a company-equity interest or a guaranteed return. The SWIFT pool is funded only by eligible protocol fees under the upstream funding conditions.

Tradability and access

SWIFT remains a tradable token. Staking does not permanently destroy it; withdrawing returns the staked token under the published withdrawal rules. Staked units cannot simultaneously be treated as freely transferable wallet balances. The staking interface, withdrawal timing, eligible supply and fee-delivery chain must be finalized before launch. Neither tradability nor fixed supply guarantees market liquidity or price appreciation.

Optional burn conversion

Users may permanently burn some or all of their SWIFT to mint swiftX. The output equals 50% of the current loss-curve mint quote for the reference value of the amount actually burned. Burned units stop earning future SWIFT staking rewards. Conversion is one-way; swiftX cannot be redeemed back into SWIFT.

Separate token-market charges

A separate 5% SWIFT token-market charge has been proposed for development and operating uses. Its scope and activation status remain to be confirmed in the token launch schedule. Any such charge must disclose buy/sell treatment, staking and burn treatment, exemptions, recipients and change authority. It is not a 5% leveraged-trading fee and is not automatically part of either staking pool.

Launch disclosures

Publish the initial fixed supply, token address on Ethereum mainnet, allocations, vesting, liquidity arrangements and actual contract controls. A fixed-supply policy does not establish a no-premine or no-team-allocation launch; neither claim is assumed. Publish the staking and conversion contract registry and any completed audit scope separately.

swiftX overview

One revenue-participation token. Two issuance routes. Equal rights per staked unit.

swiftX is the protocol’s revenue-participation token. Stakers receive 80% of the participant fee allocation, equivalent to 44% of total eligible protocol fees, plus qualifying LP-surplus distributions.

swiftX starts at zero supply with no premine. Supply grows through eligible trading losses and SWIFT burns. Both issuance sources are tracked, and neither changes SWIFT’s fixed initial supply except that burns reduce it. SWIFT launch allocations are separate.

Issuance from trading losses

Eligible losing closes and liquidations mint swiftX using the loss calculations, fee treatment, emission curve and historical progress rules in Section 16. Winning closes and unrealised losses do not mint loss rewards.

Issuance from SWIFT burns

A permanent SWIFT burn provides a separate route. The burned amount’s reference value at conversion is passed to the current loss-curve mint quote, and 50% of that quote is issued as swiftX. The original purchase price and an arbitrary one-for-one token ratio are not used.

Conversion does not create a realised trading loss, fund the bankroll or cancel a queued obligation. It reduces SWIFT supply and increases swiftX supply under the conversion rules; the two supply changes are recorded separately.

Identical rights after minting

Loss-earned and burn-earned swiftX have identical reward rights per staked unit. The burn route receives fewer tokens for the reference value, not a permanently discounted class of rewards. Holding unstaked swiftX does not receive a staking distribution.

Transfer and staking behaviour

The launch design disables ordinary wallet-to-wallet swiftX transfers while supporting minting, staking, unstaking and claims. swiftX is not a liquid substitute for SWIFT. Unstaking returns swiftX, not the SWIFT burned or money lost to obtain it. There is no reverse swiftX-to-SWIFT conversion.

Fee and surplus participation

The swiftX fee pool is 0.44 × eligible protocol fees. Qualifying LP excess above the $5 million tracked-LP threshold remains fully assigned to swiftX stakers under the distribution rules. The 45/44/11 fee split does not divide that separate surplus stream.

Each staker receives a proportional entitlement within the eligible swiftX stake. A larger collective allocation does not guarantee a larger individual return than SWIFT staking; results depend on stake, supply, distributions and acquisition cost.

Dilution and limits of the token

Both issuance routes can increase swiftX supply and reduce an existing staker’s share of future distributions. A swiftX balance is not USDC, position collateral, a queued winning claim, a refund or a fixed-value redemption entitlement. No fixed yield or maximum swiftX supply is specified by this document.

SWIFT staking and rewards

Stake the Ethereum token for a proportional share of the 11% fee pool.

SWIFT participation is staking-based. Eligible SWIFT stakers collectively receive 20% of the 55% participant allocation, equivalent to 11% of total eligible protocol fees. Holding unstaked SWIFT does not earn this allocation.

Economic entitlement

F = eligible protocol-fee amount
SWIFT pool = 0.11 × F
Staker reward = SWIFT pool × (eligible user stake / total eligible SWIFT stake)

For a distribution containing $10,000 of eligible protocol fees, the SWIFT pool is $1,100. A user with 1% of the eligible SWIFT stake receives $11 from that pool. The example assumes a nonzero total stake and ignores rounding; it is not a yield forecast.

Staking does not burn SWIFT

Staking commits tokens to reward eligibility without permanently destroying them. The token remains tradable after withdrawal under the published rules. The launch policy must specify the staking contract, withdrawal timing, reward measurement points, treatment of accrued rewards and applicable transaction fees. A no-cooldown promise is not inferred from the separate swiftX contract.

Keep the two staking systems distinct

SWIFT staking and swiftX staking have separate contracts and reward pools. SWIFT’s ABI, approval requirements, claim process, distribution cadence and empty-pool treatment must be published in its launch specification. Trading-session or swiftX-relayer permissions do not automatically authorise Ethereum SWIFT staking actions.

Reward asset and network delivery

The designated fee entitlement is denominated in USDC, following the protocol’s fee accounting. SWIFT exists on Ethereum mainnet while the Exchange accounting is on HyperEVM/HyperCore. The canonical staking location and delivery of its fee allocation must be explicitly defined, including finality, message verification, fees and delayed-delivery handling. This document does not promise instant cross-chain payouts or select a bridge.

Transfers, withdrawals and burns

The accounting must preserve already-earned rewards when stake changes and prevent the same unit from earning as both a burned SWIFT stake and newly issued swiftX. A burned amount stops qualifying for future SWIFT staking rewards. The remaining staked balance can continue earning.

A user may keep part of their SWIFT staked and burn another part. The newly minted swiftX becomes eligible for its own pool only when staked. Both eligible positions may earn simultaneously because they represent different, non-overlapping token balances.

Distribution conditions

The 11% pool comes from the same existing eligible fee budget. Its upstream cash and queue conditions do not change. Allocations are collective and proportional, not guaranteed income or a fixed individual percentage of the platform. A separately enabled token-market charge is not automatically shared through this pool.

swiftX staking and claims

Instant stake changes and pro-rata rewards at distribution.

Stake

The app flow uses a wallet signature submitted as stakeBySig through the relayer. Direct stake calls are disabled. The participation token auto-approves its staking contract, so there is no separate approval transaction in this flow. Once included, the stake shares in subsequent distributions without vesting or lockup.

Unstake

The app submits wallet-signed unstakeBySig through the relayer. Tokens return to the wallet immediately on successful execution, future earning on that stake stops, and already accrued USDC remains claimable. There is no contractual cooldown; relayer and chain availability still determine when the transaction executes.

How fees reach staking

The Exchange accumulator collects the appropriate staker fee share. The public pushStakerFees() maintenance path forwards eligible accumulated fees and qualifying LP surplus toward the staking distribution path. Swift’s routing separates the 11% SWIFT staking pool and 45% platform share. The swiftX staking path receives its 44% fee allocation plus its qualifying LP-surplus entitlement. No additional fee is created by this separation.

After funds reach staking, a keeper-signed distributeBySig submitted through the relayer updates the global accRewardPerShare accumulator. Direct public distribute() is disabled. Forwarding funds and allocating rewards are distinct events; a public fee push alone does not make every received dollar an individual pending reward.

Distribution math

Reward_i = new swiftX distribution × (stake_i / total stake)
Stake balances are measured at the distribution event.

Each staked unit earns the same amount from a given distribution, regardless of whether it was earned through a loss or minted from a SWIFT burn. The burn route’s 50% mint discount is not applied again to staking rewards. There are no duration boosts, tiers or lockup multipliers. Balances are measured at the distribution event, not weighted by the length of time they have been staked.

Claims

Wallet-signed claimBySig, submitted through the relayer, credits the user’s USDC balance on the Exchange. A separate withdrawal can then move available funds to HyperCore. pendingReward(addr) reports rewards already allocated, not all revenue waiting in the Exchange or staking contract.

Function names describe the required contract flow; verified ABIs belong in the deployment registry. Exact rounding, empty-staker handling and transfer/debt bookkeeping require implementation verification. The Ethereum SWIFT staking system is separately specified in Section 23.

Burning SWIFT to mint swiftX

A permanent, value-based conversion into the same swiftX participation token.

Users may permanently burn some or all of their SWIFT to mint swiftX. This route is separate from eligible trading losses. It uses the loss curve as a mint quote, not as an instruction to book a fictitious trading loss.

Conversion calculation

B = quantity of SWIFT actually burned
P = verified SWIFT reference value per token at conversion
V = B × P
Q(V, state) = loss-curve mint quote for reference value V at current state
swiftX minted = Q(V, state) × 0.50

Use the reference value at conversion, not what the user originally paid. There is no arbitrary one-for-one SWIFT-to-swiftX token ratio. The quantity actually destroyed defines B; any SWIFT separately collected as a fee is not part of the burned amount.

Q must use the same applicable loss-curve mint calculation, including its eligible-basis convention, threshold handling and precision. It must not be replaced with a permanent 100-tokens-per-dollar shortcut. In flat-region examples, the stated qualifying loss value is eligible mint basis; a $100 gross voluntary loss with a loss-fee carve can have a different qualifying basis.

A 50% mint-quantity discount

If a $100 qualifying loss would mint 10,000 swiftX under the current curve, burning SWIFT with a reference value of $100 mints 5,000 swiftX. If the applicable quote instead produces 9,800, the burn route produces 4,900. The rule is always half of the actual quote.

The resulting tokens are not half-reward swiftX. Once staked, each unit has the same reward rights as a loss-earned unit. For a fixed stake total and distribution, 5,000 staked units receive the same payout regardless of issuance source; a larger 10,000-unit stake receives twice that payout because it contains twice as many units.

One-way supply reduction

The conversion permanently reduces SWIFT’s total supply. It does not lock the input for later return. swiftX cannot be converted back into SWIFT, and unstaking swiftX does not restore burned SWIFT. Conversion may increase swiftX supply and dilute existing swiftX participation even while SWIFT supply falls.

Partial conversion and participation

Users can convert a portion rather than the whole holding. When the input is staked SWIFT, that amount must be removed from the SWIFT reward-bearing stake before or as part of the burn. The exact unstake-and-burn transaction flow is still to be published. Already-earned rewards remain subject to the staking accounting; burned tokens stop earning future SWIFT rewards.

For example, a user with 1,000 SWIFT could retain 600 staked SWIFT and burn 400. If the verified conversion price were $0.25 per SWIFT and Q($100, state) were 10,000, the burn would mint 5,000 swiftX. The remaining 600 staked SWIFT could continue earning from the SWIFT pool, and the 5,000 swiftX could earn from the swiftX pool once staked. This example omits gas and any separately specified conversion charges.

Price changes and expectations

If SWIFT appreciates, the same token quantity represents a larger reference value at conversion. The output is then evaluated using that value and the applicable current loss curve. The original purchase price is irrelevant to the quote. Neither appreciation nor larger individual earnings is guaranteed; curve state, eligible stake totals, realized distributions and conversion charges can all affect the outcome.

Trading accounting must not change

Burn conversion creates no USDC trading revenue, no bankroll funding and no cancellation of payout-queue debt. Do not credit treasury, sideBucket or tracked LP as though cash arrived, and do not advance historical trading progress for a burn. Q may simulate the curve across a value range to obtain an accurate quote, but simulated trading-state changes are not persisted.

Track actual burns and swiftX issuance separately. Genuine trades continue using the original loss, fee and settlement rules.

Pricing and manipulation protections: not yet specified

The reference-price source, averaging or observation method, supported market liquidity, staleness rules, manipulation checks, quote expiry and user output protections must be selected and verified before conversion launches. No particular oracle or spot market is assumed safe merely because it is on-chain. The user interface must identify the actual source and show the reference value used.

Ethereum burn and destination mint

SWIFT is on Ethereum mainnet; the trading and swiftX system is on HyperEVM. The implementation must specify how a finalized burn is recognised once, where swiftX is issued, and how delayed or failed delivery is recovered without reversing the permanent burn. A message protocol, proof scheme, bridge, finality policy and recovery interface have not been selected in this document. The existing trading-deposit flow does not by itself solve this issuance path.

Confirmation and launch requirements

Before a burn, display the actual SWIFT input, reference value and source, loss-curve quote, 50% mint multiplier, expected swiftX output, applicable charges, destination network and irreversible conversion notice. Finalize the valuation convention, precision, minimums or issuance limits, fee treatment, change authority and delivery protections. None of these open implementation items changes the agreed economic rule: half the quoted mint quantity, full per-unit staking rights.

Parameter schedule and publication checks

Protocol parameters and the remaining launch configurations.

Confirmed Swift decisions

Trading and accounting parameters

Launch decisions still open

Publish SWIFT’s exact initial supply, allocations, vesting and market arrangements; the Ethereum staking contract and withdrawal rules; stake measurement, claims and fee-delivery route; swiftX destination and cross-network burn recognition; conversion reference pricing and manipulation protections; the precise qualifying-basis convention, precision, output protection and any conversion limits or charges.

The proposed 5% SWIFT token-market charge requires a separate launch decision on activation, buy/sell scope, staking and conversion treatment, exemptions, recipients and change authority. It is not a fee on leveraged trades or automatically part of the 45/44/11 allocation.

Source-code verification still open

Check exact impact normalisation and fixed-point encodings, mint-curve exponent and threshold-crossing arithmetic, drawdowns interacting with the historical ratchet, fee accounting when payout is withheld, zero-staker handling, accumulated-reward rounding, signature fields/nonces/expiries, and all balance/queue state transitions. Verify that trading-loss minting is unchanged and burn quote evaluation does not persist trading-state changes.

Cross-network verification

Specify finality and replay protection, canonical token and stake registries, unique burn recognition, destination mint authority, fee-transfer accounting, pending states and delayed-delivery recovery. The source burn must not be counted twice or mint destination tokens before the approved verification conditions are satisfied.

Launch publication requirements

Publish verified networks and contract addresses, implementation hashes, owner and operator authorities, ABIs and relayer endpoints, supported funding routes, live parameters, token disclosures, conversion policy, and any completed audit findings. Do not claim live support, guaranteed repayment, guaranteed positive expected value, immutability or external affiliation without evidence.

Accounting examples and glossary

The same trade accounting, with revised fee recipients and a separate burn quote.

Example 1: a cash-funded voluntary loss

Assume a $100 realised loss, an empty queue, sufficient funding for the applicable 2% loss-side fee, and an event wholly within the flat emission region. The bankroll retains $98. The $2 fee allocates $0.88 to swiftX stakers, $0.22 to SWIFT stakers and $0.90 to the platform. Eligible loss basis is $98, so 9,800 swiftX is minted. No SWIFT is minted.

Example 2: a liquidation

On a $100 cash-margin liquidation with the fee applied, the same $98 is retained and the same $2 fee is divided 44/11/45. Unlike a voluntary loss, the mint basis is the full $100, producing 10,000 swiftX in the flat region. Full-margin minting does not credit the full $100 to tracked LP after the fee.

Example 3: an active payout queue

A $100 cash loss during an active queue has its loss fee waived. The $100 is earmarked for queue backing and qualifies as loss basis. Participant and platform fee payouts do not take priority. A $100 claim-funded liquidation instead cancels $100 of debt and mints on that basis; it adds no cash.

Example 4: an adjusted winning gain

Assume the gain after deadband and impact is $100. The win fee is $2 and the user’s profit claim is $98. When the fee is eligible for distribution, it produces $0.88 for swiftX stakers, $0.22 for SWIFT stakers and $0.90 for the platform. Original cash margin is handled separately. An active queue prevents an immediate recipient payout ahead of winning claims.

Example 5: qualifying LP surplus

A $100,000 qualifying surplus distribution is not a $100,000 protocol-fee allocation. Under the unchanged mechanism, it is assigned to swiftX stakers subject to the existing funding rules. The 45/44/11 fee allocation is not applied to this separate stream.

Example 6: half of the loss-curve mint quote

Assume a reference value of $100 for the SWIFT actually burned and a current qualifying loss-curve quote of 10,000 swiftX for that value. Conversion mints 5,000 swiftX. This example uses $100 of qualifying mint basis, not a claim that every gross $100 voluntary loss mints 10,000. If the actual qualifying quote is 9,800, conversion yields 4,900.

The burn creates no cash, no trading loss and no debt cancellation. It permanently reduces SWIFT supply by the number of units destroyed and issues only the calculated swiftX amount.

Example 7: collective pools and individual entitlements

A distribution contains $10,000 of eligible protocol fees. The platform receives $4,500, the swiftX pool $4,400 and the SWIFT pool $1,100. A user with 1% of eligible SWIFT stake receives $11. A user with 1% of eligible swiftX stake receives $44 from the fee pool, plus their proportional share of any separately distributed qualifying LP surplus. The same wallet may hold both stakes; each entitlement is calculated independently.

Example 8: identical swiftX rights

An eligible pool contains 1,000,000 staked swiftX and receives $10,000. A 5,000-unit stake receives $50 whether the tokens originated from losses or burns. The mint-quantity discount is not applied to this distribution again. Additional issuance can change the total stake and therefore the proportional payout.

Example 9: conversion value is measured at conversion

Suppose 400 SWIFT was bought when its price was $0.10, but the verified reference price at conversion is $0.25. The conversion reference value is $100, not the $40 original purchase cost. The output is half the current loss-curve quote for $100. A lower conversion price would produce a lower reference value. The illustration is not a price forecast.

Glossary

Documentation and deployment status

A final editorial edition of the protocol design, not a deployment certificate.

This edition sets out Swift’s trading and participation model. It covers the user journey, trading calculations, bankroll and queue accounting, token issuance, staking, conversion, operational permissions and risks. The economic allocations in this edition supersede earlier drafts.

Defined in this edition

Eligible protocol fees are allocated 44% to swiftX stakers, 11% to SWIFT stakers and 45% to the platform. Qualifying LP surplus is a separate swiftX distribution stream. SWIFT has a fixed initial supply on Ethereum mainnet. swiftX is issued through eligible losses and permanent SWIFT burns, with burn output equal to 50% of the applicable reference-value loss-curve quote.

Launch details remain separate

An agreed economic rule is not evidence that its contracts are deployed or its integrations are live. The exact SWIFT supply quantity and launch allocations, SWIFT staking withdrawal rules, conversion pricing source, manipulation protections, cross-network delivery and verified contract registry remain launch items listed in Appendix A.

The burn route must not be enabled before its valuation, verification and recovery paths are specified and tested. This document does not promise an atomic cross-chain burn and mint, a reverse conversion, or instant reward delivery.

Technical verification

The explanatory formulas use readable units. Contract precision, rounding, threshold transitions, reward accounting, signature checks and recovery paths must be verified against the actual implementation. Function names identify intended responsibilities rather than a certified ABI.

Audits, implementation hashes, network addresses and operator authorities are published separately when verified. No audit outcome, live integration, guaranteed return, guaranteed queue repayment or external affiliation is asserted by this document.

Reading the examples

Examples illustrate accounting relationships under stated assumptions. They are not market quotes, yield forecasts or guarantees of token value. Per-user distributions depend on actual eligible stake and the funds allocated at a distribution event.