1. Protocol Design

Smart contracts enforce the settlement rules, liquidity providers supply the capital, and independent frontends give users access to the protocol. Developers can integrate directly without building a separate settlement system for each application.

Each settlement pool has its own assets, parameters, and settlement history. Its balances and settlement results are accounted for independently.

2. Pools and Participants

Anyone can create a pool for a standard ERC-20 token by paying a fixed creation fee and selecting a Pool Edge between 0% and 5%. Creating a pool gives its creator no authority over other users' positions.

The protocol has three main roles. An address can take on more than one.

LP positions are tied to the address that supplied the liquidity. Only that address can manage or withdraw its positions. Pool creators, protocol developers, and frontend operators have no authority to transfer these assets.

Figure 1. Access to the protocol

The diagram shows how users access the protocol. Funds do not pass through frontends, and the nodes do not represent individual contracts.

3. Volatility Settlement

The contract determines how many tokens a user receives, using public rules and a verifiable result. The variability is in the amount received. Users do not need to predict changes in the token's market price.

Users select a pool, a settlement amount, and a Volatility Factor from 0.5x to 5x. The factor determines the settlement range and the probability of each outcome. It is not a promised return multiple.

Each settlement follows four steps:

1. The user selects parameters, reviews the fees, and submits a request.
2. The contract checks the request against the pool's available liquidity limits.
3. The contract automatically calculates and executes settlement using the pool's parameters and a verifiable result.
4. The result is applied to the pool, updating its assets and the value of each LP share.

The pool takes the other side of the settlement. Users do not need a matching order from another participant. Whether a request can be accepted depends on available liquidity and the settlement rules.

4. Pool Edge and LP Returns

Pool Edge is the pool's long-run statistical advantage under the settlement rules. It is not an annualized yield, a protocol fee, or a frontend fee. It does not guarantee a profit on any individual settlement or over a given period. Realized returns depend on settlement sizes, the distribution of outcomes, and when an LP enters or leaves the pool. A 0% Pool Edge does not remove settlement risk or waive other fees.

LP shares represent a proportional interest in the pool. Settlement gains increase the value per share; settlement losses reduce it.

Excluding fees and other inflows or outflows, the effect of a single settlement is:

Net change in pool assets = Amount received from the user − Amount paid to the user

For example, if a user puts in 100 tokens and receives 150, the pool loses 50 tokens. If the user receives 60, the pool gains 40. These gains and losses are reflected proportionally in LP positions.

5. Liquidity Limits and Verification

A pool's available liquidity limits the size of each settlement. No request may exceed the pool's capacity. Per-request limits do not eliminate losses from a sequence of unfavorable outcomes. Funds committed to concurrent requests and the rules for LP withdrawals also affect the pool's ability to meet its payment obligations.

Users should be able to verify each settlement's input parameters, the source of its result, the payment calculation, and the resulting asset movements. Frontend operators cannot select or influence settlement outcomes.

The public release is intended to be open source and permissionless, with immutable core settlement rules. Each deployment must disclose its external dependencies, configuration permissions, and procedures for handling failures.

6. Independent Frontends and Use Cases

Any developer can connect to VolaSet's contracts and build an interface or application. Multiple frontends can access the same pool, each choosing which assets and features to display.

Frontend operators may charge additional fees, provided they clearly disclose them before the user confirms a transaction. They do not take custody of assets, control pool liquidity, or alter the settlement rules through their interfaces.

If a frontend goes offline, pools and user assets remain onchain. Users can access them through another frontend or interact directly with the contracts. The plan for full release is for independent operators to provide these interfaces, with no official frontend.

Potential uses include:

• Token communities: Create a dedicated pool with settlement liquidity supplied by token holders.
• Wallets and trading products: Integrate volatility settlement into a wallet, trading interface, or dApp.
• Games and community campaigns: Incorporate settlement into a game, campaign, or launchpad.
• Branded frontends: Creators and independent operators can run their own interfaces and earn frontend fees without having to provide liquidity themselves.
• Other applications: Build additional products and integrations within the protocol's supported assets, parameters, and rules.

Mechanics or token issuance arrangements outside the existing settlement rules require separate logic.

7. Fees and Revenue Distribution

Protocol revenue, frontend revenue, and LP profit and loss are accounted for separately.

All protocol revenue goes to the SWING ORBIT Holder Vault for distribution under SWING ORBIT's onchain rules. Smart contracts handle collection, management, and distribution. The team and developers receive no share of protocol revenue.

Figure 2. Fee distribution and LP returns

Distributions depend on actual protocol revenue. No fixed return is promised. Frontend fees and LP settlement gains and losses do not flow through the vault.

8. Risks and Technical Specification

Users may receive fewer tokens than they put in. LP share values and the market value of the underlying token may also fall. Contract bugs, token transfer restrictions, network failures, or external service outages may affect asset security and settlement completion.

Separate pool accounting does not protect against failures in shared contracts or external dependencies. Immutable core contracts do not imply that token contracts or randomness services are also immutable. Verifiable results do not guarantee service availability, and permissionless access does not constitute an endorsement of any token or frontend.

This paper describes the protocol's design. The full technical specification must still define:

• Settlement ranges and probability formulas for each volatility factor, including how Pool Edge is calculated.
• Fee accounting, reserves for pending settlements, and limits on concurrent requests.
• LP deposit and withdrawal rules while settlements are pending, and procedures for handling failures.

These rules must match the final contracts.

9. Multichain Deployment and the Swing Ecosystem

VolaSet can be deployed on multiple blockchains, with separate pools and liquidity on each chain. The same protocol structure can be reused across networks, but liquidity is not shared: a pool on one chain does not back settlements on another.

SwingHook's live usage demonstrated demand for onchain volatility settlement. VolaSet was designed independently in response to that demand, extending the settlement model to standard ERC-20 tokens.

VolaSet does not issue a separate token. Its revenue model is designed to sustain incentives for the SWING token ecosystem: all protocol revenue is directed to the SWING ORBIT Holder Vault and distributed to eligible SWING ORBIT holders under its onchain rules.