Under the surface.

Overview

The Big Shortfin is a proposed creator-fee-funded short strategy paired with a Solana token, $SHORT. The concept allocates collected fees between a stock-perpetual strategy, holder rewards, and a reserve. Eligible realized net trading profits would then fund AI-assisted $SHORT buybacks.

The intended market basket contains up to ten eligible major U.S.-listed companies. The proposed execution venue is Hyperliquid, using supported equity-referencing perpetual markets, including appropriate HIP-3 markets. This is not ownership of company shares or a brokerage stock-borrow program.

Neither the token price nor holder rewards are guaranteed by the short portfolio. The token does not currently confer an implemented claim on treasury assets.

System status

“Unavailable” is different from zero. Until an account is connected and queried successfully, the dashboard must not display invented balances, orders, P&L, or a live status badge. The tank is currently an illustration.

The stock basket

Ten proposed AI companies

The current research watchlist is NVIDIA (NVDA), Microsoft (MSFT), Alphabet (GOOGL), Amazon (AMZN), Meta (META), Broadcom (AVGO), AMD (AMD), Oracle (ORCL), Palantir (PLTR), and Tesla (TSLA). This curated AI-themed list replaces the earlier general market-cap-ranked universe. It is not a claim that these are the ten largest stocks or that any are currently being shorted.

Explore the company watchlist ↗. Company links describe each business’s AI exposure; they do not establish Hyperliquid market availability. Before any company is admitted to the executable basket:

1. Confirm that a matching equity perpetual exists, is tradable, and has acceptable contract and corporate-action terms.
2. Validate deployer, collateral token, oracle, market hours, funding, margin rules, and settlement behavior.
3. Require sufficient order-book depth, acceptable spreads, current market data, and available open-interest capacity.
4. Publish the selection date, selected constituents, exclusions, and per-company venue mapping.

Target weights are equal: 10% of target gross short notional per eligible slot. If fewer than ten markets pass, leave the missing allocations in cash instead of concentrating them in the remaining names. Review membership monthly; review safety and tradability daily. Entry is conditional on checks passing, not an obligation to trade every day.

HIP-3 markets have deployer-defined contract and oracle settings and separate market infrastructure. An equity reference alone does not establish equivalence to a share or another venue’s contract. HIP-3 documentation ↗

Fee flow and accounting

Let F be newly collected and finalized creator fees, measured in their actual received asset. The proposed allocations are 0.70F, 0.20F, and 0.10F. These percentages apply to creator fees received by the project, not total token trading volume, every fee paid by traders, or forecast revenue. Pump’s applicable fee schedule must be checked at launch. Pump fee schedule ↗

The collector would persist transaction signature, mint, asset, raw amount, decimals, finality, and a unique receipt key. Replaying a receipt must not allocate it twice. Failed or unconfirmed receipts remain pending. Keep native-unit ledgers; USD values require a separate price source and timestamp.

The holder allocation stays in a separate treasury and cannot be pledged as trading collateral. Each operational cost must have an explicit payer: strategy conversion, bridge, trading, and funding expenses reduce strategy resources; approved operating costs may use the reserve. Do not quietly debit reward balances to cover trading losses.

Example, before costs: 10 SOL collected → 7 SOL earmarked for strategy, 2 SOL for holders, and 1 SOL for reserves. This is an allocation example, not current treasury data or an expected return.

Cross-chain funding boundary

A Solana receipt is not a Hyperliquid deposit. A future treasury operator must select and review a conversion and transfer route into the specific collateral asset supported by the selected markets. Each leg needs its own transaction reference, finality rule, fee, slippage check, and destination reconciliation. No bridge provider or automatic route is implemented here. Only confirmed destination collateral may enter the trading budget; in-flight funds are excluded.

Service architecture

Proposed stack: a static website, a server-side TypeScript API, a Python worker using Hyperliquid’s official SDK, PostgreSQL for receipts and state, and a durable queue for scheduled jobs. These are design choices, not services currently running. Official API and SDK ↗

