SourceLessExplorer · SourceLess AsgardSourceLess Asgard · chain 1313
LiveHeight23,699Head age52 sLast interval1 minFinality23,688Behind−11Pending0 / 8,192Tx in head0
XPlorer following the chain as its own read-only node

height 23699 of 23699 on the network. 9 peer(s) connected, 77 in its peer directory; 995 block(s) followed and 825 pulled in by sync since this follower started. Caught up: this follower holds every block any peer has claimed, so every panel below is the whole chain. Genesis 1cf8655125cc1bbb…, producers genesis.

What this follower is, locally

Following 7 seed(s) — their addresses are not published here, for the reason the peer table gives. Its store is held under its own Cerberus lease — no other node’s store is opened, touched or stopped.

Business forks

Vanaheim: a chain of your own, started from the SourceLess software with its own genesis, its own validators and its own assembly. It runs the whole of SourceLess, from contracts and hostless storage to STR.talk, and shares nothing with Asgard but the code. Allied with Asgard and governed by nothing in it.

Most projects want a token, not a fork. Fork only if your asset must be native, your data must not sit on a chain other people read, or your regulator requires you to operate the validators.

A token on Asgard

What you deploy
An AresLang contract
Your asset
A ZK13 token in contract storage
Who validates
The SourceLess validators
Who decides parameters
The Althing
Security
Inherited
Cost to start
One deploy record
Reversible
Yes: deploy another contract

A chain of your own

What you deploy
A genesis and a validator set
Your asset
Can be native to the chain
Who validates
Your nodes, and only yours
Who decides parameters
Your assembly, seated from your genesis
Security
Yours entirely
Cost to start
A validator set you operate for ever
Reversible
No: the genesis is permanent

From a rehearsal to a chain that carries value

Four stages. The first takes a minute on one machine; the second is what separates a rehearsal from a chain anybody may trust.

  1. Rehearse

    Keys derived from the name and id

    node scripts/fork.mjs up --name … --chain-id … --validators … builds a genesis, starts every seat on this machine and prints the genesis hash and the endpoints. The banner calls it a rehearsal: nothing on it is evidence of anything, and it is how you test an application against a chain of your own.

  2. Make the production keys

    Made and held privately

    The keys that seal a chain carrying value are made and held privately, never derived from its name. SourceLess does this with you before launch; it is the step that makes your keys yours.

  3. Launch

    Your seats, your keys

    node scripts/fork.mjs up --genesis <file> --seat <dir> … starts the chain from the production genesis on its own seats. The banner says DELIVERED, the only path that produces a chain anybody may put value on.

  4. Publish and operate

    Your validators, for the life of the chain

    Every port the command opens is loopback. A published endpoint, a domain name, TLS and a seed list are separate work, and so is running the machines every day after: the stack says what each part of a running fork needs.

What a fork runs

Nearly every part signs its records over the genesis hash, so it works on your fork as on Asgard, and nowhere else.

Built

Nodes: all three classes

Every SourceLess node is one of three classes, set by how much it keeps. Only the two that keep a chain may seal, and only when the genesis gives them a seat.

Partly built

Praeco: how your nodes find each other

Praeco is hostless peer discovery: nodes publish self-signed records (an ed25519 and ML-DSA pair), exchange them with the peers they meet, and drop a record that fails five dials in a row. Records expire after 30 minutes.

Built

Hostless storage: your fork's database

Data with no server. A space (Oort) records on chain who may read it, its price and a manifest root; the content is never on chain. It is cut into encrypted 256 KiB chunks (Accretion) with Merkle proofs, so a peer holding chunks cannot read them. Records from a spreadsheet seal into a space (Stardust, from Kuiper's CSV import), and a reader can verify what it fetched against block headers without keeping the chain (Lagrange, --light).

Built

Smart contracts

Every contract template deploys on a fork: the same compiler gives the same bytecode, the same VM charges the same gas, and the same deployer and salt give the same address.

Partly built

STR.talk: messaging between your names

Threads between STR.domains, sealed end to end (Occultation). The chain records that a message was posted, who may read a thread, receipts and key epochs; the message itself is sealed to its readers.

Built

The door: signing in with an STR.domain

Thrymgjoll is the holder's door: an application a holder signs in to with their STR.domain. It holds no key. The wallet signs a challenge that carries the genesis hash, and the door checks it against the chain.

Not built

eSIM access to SourceLessNet

A phone's eSIM as a way in: the device carries, or unlocks, the key of an STR.domain, and the door admits it with the same challenge a wallet signs today.

Partly built

An explorer for your fork

This explorer, pointed at your fork. It follows your chain as a node does and shows its blocks, names, spaces, threads and contracts.

Measured, not promised

3seats, three distinct producers

20blocks in 60 seconds

3,000 msslot, one block per slot

1head and one state root on every node

Measured on 2026-09-17, on Windows 11, from the command the builder opens on: height 7 at the first reading and 27 sixty seconds later, chainValid true on all three nodes. Every number is from one machine, so the seats shared a clock and a disk. A fork across several machines, and a production launch end to end, are not measured yet.

What a fork does not get

Stated before what it gets, because this is the assumption that ruins a fork.

  • No shared security. Your blocks are sealed by your seats and by nobody else. The SourceLess validators do not see your chain, hold no key on it, and could not help it if every one of your nodes went down.
  • No bridge. There is no path for value to move between your chain and SourceLess, or anything else. A fork is created fail-closed: it mints no $TR and refuses every collateral record.
  • Your own validator set to recruit. The genesis set is your whole producing capacity on day one, and adding a seat afterwards is a governance action at the 30-day delay.
  • Your own custody to perform. A rehearsal fork's keys can be derived by anyone who knows its name and id, so a fork that carries value has its keys made and held privately before it launches.
  • No real ZK13 prover. The reference provider refuses to run in production until a real prover is bound.
  • No migration path. Contract state cannot be moved onto a fork or off it across a genesis boundary.
  • No endpoint anybody else can reach, out of the box. Every port the fork command opens is loopback; a published endpoint, a domain name, TLS and a seed list are separate work.

What the genesis decides for ever

Fixed when the genesis is

  • The chain name and the chain id. Both are in the genesis hash, and the hash is the chain's identity.
  • Everything bound to the hash. Transaction, block and contract signatures bind it, so none replays onto another chain.
  • The allocations. Who holds what at block zero.

Changeable by your assembly, after a delay

  • The block target, from 1 to 60 seconds, after 7 days.
  • Confirmations before final, from 4 to 127, after 7 days.
  • The voting window and the timelocks, after 30 days.
  • The validator set. A seat moves by a governance action, after 30 days, so plan the starting set.