George Sarris (0xcircuitbreaker) · · 2 min read
Archived Design Study: Solidus as an Open Perpetuals Network
A historical Solidus design study, updated to reflect the Lucrum rebrand and distinguish proposed architecture from Hyperliquid's shipped network.
In this article
Archive and status note
Solidus is not a current DDG network. The Lucrum monorepo's migration plan records the full rebrand from Solidus to Lucrum Finance on March 22, 2026. This page is retained as a design archive, not an investment comparison, testnet announcement, or statement of available functionality.
The prior version described Solidus as implemented, under test, permissionless, trustless, and capable of approximately 100 ms finality. Those claims lacked public consensus code, network identifiers, an explorer, reproducible benchmarks, deployment records, and independent review. They are now treated as historical design targets.
What Hyperliquid has actually shipped
Hyperliquid's official technical overview describes HyperCore as a fully on-chain order book secured by HyperBFT. It reports approximately 200,000 orders per second on mainnet and, for a geographically co-located client, median end-to-end latency of 0.2 seconds and a 99th percentile of 0.9 seconds. These are Hyperliquid's own current measurements and should be cited with an access date when compared.
Hyperliquid publishes a validator node repository and a delegation program. The program requires 10,000 HYPE in one address to apply, and Foundation validators strongly consider participation when selecting trusted peers. That is a concrete centralization consideration, but it is more precise than the earlier blanket description “closed-source, centrally operated, KYC/KYB-gated.” Source availability and validator composition can change and should be checked at publication time.
The Hyperliquid bridge is not “trustless custody” in an absolute sense. Its official bridge documentation explains the stake-weighted validator signatures, dispute period, cold-wallet unlock process, and audit references. A fair comparison should describe those mechanisms and risks rather than collapse custody into a yes/no label.
What the former Solidus concept proposed
The historical design combined four ideas:
- A 16-chain hierarchy: 1 Prime, 3 Region, and 12 Zone chains
- DAG-based ordering derived from DAGKNIGHT research
- POEM multi-hardware mining across ASIC, GPU, CPU, and mobile/TEE classes
- ForumCore, a proposed on-chain order-matching and margin engine
The intended goal was an auditable, permissionless perpetuals venue with low-latency settlement. No public artifact currently establishes that these components worked together, that anyone could join consensus without approval, that funds were non-custodial under a deployed contract, or that a single mining class could not compromise the system.
The DAGKNIGHT paper analyzes a proof-of-work ordering protocol. It does not validate the Solidus 16-chain hierarchy, POEM weighting, ForumCore, 100 ms finality, or MEV properties. Those would each require their own specification and evidence.
Comparison that can be made responsibly
| Dimension | Hyperliquid | Former Solidus design |
|---|---|---|
| Network status | Production mainnet | Archived concept; no verified public testnet |
| Order book | HyperCore, documented as on-chain | ForumCore proposal; no verified deployment |
| Consensus | HyperBFT, documented and operating | DAGKNIGHT/POEM integration proposed |
| Performance | Officially reported mainnet measurements | No reproducible public benchmark |
| Validator entry | Stake requirements plus Foundation peer-selection dynamics | Permissionless participation was a target |
| Asset security | Documented chain and bridge trust model | Non-custodial settlement was a target |
| Source availability | Node and bridge artifacts public; verify current HyperCore scope | Full-stack openness was a design requirement |
This table deliberately avoids “better,” “fully decentralized,” and “trustless.” Those conclusions require a defined threat model and deployed evidence.
Lessons retained for current work
The useful thesis survives the product name: an on-chain exchange should publish its matching rules, consensus assumptions, custody paths, benchmark methodology, validator-entry rules, and upgrade controls. Claims about openness and performance should be independently reproducible.
Any successor that revisits the Solidus design should publish code and testnet evidence before comparing itself with a production venue. DDG's current protocol direction is described under Lucrum.