• Fee observer: reads finalized chain events and reconciles them to treasury balances.
• Allocation coordinator: creates immutable allocations and tracks transfers through pending, confirmed, failed, and reconciled states.
• Universe registry: stores company identity, ranking snapshot, DEX name, full market symbol, asset ID, precision, collateral, and approved contract specification.
• Risk engine: produces a versioned order plan or a reasoned no-trade decision.
• Execution worker: submits approved instructions and records per-order outcomes.
• Reconciler: compares intended orders with fills, positions, fees, funding, and account equity.
• Reward indexer: computes eligible holding time independently of the trading worker.
• Public API: serves sanitized observations and provenance; never signs trades.

Separate read-only ingestion, order signing, treasury administration, and public hosting. The browser must never contain a private key, signing secret, or fund-transfer credential.

Hyperliquid integration

Planned adapter, not connected. Public information is queried through POST https://api.hyperliquid.xyz/info. Signed exchange actions use POST https://api.hyperliquid.xyz/exchange. Production activation requires real account setup and independent implementation testing.

Read path

Use the documented dex parameter where applicable. Do not infer a HIP-3 market from a stock ticker alone. Perpetual information API ↗

// Read-only discovery request; no account or signature required.
POST https://api.hyperliquid.xyz/info
Content-Type: application/json

{"type":"perpDexs"}

Resolve asset IDs from current venue metadata. HIP-3 asset IDs follow the documented offset scheme, rather than the ordinary first-DEX universe index; store and revalidate the mapping. Asset ID rules ↗

Order path

Use the official SDK’s signing implementation. A sell order can open or increase a short; a buy with reduce-only intent can reduce an existing short. IOC orders may partially fill; inspect each returned status. A successful HTTP response alone is not evidence of a fill. Client order IDs support reconciliation. Treat network timeouts as unknown outcomes until order state is checked. Exchange actions ↗

Signing and account identity

An approved API wallet signs on behalf of its associated account. Queries must reference the actual trading account, not assume the signing wallet holds the positions. Use fresh signing identities when rotating agents, with an atomic nonce allocator per signer. API wallets and nonces ↗

Streams and backpressure

Market streams can use wss://api.hyperliquid.xyz/ws. The adapter must reconnect, recover missed state, and mark downstream observations stale during gaps. WebSocket guide ↗

Implement weighted REST budgeting, bounded retries with jitter, and a priority queue for cancellations and reconciliation. Respect both IP-level and account-level limits; load current limits during implementation instead of assuming a fixed number of requests is always safe. Rate limits ↗

Daily strategy cycle

Proposed schedule: run an allocation review at 15:00 UTC each day and record either an approved plan or a no-trade decision. New exposure also requires acceptable underlying-market conditions. Weekends, holidays, stale equity oracles, and corporate actions may suppress entries even when a perpetual order book is open.

OBSERVE → RECONCILE → PLAN → RISK CHECK
                             ├─ fail → SKIP / ALERT
                             └─ pass → SUBMIT → CONFIRM → RECONCILE

Any uncertain outcome → freeze new exposure; reconcile before retry

A cycle uses the latest confirmed balances and existing positions. Compute the difference between target and current exposure; do not add another full basket every day. Acquire a lease keyed by account and cycle so that two worker instances cannot run the same allocation concurrently.

Create a durable order intent before submission. Include a unique client order ID and plan hash, record acknowledgements and fills, and reconcile remaining quantity before retrying. Partial fills must update the residual plan. Increasing a short must never be confused with a reduce-only close.

If a market becomes ineligible, stop adding risk and use a reviewed exit policy. Do not silently substitute a crypto asset for an unavailable stock market.

Sizing and risk controls

These are proposed engineering parameters for testing, not validated live risk settings. Start paper testing at 1× gross exposure relative to strategy equity; a ceiling of 2× is a design limit, not a target or promise. Market-specific margin rules may require a lower limit.

E = reconciled strategy equity after costs
N_target ≤ min(L × E, approved absolute notional cap)
N_i_target = N_target / 10 for each eligible basket slot
order_delta_i = N_i_target − current_short_notional_i
tank_fill = clamp(observed_gross_short_notional / published_scale, 0, 1)

Equity includes realized and unrealized results; cumulative fee receipts do not equal current collateral. Funding, execution costs, adverse moves, and withdrawals can reduce equity. Publish the tank’s denominator and separately expose its underlying notional so changing the visual scale does not disguise a change in exposure.

Numerical limits for loss, liquidity, funding, data age, and liquidation buffer must be defined per market and validated before activation. A stop order is not a guaranteed exit price. Canceling orders does not close positions. A treasury short can lose its posted collateral and be liquidated; correlated company exposures can move together.

