Skip to content
Tangent
ADocumentation

How the desk is built, and what it promises.

The written record behind the numbers: architecture, strategy parameters, payout mechanics and the interfaces that expose them. Every figure on the site can be traced to a rule described here.

A.1

Overview

Tangent is a rules-based derivatives desk issued as a token. The token's own trading activity funds the book, the book trades on-chain perpetuals under fixed rules, and the profit it realises is paid to holders every epoch.

There is no discretionary trading and no treasury to trust. Two systematic sleeves, S-01 Adaptive Trend and S-02 Dispersion Neutral, run autonomously on one account at the Hyperliquid. Positions, exposure, margin and payouts are published while they are open, not after the fact.

The site reads the same account the engine trades. Nothing is aggregated away: the numbers on the desk are the numbers the engine runs on.

Token
TNGT on Base
Settlement
USDCCollateral, P&L and payouts are all denominated in the settlement asset.
Venue
HyperliquidOn-chain perpetuals with a public, keyless read API.
Epoch
7 daysSettled at 00:00 UTC on the epoch boundary.
A.2

Architecture

Five stages, each observable on its own. Capital flows one way; information flows back to the site at every stage.

  1. 01

    Token activity

    Every TNGT trade routes a 3.0% fee to the desk's account. No raise, no vote.

  2. 02

    Collateral

    Fees settle as USDC margin at the Hyperliquid. Margin, exposure and liquidation levels are public.

  3. 03

    Engine

    The two sleeves compute signals, size positions to a volatility budget and place passive orders. Hourly heartbeat, hourly rebalance.

  4. 04

    Realised P&L

    Closed trades become realised profit. Only what the book actually earned can be distributed.

  5. 05

    Distribution

    70% of each epoch's realised profit is paid pro-rata to holders; 30% compounds into the book.

  6. 06

    Publication

    The site and the data API read the venue account and the engine's operator records. Nothing is entered by hand.

A.3

Strategies

Both sleeves are fully specified. Their behaviour can be anticipated from the parameters below; there are no overrides.

S-01

Adaptive Trend

Directional · vol-targeted · Days to weeks

Follows persistent moves in the most liquid, most volatile perpetual markets. It buys strength, sells weakness, and sizes every position so the whole sleeve carries a fixed risk budget rather than a fixed notional.

Ann. vol target
25%
Rebalance
15 min
Lookbacks
1w · 1m · 3m
Gross cap
5.0x
Objective
Capture medium-term trends while keeping realised volatility close to a 25% annualised target.
How it works
Three lookback windows (1w / 1m / 3m) vote on direction each hour. Agreement sets conviction; conviction and recent volatility set size.
Exposure
Net long or net short by design. Gross capped at 5x equity; single-name cap at 15% of gross.
Risk management
Positions exit on signal flip, not on price targets. A −6% daily equity drawdown flattens the sleeve until the next session.
Markets
Crypto majors and high-volatility alts, plus tokenised US equity perpetuals.
Execution
Passive limit orders on the Hyperliquid, rebalanced every 15 minutes; taker fallback only at the session close.
Methodology
Time-series momentum with a funding-rate tilt: crowded carry reduces size, paid carry increases it.
S-02

Dispersion Neutral

Market neutral · dollar balanced · Weekly

Ranks a fixed universe by relative momentum, holds the strongest names long and the weakest short, and keeps the two sides balanced so the sleeve earns from dispersion between assets rather than from the market's direction.

Net exposure
≈ 0
Rebalance
Weekly
Universe
40 names
Per-name cap
8%
Objective
Produce returns with low correlation to the trend sleeve and to the broad market.
How it works
Cross-sectional momentum scores are recomputed weekly; the top quintile goes long, the bottom quintile goes short, weights scaled by inverse volatility.
Exposure
Net exposure held near zero and hedged against the index with perpetuals. Gross typically 150 to 200% of sleeve equity.
Risk management
Per-name cap at 8% of gross, sector caps on equities, and a hard stop when the long/short spread moves −4% in a session.
Markets
Tokenised US large-cap perpetuals and the top-20 crypto assets by liquidity.
Execution
Rebalanced once a week in a single batched session to keep turnover and fees low; partial fills carry to the next batch.
Methodology
12-1 month relative momentum with a short-term reversal filter and volatility scaling.
A.4

Risk framework

Hard limits are parameters of the engine, not guidelines. They are published next to their current readings on the desk.

Leverage cap
5.0x gross / equityThe engine trims the largest positions at the hourly rebalance if the book drifts above the cap.
Vol target
25% annualisedRealised volatility of the P&L series over the trailing month, computed on step returns.
Kill switch
-6% dailyA daily drawdown at this level flattens the book until the next session.
Single name
15% of gross (S-01) · 8% of gross (S-02)
Funding tilt
Crowded carry reduces size; paid carry increases it.
Exits
On signal flip, never on price targets.
A.5

Payout mechanics

Distribution is mechanical. At each epoch boundary the engine settles the epoch and publishes the ledger row before any transfer is made.

Realised epoch profit is the sum of closed P&L over the epoch, net of fees and funding. Unrealised P&L never counts: an open position cannot pay a dividend.

Paid share is 70% of realised epoch profit, distributed pro-rata to every holder at the snapshot block in USDC. The remaining 30% stays in the account as collateral, so the book grows with its own results.

Losing epochs pay nothing and carry no debt forward: the next epoch starts from zero. The ledger records them anyway.

A worked example with a 12,000 USDC realised epoch: 8,400 paid to holders, 3,600 compounded. With 340 holders that is 24.7 USDC per average holder, scaled by balance. See the distribution ledger for the settled epochs.

A.6

Data API

Public, read-only JSON. The same endpoints the site polls. No key, no rate-limit surprises: responses are cached for a few seconds at the edge.

GET/api/fund

Desk snapshot: account metrics, open positions, equity series, distribution and engine records.

GET/api/fund/events

Desk log, newest last: fills, funding, engine heartbeats, payouts and risk lines.

GET/api/fund/distributions

Payout ledger, one row per settled epoch, plus the current distribution record.

POST/api/signals

Strategy submission from the form. Validated, rate-limited, persisted before it is acknowledged.

Schemas are enforced with Zod on every write and documented in lib/schemas.ts. Operator records (engine heartbeat, distributions, snapshots) are published by the engine through a bearer-protected admin API and merged into the public payload immediately.

A.7

Feed states

The pill in the header reflects the real state of the data feed. It is never forced.

LIVE
Snapshot received within the last 150 seconds.
STALE
Last poll failed or the snapshot is older than 150 seconds. Last values are shown, marked.
OFFLINE
Source configured but the venue could not be read at render time.
PRE-LAUNCH
No data source configured. Empty states everywhere, no numbers.