SPREADWORKEnter the desk
SPREADWORK DOCUMENTATION / V0.1

Know the
whole position.

A basis strategy is only as understandable as its accounting. Here is how this one is built.

01 / SPOT VENUE
02 / HEDGE VENUE
03 / SETTLEMENTRequest → Reconcile → Settle
PRE-LAUNCH STATUSDevelopment preview. No vault, project token, staking pool, live NAV, funded account or return history has been connected. This interface does not accept deposits.
01 / OVERVIEW

Two legs. One view.

SPREADWORK coordinates a long spot position on and a short perpetual position on . Matching their sizes aims to reduce directional exposure. It does not eliminate basis, funding, execution or counterparty risk.

These legs exist in separate execution domains. An authorized operator maintains the strategy, while a separate reporter supplies the value of assets held outside the vault. There is no atomic cross-venue hedge.

FIG. 01 / EXPOSURE

When one leg moves, the other responds.

Illustration: $1,000 spot + $1,000 perpetual short, opened at the same price.

Long spot Short perpetual Combined price P&L
Illustrative offsetting price profit and lossAs the underlying price rises, a matched spot position gains and the perpetual short loses the same amount in this simplified example. Their combined price profit and loss is zero. At a 10 percent move, the spot result is +$100 and the short result is −$100. This excludes funding, costs, divergence and execution risk.+$200$0−$200−20%0%+20%Underlying price move
+10%
Spot price P&L+$100
Short price P&L−$100
Combined price P&L$0

Arithmetic, not a return forecast. Real results also include funding, fees, price divergence, imperfect fills, margin and custody risk. These can produce a loss even when the intended exposure is matched.

02 / VAULT LIFECYCLE

A request, then a settlement.

  1. Queue a deposit. The vault transfers the exact stablecoin amount into a reserved balance. Pending deposits are excluded from assets backing existing shares.
  2. Settle. With a fresh NAV report, an operator accepts the request and mints shares at the current share value. Your minimum-share limit must be met.
  3. Deploy and reconcile. Accepted capital can move to the fixed strategy custodian. Spot execution and the hedge happen through the offchain operating process.
  4. Queue a withdrawal. Shares are held in escrow. Settlement burns shares and pays assets only when the vault has available cash and your minimum-asset limit is met.

Owners can cancel unsettled deposits or redemptions. Cancellation is available while paused. Capital already settled into strategy positions cannot be withdrawn instantly.

FIG. 02 / THE CAPITAL LIFECYCLE

A place in the queue is not a deployed position.

  1. 01 / REQUEST

    Reserve assets

    The stablecoin deposit waits separately from assets backing existing shares.

    Pending assets cannot deploy
  2. 02 / ACCEPT

    Issue shares

    Fresh NAV + your minimum-share limit. Accepted assets join the vault.

    Operator settlement
  3. 03 / COORDINATE

    Work both legs

    The operator deploys capital and reconciles spot holdings and the hedge.

    Separate execution domains
  4. 04 / REDEEM

    Escrow, then settle

    Requested shares wait in escrow. Fresh NAV, available cash and your minimum output govern payment.

    Burn shares → pay assets

Before settlement, the owner can cancel a pending deposit or redemption—even while paused. Strategy capital needs time to unwind.

03 / ACCOUNTING

What a share represents.

THE ACCOUNTING IDENTITYVault NAV = liquid asset balance
+ reported strategy value − pending deposits

External value is an operator-dependent accounting input, not a trustless proof of custody. Only the configured reporter can submit it. Reports have monotonically increasing timestamps, a freshness limit and a bounded change between reports; settling requests requires a fresh report.

Report bounds limit ordinary changes; they cannot prove offchain balances are correct. Material changes outside the configured bound require a paused administrative recovery update, which emits an event. Public production access requires independent operational review and an appropriate custody arrangement.

The deployed share token uses 18 decimals; the asset uses its configured decimals. The first deposit is normalized to 18-decimal shares. Later issuance and redemption use proportional NAV.

FIG. 03 / SHARE-BACKED ASSETS

