What's next

Dassie is early. This page lists what it does not do yet, so you know where the edges are. The work has no numbered milestones: each area moves forward on its own, side by side with the others.

The full list, with what "done" means for each area, is the roadmap in the specification. This page says the same in plain words, and leaves out the internals.

Real money

Every node refuses the live realm, so nobody can put real money into Dassie yet. It stays that way until every condition on a short list holds. Still left: the node checking the XRP Ledger's validators in a few more cases, a live node that takes none of the testnet's defaults, settlement hubs on mainnet, a mainnet list of bootstrap nodes, and an external security review. Early days lists every condition and where each stands.

Why it works this way: each condition closes a way that real money could be lost.

The public testnet

The testnet was set up again for 0.3.0. Its five bootstrap nodes, boot1 to boot5, are built in, and so are its XRP hub and its DSUSD hub, which four of them, boot1 to boot4, keep. The project also runs the front door at dassiepay.net, which a node without a hostname keeps as its relay by default, so that it is reached at <node ID>.dassiepay.net. A new node finds the network on its own, and dassie setup joins the XRP hub.

The testnet still has no domain of its own. Later, its names move to test.dassiepay.net, so that dassiepay.net is left for the live realm.

Settlement hubs

Peers settle over settlement hubs, and the node runs as a hub's member and as one of its validators today. On the testnet, an XRP hub and a DSUSD hub run, kept by four of the bootstrap nodes. Still to come:

• hubs on mainnet, for XRP and for RLUSD: their schemes are built, but no hub runs there yet, so none is built in;
• for owners: closing your account in a hub, and moving to another hub of the same asset;
• for validators: keeping their history across a restart, and a few rarer steps when a hub's validators change;
• founding: replacing a validator that fails before the hub starts, and following a founding in the wallet;
• hub balances and holds in the desktop app;
• once hubs run for a while: fees that follow how busy a hub is, several hubs of one asset per node, and putting what a node earns into its holds.

Names

Names are built, and on the testnet they are free, held for your node by a quorum of the bootstrap nodes. A name reaches a node through a front door: a node without a hostname is reached at <name>.dassiepay.net, through the front door it keeps as its relay by default. Testnet names may be reset at any time. A live node has no names. Next:

• fees for names and for registering a node, so that nobody can take every good name for free; with them, names on the live realm;
• showing in the wallet who holds the names your node looks up, and the payment address each of your names gives;
• moving a name to a new node ID when you move to a new node.

Nodes without a public IP

A node without a public IP joins as a periphery node: it connects to core nodes as its uplinks, gets addresses beneath them, and is reached through a relay, by default the front door at dassiepay.net. That works today, over UDP or, where UDP is blocked, a WebSocket, through an HTTP proxy where the network sets one. Not there yet:

• dialing a lost uplink again with a backoff;
• demotion by uplinks: an uplink that promoted a node checks it only until it is in the core; later it keeps checking it, and stops vouching for one that stops answering;
• front doors: the consent page for apps that ask to spend from your wallet, your own domain pointed at a front door, your names as a wallet setting, and rate limits per client behind a front door;
• owner apps. The node pairs apps today (dassie pair), but the apps themselves, a remote mode of the desktop app and a mobile app, are still to be built;
• the desktop app beyond Linux and Nix: AppImage, .deb and Flatpak packages, macOS and Windows, and updates of its own (Other platforms);
• receivers that need no deposit of their own, and nodes that run in a browser.

Setting up in the wallet

Today you set a node up with your recovery phrase and a first ledger, and every other choice is a default. A guided setup in the wallet is to walk you through each choice that matters, and what it costs. One of them is your relay. A node without a hostname keeps a connection to the project's front door at dassiepay.net by default, unless its owner says otherwise in DASSIE_RELAY. The front door then learns when your node is online, and reads the Open Payments requests it passes on. The guided setup is to say so, and let you keep it, name another relay, or keep none. Until then, How others reach you shows how to choose.

Exchange rates

A node's holdings drift as it forwards payments. Today, peers swap assets with each other at the prices in each other's signed snapshots, which brings them back toward balance. What is left is where the rates come from. A node takes its exchange rates today from exchanges and the European Central Bank, whose terms allow personal or internal use. Next, it takes XRP's rate from mainnet's XRP/RLUSD pool, proven against validated ledgers, and the other currencies' from four central banks.

Checking the XRP Ledger

A node proves what it reads from the XRP Ledger against ledgers its own list of validators signed, with the project's proof servers answering. Left: signing only from a fresh anchor, a few more cases in the simulations, offering the proof servers' patch to rippled, and riding out validators that go offline as rippled does. Issuer transfer fees on tokens are not handled yet: while an issuer charges one, the node does not pay from that token.

Kopje everywhere

This site draws in Kopje, Dassie's visual identity. The wallet and the desktop app's icons and tray do not yet.

Smaller gaps

• ILP over HTTP. The node speaks BTP and Open Payments to clients, but serves no /ilp route.
• Post-quantum TLS. The node's TLS uses classical key exchange only. Each node ID already commits to a post-quantum key, which signs nothing yet.
• Limits per ledger. The largest packet, and the thresholds counted in it, are one value for the whole node, not one per ledger.
• Live status in the wallet. The wallet asks the node for its status and hubs every few seconds, instead of following a stream.
• A gentle shutdown. On stop, the node does not wait for payments in flight to finish. After the restart they count as rejected.
• Peers over a node's lifetime. A node keeps the accounts of every peer it ever had in memory, which caps how many peers it can have in its life at a few thousand.
• Pre-releases. There is one release channel, and no release candidates.

How Dassie is tested and released

• Continuous simulation. A campaign already runs the simulations from random seeds and files an issue for each new failure. Next: wider random configurations in more simulations, and, once a live network runs on Dassie's releases, a release that waits until the campaign has cleared it.
• Rebuilding releases. Each release is built once, then signed. Next, a second builder builds it again and signing waits until the bytes match.

Further out

Some designs stay future work, and the architecture must leave room for them: a way to pay for messages between nodes with tokens, a private transport between peers over UDP, and a wallet that does not have to trust the node that serves it.

Following along

The roadmap changes as work lands, and Release notes say what each release brought. The reasons behind each piece of work are in the design decisions. To talk about any of it, or to help, come to Discord or read Contributing.