Finality target, not a measurement
p50 < 500 ms
A design target derived from published parameters. Not a measurement of any running network.
SOVEREIGN · A Layer 1 by DagTech
Permissionless mining underneath BFT finality. Post-quantum accounts from genesis.
Every general-purpose chain in production makes you choose: fast deterministic finality with a bonded or permitted producer set, or open permissionless mining with probabilistic confirmation. Sovereign is engineered to compose both — proof-of-work block production and merge-mined external anchoring beneath a BFT finality gadget targeting p50 under 500 ms and p99 under 1 s — because the customer arriving next, the autonomous machine, cannot treat settlement as a step in its plan.
Presale not open. Nothing on this site accepts payment. Registration reserves allocation priority only.
Every component of this architecture has been demonstrated independently in production systems. The composition has not. Sovereign is an active research programme with published targets, published parameters and published open problems. Latency figures on this site are design targets, not measurements.
Presale opens —. Registration is free, non-binding and confers no right to purchase.
Presale opens in
Counting down to the published presale open timestamp.
—
Design targets
Finality target, not a measurement
p99 < 1 s
The honest bound. A percentile is stated in every latency figure on this site.
Post-quantum account scheme, day one
Genesis
Keys created at genesis do not need migrating later.
We are building for a customer who has not arrived yet, and who will not wait when it does.
Built by DagTech
Who is behind this
DagTech builds Sovereign.
Sovereign is engineered by DagTech, an infrastructure operator running production proof-of-work mining, pool and explorer infrastructure. We are naming the builder because a Layer 1 that will not tell you who is responsible for it has told you something.
Accountable entity
Registered entity name, jurisdiction and registration number are published in the corporate structure memorandum and are filled here from that document. They are not stated from memory.
Regulatory posture
Sovereign's token distribution is structured under a published framework. Restricted jurisdictions are listed in full at the jurisdictions page rather than summarised. The European Economic Area is excluded operationally, at the point of registration.
Audit posture
0 complete
No third-party audit is complete. This line will name the auditor and publish the report in full, including unresolved findings, when one is.
Security disclosure
Vulnerability reports go to the published security contact. Policy, scope and response times are published with it.
What we will not do
Four refusals, and the consequence of each. They are here rather than in a legal footer because they are a position, not a disclaimer.
01
No figure we cannot reproduce from published parameters.
Some of our numbers are less impressive than our competitors'. That is the trade.
02
No unqualified universal negative.
We will not tell you something is impossible. We will tell you what it costs an attacker.
03
No ROI projection that is not labelled a projection.
We will not show you a price slider.
04
Weaknesses published, not buried.
The proven-versus-research section of this page is the list.
Coming soon
Registration is open. The presale is not.
Whitelist registration reserves your place in the queue and nothing more. It is free, it is non-binding, it does not require a wallet connection, and it does not confer any right or obligation to purchase SOVL1. When the presale opens, registered addresses are notified first and receive the participation window described in the presale terms document.
Your details validated. Nothing was sent.
This page has no backend. Your entry was checked in your browser and written to the browser console; it has not been transmitted, stored, or queued, and no position has been issued. When the registration endpoint is connected, this same screen shows your queue position and a timestamped receipt you can verify.
What happens next, once the endpoint is live
-
Now
Your registration receipt, with a verifiable timestamp.
Issued by the registration service. It is not issued by this preview.
-
Within 48 hours
The technical brief and the current weakness register.
-
—
The full parameter set and benchmark harness, 14 days before public release.
-
When the presale opens
You'll be contacted in queue order. We will email you whether it opens on schedule or not.
We will never ask you for money, a wallet signature, or a seed phrase. Not now, not ever.
Tell us what to send you
Two more questions so we send you the right documents instead of all of them. Skip if you'd rather — it won't affect your position.
What happens next
Four things, each finite, each true. The scarce goods here are allocation priority and information priority — not price.
-
One
Documentation, 14 days before public release.
The parameter set, the benchmark harness, the audit scope and the technical brief. The window is honoured to the day, and the public release actually happens.
-
Two
A place in a queue that determines onboarding order.
Ordered by registration timestamp and issued as a verifiable receipt. Position determines onboarding order — nothing else.
-
Three
Inclusion in a capped early-access tranche whose size is published.
The cap exists because compliance onboarding capacity is genuinely finite, and we would rather cap the programme than onboard badly.
-
Four
The ability to ask questions that get answered.
The questions from this form drive what we publish next.
What you do not get
A guaranteed allocation, a discount we have not defined yet, or any assurance the presale will open at all on the date we currently expect. If any of those matter more than the four things above, do not register yet.
Registrations confirmed
Not shown
The counter reads from the registration database and updates on write. It does not increment on a timer. Until that endpoint is connected no number appears here — a generated registration count would be fabricated social proof, and we would rather show nothing.
Indicative allocation tiers
Tiers are indicative and subject to change. Registration confers no allocation, no priority, and no entitlement.
Tier 01
Founding
Onboarding order is by registration timestamp. Terms are published in the presale terms document before any window opens.
Tier 02
Early
Same terms, later position. Registering earlier does not yield a better price. It never will.
Tier 03
Standard
One tranche, one queue, one set of terms, published.
Tier 04
Public
Opens after the early-access tranche closes on its published date. If that date is extended, we publish why before the original date passes.
Architecture
Five layers. One sentence each.
The differentiator is not any single layer. Four of the five exist elsewhere. The claim under test is that they hold together.
Production — who is allowed to make blocks
Anyone with a machine and electricity. Proof-of-work, permissionless, no bond, no allowlist, no application.
Anchoring — how the record resists being rewritten
Sovereign's block headers are merge-mined into an established external proof-of-work chain, so rewriting Sovereign history means paying to rewrite that chain's history too.
Finality — when a payment stops being reversible
A BFT committee commits blocks under an explicit fault threshold. Once committed, a block does not reorganise unless that threshold is exceeded.
Accounts — how ownership is proved
Post-quantum signatures available from genesis, so keys created today do not need migrating later.
Execution — what the chain actually runs
The execution environment named in the Architecture section of the whitepaper, so existing tooling ports rather than being rewritten. The environment is a published parameter and is filled here from that document rather than described.
Layer 1 buys openness. Layer 2 buys durability. Layer 3 buys speed. Layer 4 buys time. Layer 5 buys adoption. The engineering question — the whole question — is whether 1 and 3 can share a chain without one weakening the other. That question is open, and we say so in the proven-versus-research section.
The regulatory clock
Nobody is asking for this yet. That is precisely why we shipped it at genesis.
We will not pretend there is demand for post-quantum accounts today. There is not. No customer has asked us for one, no competitor is losing deals over the gap, and any site telling you otherwise is selling you a fear it does not hold itself.
What exists instead is a schedule. NIST IR 8547 sets the transition path for classical public-key cryptography: deprecated after 2030, disallowed after 2035. That timeline governs US federal systems and, through procurement and audit practice, a great deal of what touches them. It is a published document with published dates. It does not depend on anyone's forecast of when a cryptographically relevant quantum computer arrives.
The engineering consequence is narrow and specific. Signature schemes are not a patch. An account created under a classical scheme is a liability that has to be migrated — coordinated, socially, across every holder, on a live chain, under a deadline. Chains that begin post-quantum do not have that migration ahead of them. Chains that do not, do.
Sovereign supports the NIST-selected post-quantum signature schemes named in the Cryptography section of the whitepaper from genesis. Classical schemes remain available for compatibility; the migration path in either direction is specified in the Cryptography and Post-Quantum Migration document.
This is a bet on a calendar, not on a threat model. We hold it because the calendar is published and the cost of holding it early is low. If the schedule moves, our reasoning moves with it, in public.
Some engineering is done for the year it is needed, not the year it is noticed.
NIST IR 8547 transition
- Classical PKC deprecated
- after 2030
- Classical PKC disallowed
- after 2035
- Sovereign PQ accounts
- genesis
A published external schedule, not a forecast of our own. Source: NIST IR 8547.
The binding constraint
One transaction is not the problem. Twenty in a row is.
Latency debates on chain sites usually compare a single transaction, which is the wrong unit. An autonomous agent rarely settles once. It settles, reads the result, decides, and settles again — a chain of dependent calls where each one must be final before the next can be formed. Confirmation latency does not add to the workload. It multiplies against the depth of the chain.
Twenty dependent calls is a modest agent workflow: source a quote, verify a counterparty, escrow, release, reconcile, repeat.
How Sovereign compares
Bar chart of total settlement time for twenty chained dependent calls. A chain confirming in twelve seconds takes 240 seconds. The same chain using an observed mean inclusion-to-confirmation of 12.9 seconds takes 258 seconds. Sovereign at its p50 design target takes 10 seconds. Sovereign at its p99 design target takes 20 seconds. The two Sovereign bars are design targets, not measurements.
Solid = measured third-party systems.
Outlined = Sovereign design target, not measured.
| Settlement layer | Per-call cost | 20 chained calls | Basis |
|---|---|---|---|
| A chain confirming in 12 s | 12 s | 240 s — 4.0 minutes | Defined |
| Same, using observed mean inclusion-to-confirmation | 12.9 s | 258 s — 4.3 minutes | Defined |
| Sovereign, at the p50 target | 500 ms | 10 s | Projected |
| Sovereign, at the p99 target | 1 s | 20 s | Projected |
Observed mean inclusion-to-confirmation is filled from the source cited in the Latency and Sequential Composition document. It is not estimated here.
Finality, p50 target
< 500 ms
Design target derived from published parameters.
Finality, p99 target
< 1 s
The bound we publish alongside every median.
Block interval
—
A design target for block cadence, taken from Whitepaper v4.0. It is a production parameter, not a finality figure, and is never presented as one. Nothing has measured it yet.
Published risk
The components are demonstrated. The composition is a research programme.
Most chain sites publish what works. This section exists because our charter requires us to publish what does not yet, and because we would rather you find our open problems here than find them yourselves later.
That sentence is from our own technical documentation. We put it on the front page instead of page 41. Here is what it means for you, specifically.
Demonstrated in production systems
DefinedPermissionless proof-of-work block production, at scale, for over fifteen years.
Merge-mined anchoring of a secondary chain into an established proof-of-work chain.
BFT finality gadgets committing blocks under an explicit fault threshold in live networks.
NIST-selected post-quantum signature schemes, standardised and implemented.
The execution environment named in the whitepaper, in production across many networks.
Not demonstrated, under active work
ProjectedThe composition itself. A permissionless, unbonded producer set feeding a bonded BFT committee at sub-second cadence has not been operated at scale by anyone, including us.
Committee liveness against adversarial production. Open production means the committee cannot assume well-behaved proposers. Our mitigations are specified; they are not proven.
Latency targets under real network conditions. p50 under 500 ms and p99 under 1 s are design targets derived from published parameters. They are not measurements, and we will not present them as measurements before we have them.
Merge-mining cadence against fast finality. External anchoring is slow by construction. How anchoring depth interacts with a fast finality path across the interval between anchors is an open question we specify rather than assert.
Post-quantum signature cost at target throughput. Larger signatures cost bandwidth and verification time. The budget is published; the headroom is not yet demonstrated.
We publish attack analysis, negative results and post-mortems in the research library, including work that did not go our way. Testnet metrics, when a testnet is live, are published as measured — with methodology, hardware and network conditions attached — and are never blended with target figures.
A specification that hides its open problems is not a specification. It is a brochure.
Registrants receive the full parameter set and the benchmark harness 14 days before public release.
Register for Early AccessPreview
Network Preview
DAG structure
| Height | Block | Parents | Timestamp | State |
|---|
Network health
Targets are stated as targets. Where a value is a design target rather than an observation, the tile says so.
Recent testnet blocks
Five rows, capped. When the testnet feed is connected this component switches to real testnet blocks and the badge changes with it.
Node distribution
Node distribution
Testnet hashrate
—
Sparkline covers the last 24 hours at hourly resolution.
SOVL1
Supply, allocation and the schedule that governs both.
The hard cap, both emission pools and the presale and public distribution are published parameters taken from Sovereign Whitepaper v4.0 §6.1 and its supply table, and are badged DEFINED. The remaining 40,000,000,000 SOVL1 — community, liquidity and team — is not yet published: it appears as a single unallocated segment marked §, and its breakdown is pending the Tokenomics document. Nothing on this page is a forecast of price.
Ticker
SOVL1
Maximum supply
—
A hard cap enforced in consensus. It is not a governable parameter.
Genesis supply
—
Whitepaper v4.0 does not state a genesis supply, so no number appears here. A figure invented to fill this tile would be indistinguishable from a published one, and we would rather show nothing until the Tokenomics document states it.
Fee policy
—
Whitepaper v4.0 does not state a burn or redistribution split. This tile stays empty until the Tokenomics document states one explicitly.
Supply and allocation
Solid segments are published: 20,000,000,000 SOVL1 to the validator emission pool, 5,000,000,000 to the miner emission pool and 35,000,000,000 to presale and public distribution, against a hard cap of 100,000,000,000 SOVL1 (Sovereign Whitepaper v4.0 §6.1 and supply table). The hatched and outlined segment is the remaining 40,000,000,000 SOVL1 — community, liquidity and team. Its breakdown is pending the Tokenomics document and is not shown here because it has not been published.
Emission schedule
Outlined and hatched = modelled forward projection, not an observation.
A(n) = A₁ × 0.9^(n−1) geometric, published in Whitepaper v4.0 §6.1 cumulative(n) / pool = 1 − 0.9^n converges exactly on each pool, no terminal cliff year one = 10% of each pool = 2,000,000,000 SOVL1 to validators, 500,000,000 to miners split = 80 / 20 validators to miners Rewards are distributed per reward epoch of approximately 24 hours, pro rata to finality-vote participation, not per block.
Unlock schedule
| Bucket | Share | Cliff | Vesting and release | Enforcement |
|---|
Dilution, from your side
Token allocation describes distribution, not value. SOVL1 has no price history, no guaranteed listing, and no mechanism in this document that supports any particular price. Any return figure you encounter about SOVL1, from us or anyone else, is a projection and should be treated as one.
A presale participant's proportional holding falls every time emission is paid or a locked bucket unlocks. That is arithmetic, not opinion: 25,000,000,000 SOVL1 is emitted to validators and miners over the life of the geometric schedule, and a further 40,000,000,000 sits unallocated against the cap. The same number of units becomes a smaller share of circulating supply as each is released. The unlock table above is the schedule on which that happens for the published buckets. The release schedule for the unallocated 40,000,000,000 has not been published, which means the dilution it implies cannot be calculated yet — read it the day it is, and read it again on the date the first cliff falls.
No price target appears anywhere on this site. Any figure you have seen elsewhere that projects a SOVL1 price is not from us.
Production and finality
Participate
Three tracks. Two calculators that compute from parameters you can see and edit. Every output on this page is a projection, and every projection says so.
Participation tracks
The committee that commits, and what it stands to lose.
Miners produce blocks. A BFT committee makes them final. The two roles are separate by design: production stays open so that no one can be excluded, and finality is committed by a bonded set so that the commitment carries a cost if it is broken.
Staking on Sovereign is that bond. It is not a savings product and it is not a yield instrument. It is collateral posted against correct behaviour, and it is slashable.
Rewards move inversely with participation. Raise this and watch the yield fall. Whitepaper v4.0 §6.1 plans for a band of 31–38%, centred on 35%, which is the default here. Bonded stake is measured against the 100,000,000,000 SOVL1 hard cap.
Network assumptions
Result
Projected reward over the period
—
Net of validator commission and downtime, before any slashing event.
Projected annualised rate
—
Projected ending balance
—
Projections are not promises. Staking rewards shown anywhere on this site are projections derived from the published parameters shown beside them and the participation rate at the time of calculation. Participation changes, and rewards move inversely with it.
Two published constraints that materially affect you. Unbonding takes a minimum of 14 days: a bond cannot be exited on demand, and it remains slashable while it unwinds. In-protocol delegation is banned at launch, with a formal revisit at 12 months — you cannot delegate to a validator, so this calculator models a bond you operate or that is held on your behalf outside the protocol. Slashing is a 5% base for equivocation, scaled by correlation, and an invalid finality certificate is penalised in full. Those penalties apply identically to stake bonded from a vesting allocation.
Staking opens at mainnet.
Published economics — all figures below are protocol parameters, not estimates
| Parameter | Value |
|---|
No bond. No allowlist. No application.
Block production on Sovereign is open proof-of-work. If you have hardware and power, you are already qualified.
Cost of entry, not cost of stake
A bonded validator set concentrates production among those who already hold the asset. Proof-of-work prices entry in hardware and electricity — inputs that exist outside the token and cannot be accumulated by holding it.
An external anchor
Merge-mined anchoring means Sovereign's history inherits the reorganisation cost of an established external proof-of-work chain. An attacker rewriting Sovereign is buying hashpower on a market they do not control.
Permissionlessness that survives the operator
There is no admission process to capture, no bond to price out small operators, and no committee that can decline your blocks because of where you are.
A production set nobody curated
Who mines is an outcome, not a roster. Hashrate distribution and producer counts appear on the network dashboard and are drawn from chain data only.
This section does not claim Bitcoin-equivalent safety, proof-of-work-grade safety on the fast path, or that proof-of-work makes Sovereign secure. Proof-of-work governs production and anchoring. Finality is governed by the BFT layer, under its own stated fault threshold. These are separate guarantees with separate assumptions and the site never merges them.
Difficulty rises as hashrate arrives. Raise this and watch the return fall.
Defaults to zero, deliberately. SOVL1 has no price history and no guaranteed listing. This field converts a coin-denominated result into currency using an assumption you supply; it is not a price forecast, and there is no price target anywhere on this site.
Network assumptions
Result
Projected block reward share, per day
—
Projected electricity cost, per day
—
Projected net, per day
—
Projected break-even
—
Any yield figure shown in the mining calculator is a projection computed from inputs you supply — your hashrate, your power cost, your uptime — against network parameters that change with difficulty and price. Projections are not promises. The calculator publishes its formula. Difficulty and network hashrate inputs are read from chain data when the adapter is connected.
Hardware comparison
| Class | Hashrate | Draw | Efficiency | Indicative cost |
|---|
Miner economics — protocol parameters
| Parameter | Value |
|---|
The right to produce a block should be bought with work, not with position.
Published requirements, before you commit hardware.
Hardware, bandwidth and storage requirements are published as measured on the reference build. Where a figure has not been measured yet, it is marked rather than guessed.
| Role | CPU | Memory | Storage | Bandwidth |
|---|
Storage and bandwidth growth
State growth is a function of block interval, block size and the post-quantum signature budget, all of which are published parameters. Larger signatures cost bandwidth and verification time; that cost is in the budget and the headroom is not yet demonstrated. Plan capacity against the published growth model rather than against a snapshot, and re-check it after each parameter change.
Onboarding, four steps
Step one
Provision against the published requirements above.
Step two
Install the reference build and sync the public testnet.
Step three
Verify your node against the published health checks.
Step four
Register node interest so we can reach you when the validator programme opens.
Register node interest
Registering as an operator routes you to the hardware requirements, validator economics with exact numbers, and testnet participation instructions — not the general list.
Register as an operatorBuild
Familiar tooling. Unfamiliar latency budget.
Sovereign runs the execution environment named in the whitepaper, so the contracts, libraries and test frameworks you already use port across. What changes is the assumption underneath your code: you can stop designing around confirmation delay.
Most on-chain applications are shaped by a latency constraint their authors stopped noticing — optimistic UI, pending states, batching, off-chain sequencing to hide the wait. On a sub-second finality target, chained on-chain calls become a design option rather than a thing to route around. That is the interesting part of building here.
Network details
Testnet only. Testnet SOVL1 has no value and will not be migrated.
Quickstart
-
1 · Install the node
# Requires the release channel published in the node operations document. curl -fsSL https://get.sovereign.network/install.sh | sh sovereign --version -
2 · Join the public testnet
sovereign init --network testnet sovereign start --rpc.enabled --rpc.addr 127.0.0.1:8545 -
3 · Create a post-quantum account
# The scheme name is a published parameter; see the cryptography document. sovereign account new --scheme pq sovereign account list -
4 · Settle a chain of dependent calls
for i in $(seq 1 20); do sovereign tx send --to $COUNTERPARTY --value 1 --await-final done
Commands are shown against the reference build. Where an API is not yet stable, the documentation says so on the page, not in a changelog you have to go and find. Endpoints resolve once the testnet parameters above are published.
SDKs
Only SDKs that exist are listed. When a language binding ships, it appears here with its install command and its stability marker.
Development activity
Recent commits
Commit activity, contributor counts and repository history are published live from the public repositories. We would rather show you who is actually working than show you a wall of logos. Until the repository endpoint is connected, this component shows a simulated preview of that feed and says so.
Documentation
Architecture, API reference and guides, versioned alongside the release channel.
API reference
RPC methods, subscription topics and error semantics.
Bug bounty
Scope, severity tiers, payout bands and response times, published before the first report arrives.
Grants
Programme size and how to register interest. The application flow ships when there are recipients to name.
Status
Uptime history including the downtime. A perfect graph on a young testnet reads as fake.
llms.txt and agent skills
The veracity taxonomy used on this page is published in machine-readable form, so an agent summarising this site inherits the labels rather than stripping them.
Demand
Ecosystem
Case studies appear here when there is a named counterparty, a quantified claim and a verification link. Until then this section carries what is genuinely knowable: which wallets will work, and what the grants programme is.
Case studies
No case study meets the publication bar yet.
Every quantified claim on this site carries a source link or the number is removed. A case study whose counterparty will not be named ships as a sector-anonymised card with the claim intact and an explicit counterparty under NDA chip — anonymity disclosed is fine; anonymity concealed is not. None currently qualifies, and a directory of placeholder cards is worse than none.
No customer logo appears on this site unless that customer has signed a written agreement permitting it and the relationship is described accurately in the same block. No advisory logo appears without a named individual and a stated role.
Wallet compatibility
| Wallet class | Custody | Testnet support | Hardware key support | Status |
|---|
Grants
The programme's size and its status are published in the grants document. The application flow ships when there are recipients to name; the directory of recipients ships with them, not before.
Evaluating SOVEREIGN professionally? There is a separate process, a data room, and a named contact. Request data room access
Plan
Roadmap
Targets, not commitments. Dates move; we publish when they do.
Foundation
Complete- · Architecture specified and published.
- · Charter adopted: no figure we cannot reproduce from published parameters.
- · Weakness register opened and versioned.
- · Comparative screen criteria published.
Testnet
In progress- · Public testnet, faucet and RPC endpoints published.
- · Benchmark harness published so results can be reproduced.
- · Latency measured and published with methodology, hardware and network conditions.
- · Third-party audit scope published before an auditor is engaged.
- · Early-access registration open. No payment accepted.
Mainnet
Planned- · Audit report published unredacted, including unresolved findings.
- · Presale terms and receiving contract published before the first transaction.
- · Genesis with post-quantum accounts available from block zero.
- · Staking and slashing live under the published fault threshold.
Expansion
Planned- · Merge-mining cadence tuned against measured finality.
- · Grants programme opened with named recipients.
- · Governance moved to the published on-chain process.
- · Commitments ledger published: kept, late, changed, missed.
Status chips fall back to configuration values when the status feed is unavailable. Missed items stay on the page permanently with an explanation rather than being quietly removed.
Accountability
Team and governance
A Layer 1 that will not tell you who is responsible for it has told you something. Anonymous leadership is incompatible with taking presale funds and with any institutional conversation, so it is not an option here.
Core team
Team disclosure is scheduled.
It will name individuals, not roles: real names, photographs, and an external profile for each — GitHub, ORCID or Google Scholar, prior shipped systems, LinkedIn. Every link points somewhere we do not control. Where the team is light we will say so and say who is advising on that gap. A named gap is survivable; a discovered omission is not.
No advisory logo appears without a named individual and a stated role. Council-style credibility stacking with unnamed institutions is not permitted.
Advisors
Listed at reduced prominence, by name and stated role, on the same disclosure date as the core team.
Governance
Two questions decide a governance model: who decides what today, and who decides what at mainnet. Both are answered in the governance document rather than summarised into a diagram here.
| Decision | Today | At mainnet |
|---|---|---|
| Protocol parameters | DagTech engineering, published with the change | On-chain process defined in the governance document |
| Treasury deployment | Named entity directors, with use-of-proceeds published | On-chain process, with published minutes |
| Weakness register status | Engineering, versioned and dated, externally raised items credited | Unchanged. It is a record, not a vote |
| Emergency response | Published incident procedure and security contact | Published incident procedure, with post-mortem |
Governance document
Who decides what, on what evidence, and how a decision is recorded.
PDFThe accountable entity
Registered name, jurisdiction, registration number, registered address, named directors and regulatory posture are stated plainly in the corporate structure memorandum, not in a footer.
Primary sources
Read the documents. The site is downstream of them.
This page is a summary. The documents are the product of record, and where the two disagree, the documents win. Everything below is versioned, dated and downloadable in full.
No documents in this category yet.
Any competitive claim on this site is backed by the Comparative Screen, and the screening criteria are published with it. We do not make unqualified universal negatives. Where we say we found no chain composing both properties, we mean: under those criteria, across that set, on that date.
Register for Early Access
Free, non-binding, no wallet, no payment. It reserves your place in the queue and gets you our documentation before it goes public.
Your details validated. Nothing was sent.
This page has no backend. Your entry was checked in your browser and written to the browser console; it has not been transmitted, stored or queued, and no position has been issued. When the registration endpoint is connected, this screen shows your queue position and a timestamped receipt you can verify.
We will never ask you for money, a wallet signature, or a seed phrase. Not now, not ever.
Presale opens in
—
Verified channels
Sovereign communicates only from the official domain and the channels listed in the footer. We will never send you a wallet address by direct message, never ask for a seed phrase or private key, and never open a purchase window on any other domain. Check the address bar.
Twelve questions, including the ones we would rather not be asked.
No — and speed is not the claim. Fast chains exist in quantity. What does not exist, under the criteria in our Comparative Screen, is a chain that keeps block production permissionless and unbonded while committing finality in under a second. The composition is the claim. Speed is a consequence of it.
The components have. The composition has not. That distinction is important enough that it has its own section on this page, with a list of the specific things we cannot yet demonstrate. Nothing about Sovereign should be described as proven, including by us.
How data on this page is labelled. Every data component on this site declares where its numbers came from, and the badge is set by that declaration rather than written by hand. Live is real-time data from a production endpoint. Testnet is a real measurement from the public testnet, which is a real chain but not mainnet, and whose tokens have no value. Preview — simulated is generated data illustrating the intended interface; it is not a measurement of any network. Projected is forward-looking model output, not an observation. Defined is a parameter fixed in published documentation. The same taxonomy is published in machine-readable form so that an agent reading this page inherits the labels.
No, and we will not make that comparison. Bitcoin's security comes from fifteen years of accumulated proof-of-work under one set of assumptions. Sovereign's fast path is secured by a BFT committee under a stated fault threshold, with merge-mined anchoring providing external reorganisation cost over longer horizons. Those are different guarantees. Anyone offering you proof-of-work-grade safety on a sub-second path is describing something that does not exist.
p50 under 500 ms and p99 under 1 s. Both are design targets derived from published parameters, not measurements. When we have measurements they will be published with methodology, hardware and network conditions, and they will be labelled as measurements. Block interval is a separate parameter and we never present it as finality.
Because nobody is asking for it, and because the schedule is already published. NIST IR 8547 deprecates classical public-key cryptography after 2030 and disallows it after 2035. Signature schemes cannot be patched in; changing them on a live chain is a coordinated migration of every holder. Beginning post-quantum costs us a little now and avoids that migration entirely.
Today, largely yes. Autonomous machine-to-machine settlement is a market signal, not a moat, and we hold it as such internally. What is not narrative is the arithmetic in the sequential composition section: chained dependent calls multiply confirmation latency, and that is true whether the caller is an agent, a market maker or a settlement system.
Committee members commit blocks; they do not produce them. Production is open proof-of-work, so a censoring committee cannot prevent your transaction from being included in a block. The committee's power is over finality timing, bounded by the fault threshold and priced by slashable bonds. The full analysis, including the cases where this argument is weakest, is in the research library.
Because the economics are published rather than described, and because merge-mining means the anchoring work is not exclusive to us. Run the numbers with your own power cost in the calculator, which shows its formula. If the numbers do not work for you, they do not work, and no amount of copy on this page should change that.
No. Registration is live; the presale is not. Registering is free, non-binding and grants no right to purchase. When a purchase window opens it will be announced on the official domain and on our verified channels only. Anyone offering you SOVL1 before then is defrauding you.
We do not know, and neither does anyone telling you they do. SOVL1 has no price history and no guaranteed listing. Every yield or return figure on this site is a projection generated from inputs you supply and parameters that change. Projections are not promises. You should be prepared to lose what you put in.
Engineering risk in the composition — specifically, committee liveness when the producer set is open and adversarial, and whether the latency targets survive real network conditions. Both are named in the proven-versus-research section with the rest. A regulatory or funding failure would end the project; an engineering failure in that composition would end the thesis.
We publish the negative result, in the research library, with the analysis. That has already happened to smaller claims — an earlier version of this site led with a headline that conflated block interval with finality, and it was killed internally before launch rather than defended.