SwingTrade
SwingTrade is a decentralized protocol for on-chain volatility settlement, currently in beta. Trades settle in the same asset. Smart contracts calculate the settlement amount using a verifiable volatility factor.
Trading and settlement
A trade in SWING settles in SWING; a trade in ETH settles in ETH. Volatility settlement changes the amount of the asset rather than exchanging it for another token.
Each trade uses a volatility factor determined through Chainlink VRF. The resulting settlement amount may be higher or lower than the trade amount.
After the volatility factor is verified on-chain, the contract settles the trade and transfers the assets to the wallet. No claim transaction is required.
Providing liquidity
Liquidity providers deposit an asset into its pool to fund trade settlement and receive LP shares in return.
LP shares give providers a proportional interest in the pool’s settlement profits and losses. A positive pool edge creates an expectation of profit over many trades, but individual positions can lose value.
Each pool accepts a single asset. Withdrawals can be requested at any time, subject to on-chain confirmation and settlement of outstanding trades.
Supported assets
The beta supports ETH, SWING and other approved tokens. Support for any standard ERC-20 token is planned for a future release.
Available assets are listed in Pools.
Each asset pool has separate accounting, liquidity, LP shares and trade records.
Trade amounts are limited by the pool’s available liquidity. See Trade limits.
Before you start
Trading requires a balance of the selected asset and ETH for network gas fees. ERC-20 tokens require a sufficient allowance; native ETH does not require approval.
Before participating in the beta, review the settlement rules, fees, liquidity mechanics and risk notice.
Volatility settlement
Trade parameters
The user selects an asset and a trade amount. Each pool specifies a settlement multiplier range.
A settlement multiplier is determined independently for each trade within the pool’s range.
Base amount and multiplier
The base amount is the trade amount less the trading fee. The settlement amount equals the base amount multiplied by the settlement multiplier.
The multiplier describes a change in asset quantity, not market price. Net profit or loss also depends on the applicable fees.
Volatility factor
At launch, the volatility factor allows settlement multipliers of 0.3–5×. Custom multiplier ranges are planned for a future release.
Smart contracts enforce the multiplier range and settlement rules.
Verification
Chainlink VRF determines each trade’s volatility factor. The contract verifies the associated cryptographic proof on-chain before settlement.
Verification and settlement are recorded on-chain.
Reference: Chainlink VRF documentation.
Pool edge
Pool edge is the pool’s statistical advantage under its settlement rules. With a positive edge, total settlement payouts are expected to be lower than total base amounts received over many trades. This difference arises from settlement outcomes, not an additional fee deduction.
Pool edge ranges from 0% to 2%. Each pool’s setting is shown on its page in Pools.
Pool edge is not an LP yield or annualized return. It does not guarantee profit on individual trades or over any holding period.
Settlement example
For a 100 SWING trade with a 0.5% trading fee, 0.5 SWING is deducted and the remaining 99.5 SWING is used for settlement.
| Multiplier | Amount received |
|---|---|
| 0.5× | 99.5 × 0.5 = 49.75 SWING |
| 5× | 99.5 × 5 = 497.5 SWING |
VRF and network gas fees are separate and are not included in this example.
Trade limits
There is no protocol-level minimum trade amount. The maximum trade size is 5%–20% of the pool’s available liquidity, depending on the pool. The limit adjusts as available liquidity changes.
For a pool with a 5% limit, 1,000,000 units of available liquidity allow a trade of up to 50,000 units. If available liquidity falls to 800,000 units, the limit falls to 40,000 units.
Trade lifecycle
ERC-20 approvals
An ERC-20 approval authorizes a specific contract to spend tokens up to an allowance. It is required when the contract’s existing allowance is insufficient.
The app requests the maximum token allowance, with no amount to enter. Approval is skipped when the existing allowance is sufficient. Native ETH does not require approval.
Wallet confirmation
Approval and trading are separate transactions. When approval is required, the app waits for on-chain confirmation, then automatically requests trade confirmation in the wallet.
This requires two wallet confirmations. For native ETH or tokens with sufficient allowance, only the trade requires confirmation.
Canceling the trade request leaves the trade unsubmitted. Any approval already confirmed on-chain remains in place.
Awaiting the volatility factor
After on-chain confirmation, the trade awaits verification of the volatility factor and settlement.
You can submit another trade while settlement is pending. Each trade is processed independently; a new submission does not replace or accelerate an existing trade.
Closing the progress card or leaving the app does not cancel a submitted trade. Its status and result are available in Portfolio.
Settlement and payment
The contract calculates the settlement amount and transfers it to the wallet automatically. No claim transaction is required.
Settlement results, amounts received and on-chain records are available in Portfolio.
Callback failures and recovery
In rare cases, a failed settlement callback may leave a trade unsettled. The user can recover the base amount after 48 hours.
Recovery must be initiated by the user and applies only to trades left unsettled by a callback failure.
A trade awaiting its volatility factor has not necessarily experienced a callback failure. Its current status is shown in Portfolio.
Fees
Trading fees, VRF fees and network gas fees are calculated separately.
Trading fee
The protocol charges a trading fee of 0%–1%, paid in the asset used for the trade.
Each pool’s fee rate is shown on its page. The fee is deducted from the trade amount to determine the base amount.
VRF fee
The VRF fee covers the Chainlink VRF request that determines the volatility factor. It is separate from the trading fee.
Network gas fees
Network gas fees are paid in ETH for approvals, trades and liquidity transactions. The amount depends on network conditions and the computation required.
When approval is required, both the approval and the trade incur gas fees.
Providing liquidity
Redeem LP shares to withdraw the underlying assets.
Single-asset deposits
Liquidity providers deposit the pool’s asset, receive LP shares and supply the funds used to settle its trades.
For example, the SWING pool accepts SWING only. Each pool is accounted for separately, so providers participate only in that pool’s settlement profits and losses.
Liquidity deposits are currently limited to approved assets listed in Pools.
ERC-20 deposits require sufficient allowance for the liquidity contract. Approval for a different contract does not authorize the deposit.
How LP returns are generated
The pool receives each trade’s base amount and pays the settlement amount. The net difference increases or decreases the assets backing LP shares.
A positive pool edge creates an expectation of net settlement profit over many trades. Providers participate in these profits and losses in proportion to their LP shares.
Each pool’s edge is shown in Pools. A 0% edge provides no statistical advantage under the settlement rules.
Expected profit is not a guaranteed return. Actual results depend on trade volume, settlement outcomes and the provider’s share of the pool during those trades.
LP shares and positions
LP shares represent proportional ownership of the pool. Deposits issue shares; withdrawals redeem them for underlying assets.
A provider holding 100 of a pool’s 1,000 LP shares owns 10% of the pool.
Settlement profits and losses change the assets backing each share. A position can therefore gain or lose value without a change in its share balance.
Minimum deposit
Each pool has a minimum liquidity deposit, shown on its page in Pools.
Withdrawing liquidity
Providers can request a withdrawal at any time for some or all of their LP shares. Withdrawals require on-chain confirmation.
If the pool has unsettled trades, the withdrawal waits for those trades to settle before returning the redeemable assets. The page shows its status and progress.
The token amount returned is calculated from the pool’s state at execution and the shares redeemed.
Trading fees and pool edge
The trading fee is collected by the protocol. Pool edge is part of the settlement rules and determines the pool’s statistical advantage. Both are set separately for each pool.
LP returns come from net settlement profits and losses, not from protocol trading fees. They are reflected in the assets backing each LP share.
Portfolio and history
Portfolio
After connecting a wallet, open Portfolio beside the wallet address to view trade history and liquidity positions.
The Trades view lists trades and settlement results. The Liquidity view lists liquidity deposits and withdrawals. Positions are grouped by asset.
Trade status
Records distinguish approval, trade submission and settlement. Approval alone does not submit a trade.
Each trade record shows the asset, amount, current status and settlement result.
On-chain records
Each record includes a transaction hash linked to Etherscan. Approvals, trades and liquidity operations have separate on-chain records.
Contracts
Contract addresses, deployment networks and block explorer links will be published with the official release.
Beta and risk notice
SwingTrade is in beta, and its smart contracts have not been audited. Contract defects or operational failures may result in losses for traders and liquidity providers.
Traders may receive less than the amount committed. Liquidity providers may withdraw less than their original deposit, including when the pool has a positive edge.
FAQ
Why can the same trade amount produce different results?
The settlement multiplier is determined independently for each trade. Using the same asset and amount does not produce a fixed result.
Why are two wallet confirmations required?
An ERC-20 trade needs approval when the existing allowance is insufficient. Once approval is confirmed on-chain, the app requests the trade confirmation. Otherwise, only one confirmation is needed.
Why is my trade still awaiting settlement?
Settlement follows on-chain confirmation and verification of the volatility factor. Check Portfolio for progress. Other trades can be submitted while settlement is pending.
Do I need to resubmit a trade after closing the app?
No. Submitted trades continue on-chain. Check Portfolio for the status and result; resubmitting creates a separate trade.
Why does the trade limit change?
Each pool sets its limit within 5%–20% of available liquidity. The maximum trade amount changes as liquidity changes.
How do trading fees differ from pool edge?
The trading fee is deducted from the trade amount and collected by the protocol. Pool edge is the statistical advantage built into settlement outcomes, not a separate deduction.
Fees and edge are shown on each pool’s page. LP returns come from settlement profits and losses; neither parameter is an LP yield.
Can liquidity providers lose funds?
Yes. When settlement payouts exceed base amounts received, the loss reduces the assets backing each LP share. Providers may withdraw less than they deposited.
A positive pool edge creates an expectation of profit over many trades, not a guarantee for any holding period.
Why are LP shares different from the amount deposited?
Shares measure ownership of the pool, not a fixed token balance. The assets backing each share change with settlement profits and losses.
Why does a liquidity withdrawal take time?
A withdrawal requires on-chain confirmation and may need to wait for outstanding trades to settle. The redeemable assets are then returned. Withdrawal progress is shown in the app.