Holder rewards

Proposed distribution: reserve 20% of collected creator fees for weekly SOL reward epochs, independently of trading P&L. If receipts arrive in another asset, any conversion rule and costs must be disclosed before the epoch opens. No fees means no new reward funding; there is no fixed APY.

weight(wallet) = Σ eligible_token_balance × seconds_held
reward(wallet) = epoch_distributable_SOL
               × weight(wallet) / total_eligible_weight

Use finalized token-account history over a defined seven-day UTC epoch. Aggregate all eligible token accounts by controlling wallet. Exclude a published list of team, treasury, burn, bonding-curve, and liquidity-pool accounts. Do not allocate equal rewards per wallet; splitting a balance across wallets must not increase its combined weight.

Freeze and publish epoch boundaries and exclusion rules before each epoch. Persist boundary balances and replay transfers during the epoch. If data has gaps, delay distribution rather than invent weights. Use integer arithmetic for token units and lamports, deterministic rounding, and an explicit dust/carry-forward policy. If total eligible weight is zero, carry funds forward under the announced rules.

Proposed claim design: publish a reproducible distribution file and Merkle root, fund a dedicated Solana claim account, and require a proof tied to epoch, wallet, mint, and amount. A claim flag prevents double collection. The contract must fix destination ownership and verify funding and authorization. Claim expiry, small-balance thresholds, and unclaimed funds require published terms. The indexer, claim contract, and dashboard do not exist yet.

Example: a wallet with 1% of eligible time-weighted supply receives 1% of that epoch’s distributable pool, before any disclosed claim transaction cost. This is a formula illustration, not a current payout entitlement.

AI-assisted buybacks

Planned extension: eligible realized net profit from the short strategy funds open-market purchases of $SHORT. A bounded AI agent would propose execution timing and order slices; a deterministic policy engine and restricted signer would enforce the budget. This agent and buyback route are not implemented.

Which profits qualify

Only settled, reconciled trading results qualify. Exclude unrealized gains, new creator-fee deposits, reward funds, and borrowed collateral. Deduct realized losses, funding paid (net of funding received), trading costs, and attributable conversion and transfer costs. Losses carry forward: profitable individual trades do not qualify while the strategy remains below its cumulative realized net-profit high-water mark.

P = cumulative realized net trading profit since inception
A = cumulative profit already allocated to buybacks
unallocated_profit = max(0, P − A)
cash_surplus = max(0, withdrawable confirmed strategy cash
                     − required collateral − protected buffer
                     − pending obligations)
new_buyback_allocation = min(unallocated_profit, cash_surplus)

A includes spent and still-reserved buyback funding, so an unfinished purchase cannot be allocated a second time. Return unused funds only through an explicit reversing ledger event. Reconcile outstanding orders and adverse unrealized exposure before releasing cash. Reserve enough for all known transfer and execution costs.

All qualifying surplus can be earmarked for buybacks under this draft, but execution remains subject to limits and market conditions. If there is no qualifying profit or no safe surplus, make no new allocation. Withdrawing cash must not reduce the margin buffer below its approved threshold.

Cross-chain execution

The Hyperliquid adapter handles the stock-perpetual strategy. It does not by itself buy a Solana token. A separate reviewed transfer route and Solana swap adapter must be chosen. The agent must validate the exact $SHORT mint, approved venue/program, token accounts, quote freshness, minimum output, transaction fees, and simulated transaction effects. A ticker string alone is not token identity.

Agent permissions

The proposed agent receives read-only market context, an approved funding amount, route allowlists, and numerical execution limits. Its output is a structured plan: mint, quote ID, input amount, minimum received amount, validity deadline, and rationale. Treat market text and model responses as untrusted; neither may alter policy or signer permissions.

The model cannot increase its budget, select an arbitrary destination, change the mint, withdraw treasury funds, grant token approvals, or bypass human suspension. The execution gate must reject plans exceeding daily or per-order caps, slippage limits, or liquidity-impact thresholds. Numerical limits and custody permissions remain to be finalized and tested.

Use a unique intent ID and record quotes, simulated effects, broadcast signatures, finality, actual token receipts, and fees. A dropped acknowledgement is an unknown outcome; inspect chain state before retrying. Pause on stale quotes, abrupt liquidity changes, route anomalies, inconsistent balances, or exhausted funds.

