> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/design-decisions-and-proposals/production-readiness-and-fee-integration-v1.md). # Production readiness and fee integration plan Status: planning only\ Reviewed: 2026-07-30\ Execution authority: unchanged; production fees and live trading remain disabled unless separately approved ## Decision NYTSHIFT is **not ready for unrestricted mainnet execution or fee collection**. The safe sequence is: 1. freeze a release candidate and prove the complete PAPER/testnet lifecycle; 2. rehearse backup, restore, reconciliation, emergency stop and rollback; 3. complete legal, compliance, privacy and customer-disclosure review; 4. approve dedicated production authority and venue-specific commercial terms; 5. run tiny, supervised, explicitly capped mainnet canaries; 6. expand only after the evidence pack passes. No platform-fee rate is recommended yet. The existing Hyperliquid 2 bps implementation is a technical candidate, not a commercial approval. It remains fail-closed when no builder address/approval is configured and must be re-approved after the cost and competitor study below. A 0.3% NYTSHIFT fee cannot be used on Hyperliquid perps: Hyperliquid caps perp builder fees at 0.1%. ## Current boundary | Surface | Current product boundary | Commercial boundary | | ---------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | PAPER | Browser/customer-scoped simulation with explicit modeled and unmodeled domains | Any fee is labeled `SIMULATED`; no money is collected | | Hyperliquid | Protected signer/control-plane code exists; automation remains testnet-only; mainnet requires separate gates | Native builder-code support exists in the repository, but production configuration and collection are not authorized by this plan | | Arcus | Public reads plus a disabled-by-default protected boundary | Venue fee tiers are observable; no verified Arcus per-order builder/platform-fee mechanism is integrated | | Lighter | Public read-only integration | No execution or NYTSHIFT fee path | | Robinhood Chain assets | Canonical/read-only market context and chain reads | No execution venue or NYTSHIFT fee path | No private key belongs in the browser, database, agent, customer profile or general web process. No fee route may custody, pool, sweep or transfer customer funds. ## Tier 0 — release freeze and evidence pack * Cut an immutable candidate from a clean commit. Freeze features, dependency versions, schemas, migrations, venue adapters, signer DTOs and production configuration. * Record artifact hash, SBOM/dependency audit, exact environment schema, database migration set, licensed TradingView asset provenance and rollback revision. * Run the full unit, integration, contract, database, signer, security, accessibility and browser suites from the immutable candidate. * Browser-test landing, discovery, terminal, market selector, chart switching, PAPER market/limit/partial/cancel/protection flows, stale/degraded states, account inspection and all empty/error states at desktop, tablet and mobile. * Prove atomic market identity: venue and symbol must agree across URL, chart, book, trades, ticket, risk, receipts and reconciliation. * Freeze if a data claim is misleading, a critical console error is first-party, a migration is not reversible/rehearsed, or any execution gate is permissive by default. Deliverable: signed release evidence index with pass/fail owner, timestamp, commit, artifact hash and linked raw result for every gate. ## Tier 1 — staging and testnet * Operate a production-shaped staging environment with isolated DNS, database, secrets, object/backup storage, alerts and signer processes. * Use dedicated testnet wallets and venue API credentials. Never reuse a production signer, builder address, database, alert secret or eligibility decision. * Run deposit/credit verification, market and limit orders, partial fills, cancellations, TP/SL lifecycle, connection loss, stale book, rejected order, duplicate request, rate limit, signer restart and ambiguous outcome scenarios. * Prove one-attempt idempotency. A timeout or unknown venue response becomes reconcile-only; it is never resubmitted automatically. * Rehearse credential revocation and emergency stop. Prove that risk-reducing cancellation remains available while new entry is locked. * Retain exact PAPER/testnet receipts with source, observed-at time, requested and filled amounts, slippage, venue fee, simulated/platform fee, funding state and reconciliation coverage. Exit evidence: a complete testnet runbook executed by someone other than the implementer, with no unresolved P0/P1 defect and no missing terminal-state reconciliation. ## Tier 2 — production authority and credentials ### Wallet and signer boundaries * Create dedicated production wallets only after a separate security approval. Use different addresses for customer trading authority, NYTSHIFT builder revenue and operator administration. * Keep production signing material in an isolated signer/secret manager with least privilege, filesystem/service-account isolation, rotation, access logging and a documented recovery ceremony. * The web process sends only normalized, policy-bound DTOs over authenticated loopback/private transport. It cannot read or export signing material. * Allowlist exact venue, network, account, market, action type, notional, leverage, fee rate and expiry at both the control plane and signer. * Require distinct people/credentials for deployment, signer policy changes and revenue-wallet administration where the operating team permits. ### Venue credentials and entitlements * Hyperliquid: dedicated API wallet; user main wallet approval for the exact maximum builder fee; live verification of approval, builder account qualification and Standard abstraction mode; separate testnet and mainnet eligibility. * Arcus: user-generated Ed25519 API key registered by the owner wallet; exact account/index scope, market-size attestations, compliance state, alert delivery and emergency cancellation rehearsal. * Lighter: remain read-only until a separate execution design reviews API-key custody, nonce ownership, account tier, rate limits, reconciliation and an officially supported commercial mechanism. * Robinhood Chain: production RPC/provider entitlement, rate limits and chain-health failover; no trading or fee authority follows merely from RPC access. No-go: shared venue keys, browser/local-storage credentials, an agent-held private key, an unapproved builder address, or a generic signer capable of arbitrary calls. ## Tier 3 — data, migration, backup and rollback * Apply checksummed, advisory-locked migrations in staging from a verified production-like backup. * Back up PostgreSQL and every allowlisted execution/reconciliation checkpoint before promotion. Encrypt off-host backups and test restore, not only creation. * Reconcile migration counts, hashes, schema version, referential integrity, ledger balances and opaque customer/account bindings before serving traffic. * Preserve the previous application artifact, environment manifest, migration boundary and service/vhost metadata. Define the exact rollback command and the database compatibility window. * Never roll back by deleting or editing an unknown-outcome record. New code must remain able to read unresolved prior-order evidence. * Run a post-restore reconciliation against venue truth before re-enabling entry. No-go: unverified backup, destructive migration without a tested forward recovery, schema drift, unbounded retention or any secret-bearing backup field. ## Tier 4 — monitoring, reconciliation and incident response Minimum production signals: * market/book/trade/candle source health, age, reconnect count, sequence gaps and reference divergence; * account/portfolio reconciliation age and coverage; * signer health, policy/eligibility expiry, builder approval and fee-configuration parity; * accepted, rejected, unknown and terminal order counts by venue; * unresolved CLOID/client-ID age, partial-fill age and dead-man/emergency-stop state; * database/store integrity, migration version, backup age and restore-verification age; * fee quote-to-fill variance, actual venue fee, actual builder/platform fee, duplicate-ledger rejects and unreconciled revenue; * P95/P99 review, submit and reconciliation latency, rate limits, alert-delivery backlog and service saturation. Alerts must be authenticated, deduplicated and tested across restart. Define 24/7 ownership before mainnet. The incident runbook must cover: 1. stop new entry; 2. preserve identifiers, logs and stores; 3. keep risk-reducing actions available only when their authority is independently safe; 4. reconcile venue truth; 5. notify affected users with factual scope; 6. restore or roll forward from verified evidence; 7. require an incident review before clearing the latch. Unknown outcomes are never retried. Missing data never becomes zero. ## Tier 5 — legal, compliance, privacy and customer terms Before charging or mainnet launch, qualified counsel must review: * operating entity, supported/prohibited jurisdictions and sanctions/AML responsibilities; * whether NYTSHIFT is acting as software provider, broker/intermediary, investment adviser, exchange interface or another regulated role in each jurisdiction; * perpetuals eligibility, leverage and RWA/stock-token restrictions; * fee disclosures, consent, tax/VAT treatment, refunds, complaints and record retention; * venue terms, builder/referral-program rules and marketing/affiliation wording; * privacy notice, lawful basis, processor/vendor terms, cross-border transfers, deletion/export and breach response; * risk disclosures for liquidation, funding, slippage, oracle/data failure, smart contracts, bridges, wallets and irreversible transactions. The UI and terms must say that NYTSHIFT is not Robinhood and is not affiliated with Robinhood unless a written agreement later permits that claim. ## Tier 6 — supervised mainnet canaries * Start with one dedicated, owner-controlled canary account and a tiny amount the owner can afford to lose. * Require an explicit per-canary approval naming venue, network, symbol allowlist, maximum order notional, maximum gross exposure, maximum leverage, maximum daily loss, maximum total fee, expiry and operator. * Begin with one plain order and its cancellation/reconciliation path; add partial fill and protective-order cases only after the preceding evidence is terminal. * Keep automation off. Keep withdrawals/transfers outside the trading signer. * Observe actual venue, funding and builder fees; reconcile every fill and ledger entry before the next canary. * Exercise the kill switch and recovery with no open risk before expanding. Expansion is stepwise. A successful HTTP acknowledgement is not a successful canary; the authoritative fill/order/account lifecycle and ledger reconciliation must be complete. ## Fee taxonomy and customer disclosure Every review must separate: | Cost | Meaning | Immediate total? | | ------------------------------------------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Venue/protocol trading fee or maker rebate | Exchange-native fill charge based on account tier, liquidity role and market | Estimated before signing; actual from fills | | NYTSHIFT builder/platform fee | Venue-supported, user-approved fee for NYTSHIFT | Estimated before signing; actual and separate on receipt | | Funding | Variable carry transfer while a perp position is open | Not part of immediate execution total; show current rate, direction and next interval | | Gas/network/bridge/processor | Chain action or onboarding/withdrawal route cost | Include only when part of the exact reviewed action; otherwise show separately/unavailable | | Slippage/spread | Difference between reference/expected and actual execution | Estimate from fresh depth; actual from fills; it is not a fee | Before any signature, show the NYTSHIFT rate and estimated amount, venue fee range, any gas/route charge included in that action, estimated slippage and the estimated immediate total. Receipts must show actual values separately, plus funding as later carry. Never hide a fee in spread or price. ## Official venue findings ### Hyperliquid Official builder codes are optional per order and apply only to fills. The user's **main wallet**, not an agent/API wallet, must approve a maximum for the exact builder and can revoke it. The official caps are **0.1% on perps** and **1% on spot**; the order field uses tenths of a basis point. A builder must maintain at least 100 USDC in perps account value, and current official account-abstraction documentation says the builder address must be in Standard mode to accrue fees. Hyperliquid also exposes the approved maximum and builder rewards through Info requests. Implications: * reject 0.3% for Hyperliquid perps; * keep the rate venue-specific, exact, config-driven and default-off; * verify user approval and builder qualification at review and immediately before signer I/O; * charge only the venue-reported builder fee on actual fills; * never infer revenue from order acknowledgement, cancellation or incomplete history. Sources: [builder codes](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/builder-codes), [exchange approval action](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint), [fees](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/fees), [account abstraction](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/account-abstraction-modes). ### Arcus Arcus documents a live maker/taker tier model based on trailing 30-day volume and requires clients to read `GET /v1/feetiers` rather than hard-code the schedule. Funding is a trader-to-trader transfer, not an exchange fee. Arcus says it charges no deposit or withdrawal fee of its own; third-party processing/conversion costs are quoted before confirmation. No official Arcus per-order builder/referral/platform-fee field or maximum was verified in the current public order documentation. Therefore NYTSHIFT must not add an Arcus surcharge to the signed order. A separate billing model would require commercial/legal approval and must not silently deduct venue collateral. Sources: [Arcus fees](https://docs.arcus.xyz/concepts/perpetuals/fees), [fee tier endpoint](https://docs.arcus.xyz/api-reference/public/get-fee-tier-table), [funding](https://docs.arcus.xyz/concepts/perpetuals/funding), [onboarding](https://docs.arcus.xyz/concepts/onboarding), [place order](https://docs.arcus.xyz/api-reference/exchange/place-order). ### Lighter Lighter currently documents Standard accounts at 0 maker/0 taker and opt-in Premium accounts with staking-dependent maker/taker fees. The public order-book metadata also supplies fee fields; those live account/market values must remain authoritative. Funding is hourly and peer-to-peer with no exchange fee taken. No official order-level builder/platform-fee mechanism or maximum was verified. NYTSHIFT's current Lighter rail is read-only, so both execution and NYTSHIFT fee collection remain unavailable. Sources: [trading fees](https://docs.lighter.xyz/trading/trading-fees), [account types](https://apidocs.lighter.xyz/docs/account-types), [order-book metadata](https://apidocs.lighter.xyz/reference/orderbooks), [funding](https://docs.lighter.xyz/trading/funding), [API keys and signing](https://apidocs.lighter.xyz/docs/get-started). ### Robinhood Chain Robinhood Chain uses ETH as its native gas token. NYTSHIFT currently uses the chain for canonical/read-only asset context and provider health, not a venue order or fee path. Network gas and third-party bridge/provider costs must be quoted by the exact reviewed route. No NYTSHIFT platform fee may be inferred from RPC access. Sources: [chain overview](https://docs.robinhood.com/chain/), [network connection](https://docs.robinhood.com/chain/connecting/), [terms and fee notice](https://docs.robinhood.com/chain/terms-of-service/). ## Fee architecture requirements Configuration is an allowlist, not a default: ``` venue -> product -> network -> enabled(false by default) -> fee mechanism -> exact rate/cap -> revenue identity ``` * Unknown venue/product/network or missing approval fails closed. * PAPER has a separate simulated schedule and can never satisfy a production fee gate. * The signed ticket binds quote ID, quote expiry, venue/product/network, account digest, order identity, requested fee mechanism/rate, user-approved maximum and total-cost ceiling. * Idempotency keys cover review, submit, venue order, fill, fee recognition and adjustment independently. * The accounting ledger is append-only and exact-decimal. Minimum identity is venue + network + opaque account digest + immutable venue trade/fill ID + fee type. * Record estimated and actual venue fee, NYTSHIFT fee, token, notional and fill quantity separately. * Rejected, canceled and unfilled quantities earn no fee. Partial fills recognize only the actual venue-reported fee for each filled quantity/trade ID. * Duplicate fill delivery changes no balance. Corrections are explicit reversing/adjustment entries; history is never overwritten. * Revenue wallets/addresses require an exact network allowlist and two-person change approval. This plan does not create one. * Reconciliation compares the local ledger with venue-native fill/reward evidence and labels bounded or missing coverage. * If the venue mechanism does not support refunds, customer remediation uses an approved, separately authorized adjustment process; it never causes the trading signer to make an arbitrary transfer. * Logs and support exports contain opaque identities and fixed reason codes, not raw keys, tokens, signatures or customer wallet addresses. Required tests: * no fee for rejected, canceled or zero-fill orders; * correct fee per partial fill and no fee on the unfilled remainder; * maker/taker, rebate, account-tier and venue-product variation; * quote expiry and changed live fee/approval before signing; * missing/stale approval, unsupported venue and cap exceeded; * duplicate/reordered fills and bounded history; * exact-decimal rounding and token identity; * reconciliation mismatch and explicit adjustment; * PAPER always reports `SIMULATED`, never collected; * no custody, withdrawal, sweep or arbitrary-transfer capability in the fee path. ## Cost and competitor study required before setting a rate The commercial owner must produce a dated study with: * infrastructure, market-data, observability, support, compliance, security, accounting and incident-response cost per active customer and per order; * current official venue fees and account tiers; * directly comparable terminal/broker/builder pricing from official competitor pages, with jurisdiction and service-level differences; * maker/taker usage mix, typical notional, partial-fill rate and price elasticity; * subscription versus fill fee versus hybrid scenarios; * user total-cost examples across order sizes and liquidity roles; * conflicts-of-interest analysis and a plain-language value justification. Until that study and legal review are approved, the production NYTSHIFT fee rate is **off**. The existing 2 bps Hyperliquid code value may be evaluated as one scenario, but it is not the recommendation produced by this plan. ## Explicit go/no-go record Production entry is **GO** only when all rows have named evidence and approvers: | Gate | Required evidence | | -------------- | ----------------------------------------------------------------------------------------------------- | | Release | immutable artifact, full regression, clean browser/accessibility/data-truth audit, rollback rehearsal | | Data | live source freshness and degraded-state proof; no fake or unlabeled retained data | | Database | migration/restore/integrity/reconciliation pass and encrypted off-host backup | | Signer | dedicated production authority, exact allowlist, rotation/recovery, no-browser/no-agent key proof | | Venue | current credentials, eligibility, limits, fee schedule and terms reviewed | | Risk | notional/leverage/loss/gross caps, dead-man and emergency-stop rehearsal | | Reconciliation | order/fill/position/funding/fee evidence complete for testnet and canary | | Monitoring | tested alerts, on-call owner, incident drill and no delivery backlog | | Legal/privacy | signed jurisdiction, terms, disclosures, fee consent and privacy review | | Commercial | approved venue-specific rate/config; builder/revenue identity allowlisted | | Canary | tiny supervised mainnet lifecycle terminal and ledger-complete | Any missing row is **NO-GO**. An operator cannot override a failed technical, legal or reconciliation gate with an environment variable. ## Decisions still required from the user/operator 1. Legal operating entity and launch jurisdictions. 2. Whether NYTSHIFT should use subscription pricing, a fill fee or a hybrid after the cost/competitor study. 3. If a Hyperliquid builder fee is chosen, the approved perps rate (at most 0.1%), exact builder address and governance/rotation owners. 4. Dedicated production accounts, wallet/key custody provider and named deployment/signer/revenue administrators. 5. Initial canary venue, symbols, maximum notional, leverage, total-fee ceiling, daily loss and expiry. 6. Alert destination, primary/secondary on-call owners and incident notification process. 7. Backup encryption/location, recovery objectives and retention schedule. 8. Customer support, complaint, refund/adjustment and tax/accounting owners. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://nytshift.gitbook.io/nytshift-docs/design-decisions-and-proposals/production-readiness-and-fee-integration-v1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.