One total. Two sources of value.

Illustrative amounts in stablecoin units. These are not live vault balances.

The onchain balance and the externally reported value have different trust properties. Freshness checks and report bounds do not prove custody or accuracy on another venue.

04 / TOKEN & FEES

Value, recirculated.

The SPREADWORK project token is separate from vault shares. Holding it is not a claim on vault deposits or an entitlement to returns. The token name, supply, fee percentage and allocation must be configured before deployment.

The vault charges its configured performance fee only against returned assets after all outstanding deployed principal and previously recognized losses have been recovered. Those fee assets go to a dedicated fee splitter. Its configured allocation funds a buyback burner; the remaining allocation funds operations.

The burner uses an allowlisted route, bounded quote freshness, minimum output and a deadline. Tokens are destroyed through a compatible burn function or sent to a configured irrecoverable address. Burn receipts remain onchain. Buybacks are dependent on actual fees and available market liquidity.

FIG. 04 / SEPARATE POOLS

Fees, stakes and vault principal have different jobs.

A / PROTOCOL FEES
Realized performance feesOnly after principal and recognized losses recover
Configured fee allocation
Buyback → burnSubject to quotes and liquidity
OperationsRemaining fee allocation
B / PROJECT TOKEN STAKING
User stakesProject token principal
Owner fundsSame-token rewards upfront
Staking poolPrincipal and reward reserves accounted for separately
Unstake principal / claim earned rewardsA reward schedule is not guaranteed APY
VAULT ASSETS STAY SEPARATE

User deposits, reserved pending assets and withdrawal obligations do not fund token buybacks or staking rewards.

05 / PROJECT TOKEN STAKING

A separate stake. A separate balance.

The staking pool accepts the SPREADWORK project token. It does not accept vault shares, hold depositor strategy capital or give stakers a claim on vault assets. Staked principal and accrued rewards are accounted for separately, even though both use the same token.

Once a pool is deployed and enabled, users can stake, unstake principal and claim earned rewards. The owner must fund rewards upfront; a fixed schedule streams that funded amount over time, allocated according to each user’s share of the staked balance. No rewards are created by displaying an APR, and there is no guaranteed APY.

New staking starts paused. Pausing new stakes does not block unstaking or reward claims. The owner cannot withdraw staker principal or rewrite an active reward schedule. Rewards allocated while nobody is staked and reward-rate division dust remain reserved for a future funded schedule; the first staker does not receive a retroactive windfall.

The pool is currently undeployed. Live staking requires a verified project token, a configured staking address, an explicit enable flag and funded rewards. Contract and token risks remain even when principal is unlocked.

06 / OPERATING RISKS

The operating model matters.

Market risk. Funding can turn negative, spot and perpetual prices can diverge, and stock wrappers can lose redemption access. A neutral target is not a guarantee of neutral exposure.

Execution risk. One venue can halt while the other remains open. Orders can partially fill. Bridge latency and margin requirements can force an unwind. positions can be liquidated.

Custody and reporting. The strategy custodian holds capital outside this contract. Operator compromise, inaccurate NAV and venue loss can impair redemptions. Depositors rely on the operator and reporter.

Contract status. Contracts are unaudited. Per project instruction, contract tests have not been run. Compilation does not establish financial safety or readiness for public deposits.

07 / INTEGRATIONS

The connected systems.

network and deployed addresses are explicit environment configuration. The app checks the RPC chain ID and vault bytecode before presenting transaction controls. It does not infer mainnet settings from a reference project.

The official SDK handles account-index and API-key signing. The reconciliation worker reads positions through the account API and produces hedge decisions. Live hedge execution requires a funded account, suitable market, signer, custody transfer workflow and production configuration.

Reading public market data. Network activity, exchange volume, open interest and funding rates describe their source network or venue. They are not SPREADWORK TVL, vault balances, earnings or a strategy return history. A public feed being available does not mean the vault or staking pool is deployed. The app labels the source and observation time; unavailable data is not a zero balance.

Back to the desk ↗