# DoubleLiquid Grant Proposal Prepared: May 29, 2026 Proposal path: Open proposal to the DoubleZero Grants Program ## 1. Executive Summary DoubleLiquid is a production-oriented Hyperliquid API endpoint that preserves the official Hyperliquid API surface while routing compatible HTTP and WebSocket traffic through DoubleZero-powered network paths. The trader experience is intentionally simple: change the base API URL, keep the same request bodies, signatures, response formats, SDKs, and operational patterns, and receive lower and more predictable latency to Hyperliquid infrastructure. The latency objective is a 50-70 ms median round-trip improvement for clients in the United States and Asia when they interact with Hyperliquid through DoubleLiquid instead of the official API path. Asia routing is Tokyo-first because Hyperliquid servers are understood to be in Tokyo; DoubleLiquid should avoid Hong Kong or Singapore detours unless route telemetry proves those paths produce a lower end-to-end Tokyo result for a specific client region. Grant request: 60,000 USD equivalent in 2Z tokens, milestone-based and subject to the final grant agreement. The requested grant is a focused subsidy for a 12-week production development and deployment program. It is not intended to fund an ongoing full-time team, replace commercial revenue, or create a long-term maintenance dependency. ## 2. Alignment With DoubleZero Grants The DoubleZero Grants Program funds high-impact projects that strengthen the DoubleZero network, reduce friction for contributors and users, and complement core development. DoubleLiquid fits as an open proposal because it is a concrete, externally owned infrastructure project with measurable user impact: - Strengthens the network: routes real, latency-sensitive trading API traffic over DoubleZero paths and exposes where DoubleZero improves application performance. - Reduces user friction: lets existing Hyperliquid API users adopt DoubleZero performance by switching a URL rather than rewriting bots, SDK wrappers, signing logic, or WebSocket consumers. - Complements core development: focuses on an application-layer adapter, production telemetry, observability, and trader-facing route evidence rather than duplicating DoubleZero protocol work. - Milestone-based: each delivery phase has explicit artifacts, service criteria, and quality gates. - Feasible and focused: initial scope is Hyperliquid REST and WebSocket parity, Tokyo-centered routing, and production onboarding for latency-sensitive users. ## 3. Problem Hyperliquid traders compete on milliseconds. Existing bots already integrate with the official REST and WebSocket APIs for market data, orders, cancels, account state, and fills. For these teams, the biggest adoption barrier for a new low-latency route is integration risk. If a faster path requires new SDKs, new payload schemas, new signing behavior, or a new trading workflow, serious trading teams will postpone adoption. DoubleLiquid removes that barrier by keeping the API contract identical and moving the performance improvement into the network path. The core hypothesis is that DoubleZero can deliver an application-level advantage for geographically distributed Hyperliquid API users, especially when client traffic originates in the US or Asia and must reach Hyperliquid infrastructure in Tokyo. DoubleLiquid turns that hypothesis into a production endpoint with route-level SLOs. ## 4. Product Definition DoubleLiquid is an API mirror and route optimizer for Hyperliquid: - Same official Hyperliquid HTTP paths, including `/info` and `/exchange`. - Same WebSocket subscription and post-message behavior as the official WebSocket endpoint. - Same JSON request bodies, headers where relevant, signatures, nonce semantics, status codes, and response payloads. - Same official SDK compatibility, maintained against the Hyperliquid Python SDK and common direct HTTP/WebSocket clients. - No custody, no private key handling, and no order mutation. - Optional future monetization through builder codes only if users explicitly opt in and sign orders with the builder parameter themselves. Production URLs: ```text https://api.doubleliquid.xyz wss://api.doubleliquid.xyz/ws ``` Example migration: ```diff - https://api.hyperliquid.xyz + https://api.doubleliquid.xyz ``` ## 5. Technical Approach DoubleLiquid is a thin compatibility layer with a strong emphasis on transparency, parity, and operational reliability. ### 5.1 HTTP API Mirror The HTTP proxy accepts the same REST paths used by Hyperliquid clients: - `POST /info` - `POST /exchange` For `/info`, DoubleLiquid forwards request bodies unchanged and returns Hyperliquid-compatible response bodies. For `/exchange`, DoubleLiquid forwards signed actions unchanged. It does not rewrite orders, signatures, nonces, vault addresses, builder fields, or expiration fields because any mutation would break compatibility and create unacceptable execution risk. ### 5.2 WebSocket Mirror The WebSocket layer proxies: - subscription messages - subscription acknowledgements - market data updates - user-specific channels - post-message order flow supported by Hyperliquid WebSockets The implementation preserves server disconnect semantics and documents reconnect expectations. Recovery paths use the corresponding `/info` requests for account and market-state backfill. ### 5.3 DoubleZero Routing The route layer is Tokyo-centered: - US East ingress to Tokyo egress - US West ingress to Tokyo egress - Tokyo ingress for Asia traffic - Tokyo egress adjacent to Hyperliquid infrastructure Because DoubleZero currently supports Solana out of the box, the Hyperliquid route is not treated as a pre-existing default path. This work includes close coordination with the DoubleZero team to enable, validate, and operate the Hyperliquid-specific Tokyo route before production traffic is directed through it. For Asian traffic, Tokyo is the default anchor because Hyperliquid infrastructure is in Tokyo. Hong Kong or Singapore should not be used as first-hop anchors unless production telemetry proves that a specific client region achieves lower end-to-end latency by entering DoubleZero there and riding a faster private path onward to Tokyo. In the default configuration, Asian clients should be routed to the shortest available Tokyo path. ### 5.4 Observability and SLOs The project will ship a public route-status dashboard and production telemetry pipeline. The system will report: - client-to-DoubleLiquid RTT - DoubleLiquid-to-Hyperliquid upstream RTT - official API baseline RTT from the same client location - end-to-end `/info` latency for representative read calls - end-to-end `/exchange` latency where production-safe visibility is available - WebSocket subscribe acknowledgement time - WebSocket message delivery delay where comparable streams are available - p50, p90, p99, jitter, packet loss, timeout rate, and error parity Public claims will be limited to measured production data. The objective is a 50-70 ms improvement for US and Asia clients; route dashboards will show actual route-level results, including routes that do not meet the objective. ## 6. Security and Trust Model DoubleLiquid should not become a trusted trading counterparty. The system is designed around a low-trust proxy model: - Users keep their own wallets, API wallets, and signing infrastructure. - DoubleLiquid never receives private keys. - `/exchange` actions remain user-signed before they enter DoubleLiquid. - Request and response bodies are not modified. - TLS is terminated only where operationally necessary, with strict logging controls. - Sensitive request logging is disabled by default. - Logs use hashes, route IDs, timing, status codes, and payload sizes rather than full signed payloads unless a production user explicitly opts into debug logging. - A kill switch routes traffic back to the official Hyperliquid endpoint if DoubleZero routing underperforms or becomes unstable. ## 7. Builder-Code Monetization Builder codes are not part of the grant-funded launch. They are included only as a future sustainability path. Hyperliquid builder codes require user approval and an optional builder parameter in future order actions. Because `/exchange` payloads are signed by the user, DoubleLiquid cannot and should not inject builder fees invisibly. Any builder-code monetization must be explicit, opt-in, and client-side: - user approves the DoubleLiquid builder address through the required Hyperliquid action; - user configures their bot or SDK wrapper to include the builder parameter; - DoubleLiquid continues to proxy payloads without mutation; - landing page and docs disclose any fee schedule before opt-in. This preserves API parity and keeps the grant-funded scope focused on infrastructure utility. ## 8. Milestones and Success Criteria | Milestone | Timeline | Development and Deployment Deliverables | Success Criteria | Grant Tranche | | --- | ---: | --- | --- | ---: | | 1. Production architecture and route plan | Weeks 1-2 | System design, Tokyo route topology, compatibility matrix, operational SLO definitions | Design reviewed, Tokyo-centered route plan finalized, risk register complete | 6,000 (10%) | | 2. HTTP API parity development | Weeks 3-4 | `/info` and `/exchange` proxy, production configuration, structured timing telemetry | Official SDK can use DoubleLiquid URL for representative info calls and signed exchange actions | 12,000 (20%) | | 3. WebSocket parity development | Weeks 5-6 | WebSocket proxy, subscription coverage, reconnect handling, post-message coverage | Trades/order book subscriptions and reconnect behavior match official endpoint expectations | 9,000 (15%) | | 4. DoubleZero Hyperliquid route deployment | Weeks 7-8 | Work with the DoubleZero team to enable Hyperliquid routing beyond the current Solana out-of-the-box path; deploy US-to-Tokyo and Asia-to-Tokyo paths, failover path, deployment runbook | Hyperliquid-specific Tokyo route enabled with DoubleZero team input, then deployed with p50 improvement on at least two target routes and no higher error rate than baseline | 12,000 (20%) | | 5. Production SLO dashboard and user onboarding | Weeks 9-10 | Public route dashboard, production docs, early user onboarding | Dashboard updates daily, 3-5 users complete URL-swap integration in production-like workflows | 12,000 (20%) | | 6. Hardening, handoff, and grant report | Weeks 11-12 | Security review, load profile, incident plan, final report, next-scope proposal | Final report includes route-level p50/p90/p99, error parity, and production readiness status | 9,000 (15%) | ## 9. Budget Requested grant: 60,000 USD equivalent in 2Z tokens. | Category | Amount | Notes | | --- | ---: | --- | | Core API engineering | 24,000 | HTTP proxy, WebSocket proxy, compatibility coverage, deployment automation | | DoubleZero Hyperliquid route deployment | 12,000 | Coordination with the DoubleZero team to enable Hyperliquid routing, US-to-Tokyo route setup, Tokyo Asia routing, failover path, deployment runbook | | Production telemetry and SLO dashboard | 8,000 | Measurement agents, route-status dashboard, p50/p90/p99 reporting, baseline comparisons | | Security and reliability hardening | 7,000 | Logging controls, failover behavior, load profile, abuse controls, review time | | Production onboarding and grant closeout | 9,000 | SDK examples, onboarding sessions, issue triage, final route report, maintenance plan | This 60,000 USD request is deliberately inside a mid-sized grant range. It is large enough to cover concrete development and deployment work, but small enough to remain a milestone subsidy rather than full-time compensation. If the grants committee prefers a smaller initial launch, a 45,000 USD version would prioritize HTTP parity, US-to-Tokyo routing, Tokyo Asia routing, and a public SLO dashboard before WebSocket expansion. ## 10. Risks and Mitigations | Risk | Mitigation | | --- | --- | | DoubleZero path does not beat official path on every route | Publish route-level data, focus traffic on routes where DoubleZero wins, keep official-path failover | | API parity breaks trading clients | Build against official docs and SDK behavior, preserve payloads without mutation, maintain golden response coverage | | Added proxy hop increases tail latency | Track p50/p90/p99 continuously, route only where DoubleZero wins, expose status page and fail open to official endpoint | | WebSocket disconnect behavior differs from official endpoint | Preserve official reconnect semantics, document recovery behavior, support `/info` backfill patterns | | Builder-code monetization conflicts with drop-in API promise | Keep monetization out of the launch; require explicit user opt-in and user-signed builder parameters only | | Sensitive trading data in logs | Disable payload logging by default; store only timings, status codes, route IDs, and hashed request IDs | ## 11. Maintenance Plan After the grant period, DoubleLiquid will remain usable as production infrastructure with: - compatibility monitoring against official Hyperliquid docs and SDK examples; - route performance monitoring by region; - a public status and SLO page; - documented failover to the official API; - optional paid or builder-code-based sustainability only after explicit user consent and committee feedback. Long-term maintenance is not assumed as part of the grant. The final milestone will include a post-grant operating plan and a recommendation on whether DoubleLiquid should continue as public infrastructure, a commercial service, or a narrower route-reference implementation. ## 12. Source References - [DoubleZero Grants Program](https://doublezero.xyz/journal/introducing-the-doublezero-grants-program) - [DoubleZero whitepaper](https://doublezero.xyz/whitepaper.pdf) - [Hyperliquid info endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint) - [Hyperliquid exchange endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint) - [Hyperliquid WebSocket endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket) - [Hyperliquid rate limits](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/rate-limits-and-user-limits) - [Hyperliquid builder codes](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/builder-codes)