Purchased tokens and reporting

Default draft policy: purchased tokens go to a disclosed buyback treasury. No automatic burn, holder redistribution, price floor, or supply reduction is claimed. Any later disposal or burn policy requires an explicit published change.

Publish funded, pending, spent, and returned amounts separately, with transaction references and received token quantities. Buybacks are separate from the proposed 20% creator-fee holder pool and are not direct cash rewards to holders. They may occur irregularly, can have execution losses, and do not guarantee a higher token price.

Data model and public API

Proposed records: fee_receipt, allocation, treasury_transfer, universe_version, cycle, order_intent, fill, position_snapshot, reward_epoch, and claim. Each record needs provenance, timestamps, status, and an idempotency key where relevant.

The following response is a schema example for a future GET /api/v1/strategy. This route is not deployed.

{
  "schemaVersion": "0.1",
  "project": "The Big Shortfin",
  "ticker": "SHORT",
  "mode": "design",
  "connected": false,
  "observedAt": null,
  "tradingAccount": null,
  "grossShortNotionalUsd": null,
  "strategyEquityUsd": null,
  "universeVersion": null,
  "positions": null,
  "rewards": {"enabled": false, "fundedEpoch": null}
}

Amounts should use decimal strings in production to avoid floating-point accounting errors. A snapshot must name its venue, account, observation time, and source references. Derived metrics should include formula versions. A client must display unknown values as unavailable, not zero, and use confirmed observations for the public ledger.

Future public endpoints may expose universe membership, allocation receipts, confirmed fills, treasury reconciliations, and funded reward epochs. Public data must omit secrets and sensitive operator metadata. On a read failure, return a stale flag and the last confirmed timestamp; do not advance the timestamp as if a new observation succeeded.

Security and operations

Planned custody model: separate treasury administration from the restricted trading signer. Use hardware-backed or multisignature administration where supported, a server-side secret manager, least-privilege service identities, and explicit signing-key rotation. Validate the actual venue permissions rather than assuming an API wallet can or cannot perform a particular action.

Every allocation configuration, universe update, and signer change must be versioned and attributed. An independent monitor should compare expected balances with chain and venue state, alert on discrepancies, and prevent new orders during reconciliation failures. Keep append-only event logs and tested database backups.

Incident runbook: pause allocation jobs; cancel resting orders where appropriate; evaluate residual exposure; revoke a compromised signer; reconcile transfers and fills; preserve evidence; publish accurate service status. Re-enable trading only after root-cause review and an explicit operator decision. Recovery does not promise a profitable exit.

Review and integration status are tracked in the system-status section. The short strategy is a proposed rules-based allocator. A separate AI-assisted buyback planner is proposed; neither an AI model nor its execution service is deployed. The agent serves a bounded execution-planning role.

Implementation and launch gates

1. Specify: finalize universe policy, market-data provider, supported contracts, collateral route, fee eligibility, reward terms, custody, and numerical risk limits.
2. Build read-only: implement collectors, instrument mapping, account observations, and reconciliation with explicit stale-data behavior.
3. Paper test: replay historical and stressed scenarios; test the ten-slot allocator, skipped names, costs, and daily idempotency.
4. Test integration: use test environments where representative instruments exist; otherwise use a documented simulator. A testnet pass cannot prove unavailable production equity-market behavior.
5. Review: independently review signing, custody, treasury flows, reward contracts, accounting, and disclosures; publish the scope and unresolved findings.
6. Activate deliberately: publish verified addresses, mappings, terms, and operating limits before any separately authorized funding and trading.
7. Observe: connect the public dashboard only after account data and execution history reconcile. Expose real timestamps and evidence links.

Required failure tests

Duplicate fee receipt; duplicate daily job; partial fill; acknowledgement lost after fill; signer nonce collision; stale feed; disconnect and recovery; precision rejection; wrong asset mapping; missing constituent; exhausted margin; bridge delay; corporate-action pause; reward-indexer gap; rounding dust; and repeat claim attempts. Each must have a deterministic safe outcome.

Open decisions remain deliberate blockers to live operation. This publication supplies a technical design and frontend only; it does not deploy financial infrastructure or authorize transactions.