Dassie
Menu

Release notes

What each release brings, newest first. A node installed with the installer's systemd units looks for a new release once a day; on NixOS, your flake decides.

dassie --version and dassie status name the version you run. How a node moves to a new release, and back, is in Updates and rollback; where releases come from, and how each is signed, in Release mirror and key. The same notes are on the architecture page.

0.3.0 starts the testnet afresh: a node from 0.2.x peers with no 0.3.0 node, and its phrase and database don't work with 0.3.0. Its daily update installs 0.3.0, which refuses the old database and doesn't start, so the update goes back to 0.2 and dassie status says so. Move the node's data aside, install the newest release, and set the node up again with a new phrase, from a fresh database: A node from the 0.2 releases has the steps.

On this page
  1. 0.4.0
  2. 0.3.4
  3. 0.3.3
  4. 0.3.2
  5. 0.3.1
  6. 0.3.0
  7. 0.2.9
  8. 0.2.8
  9. 0.2.7
  10. 0.2.6
  11. 0.2.5
  12. 0.2.4
  13. 0.2.3
  14. 0.2.2
  15. 0.2.1
  16. 0.2.0
  17. 0.1.3
  18. 0.1.2
  19. 0.1.1
  20. 0.1.0

0.4.0

  • A node's place in the network now follows the core it works out from the signed link states, not just whether it has a hostname. Every node starts in the periphery, a node with a hostname too, and becomes a core node once its uplinks have checked it: how long it has been in good standing, its heartbeats and its clock, and that it answers at its URL over QUIC and over HTTPS with a publicly issued certificate. The bootstrap nodes are core from the start. A node being promoted is paid beneath its core peers until it has been core for a while, and keeps taking packets at those addresses afterwards.
  • When a node's funds in a settlement hub are short, it shares them among its peers rather than serving whoever asks first. Every peer can always count on one largest packet, and on enough to carry what it may have in flight while funds allow; what is left goes to core peers first, by the fees they earned the node, then to downlinks. A node with plenty in its hub behaves as before.
  • A node whose funds in a hub cannot cover one largest packet for each of its peers takes fewer peers, dropping downlinks first, and tops its pool up to a packet per peer before anything else.
  • A fifth bootstrap node, boot5.dassie.xyz, joins boot1 to boot4. A node still needs a majority of the lists, three of five, so two bootstrap nodes can be down, or a whole zone lost, and the network keeps its membership.
  • A node's database now starts from one step that builds the schema 0.3.0 wrote, and the databases of every 0.3 release carry on: 0.3.0 to 0.3.3 migrate to the current schema, with a copy kept first, and 0.3.4's open as they are.

0.3.4

  • Your node keeps a generous amount in each settlement hub, a thousand of its largest packets (100 XRP or 100 USD by default), and tops it up from your own XRP Ledger account once it falls a tenth below that. Its holds for its peers count toward that amount, and it always keeps enough spendable to fund a request to settle from each peer at once. Earlier releases stopped depositing once the holds of about ten peerings filled a 10-unit ceiling, so a node with plenty on its own account could not settle, and payments through it failed. Most nodes now keep all their funds in the hub. A node in a token hub, such as DSUSD's, keeps 2 XRP on its own account for that hub's fees.
  • You can set how much your node keeps in each hub: dassie hub target <scheme> <amount>, or the target on the wallet's Hubs page, and dassie hub target <scheme> default goes back to the default. The node keeps what it put in within a tenth of that amount. A target is at least ten of the largest packets, and enough that the hub's floor stays above the account's reserve. Your node's first deposit into a hub is the target itself, since the account's reserve counts toward it.
  • A bootstrap node lists a node that registers only once its URL answers over HTTPS with a publicly issued certificate, not just over QUIC, so a node that fails HTTPS is turned away at once rather than listed and dropped two hours later.
  • Your node checks the XRP Ledger's proofs on every ledger only while a settlement through its account is on its way, and otherwise when something calls for it, so an idle node asks the proof server far less. It signs a payment only from a proof it took moments ago.

0.3.3

  • A node now keeps its place on the network's list only while its URL keeps passing the bootstrap nodes' checks: it answers over QUIC (UDP 443), and it serves over HTTPS with a certificate from a public authority, as ACME gets one. A self-signed certificate, which a node serves while ACME fails, does not pass. A node that fails either check for two hours leaves the list, though it is up and renewing, and after it registers again it drops off again two hours later until both checks pass. So a node that went away leaves the list too.
  • For people who run nodes for a network: set DASSIE_EVENT_LOG=<path> and the node writes its packet trace and the hub events it sees to a file, one JSON line each, rotated under a size cap (DASSIE_EVENT_LOG_MAX_BYTES, 64 MiB by default). It is off unless you set it, a path the node can't open stops it at start, and it records other people's payments that pass through your node.
  • The desktop app's icons and the page it shows while the node starts are in Kopje, Dassie's visual identity.

0.3.2

  • The wallet draws in Kopje, Dassie's visual identity, on every screen, light and at dusk. Home opens on the balance, with Send and Receive below it and the last few payments beside it.
  • A payment shows the amount it fixed. A request paid in full shows its amount, even when what arrived is up to a ten-thousandth of a unit off. A payment of what the receiver gets leads with that amount, and what it cost follows.
  • Two nodes keep one QUIC connection between them, and both keep the same one. A new connection replaces the one they have only once a request has gone through it, and the old one closes after its last requests. Update every node in your network together: while some still run an older release, a request in flight can fail once when a connection is replaced. A node is listed and peered only if its URL answers over QUIC, since checks now dial it anew: a node with a hostname but UDP port 443 closed drops off the list once the bootstrap nodes run 0.3.2.
  • An uplink checks a downlink that asks to be promoted to the core: how long it has been in good standing, its heartbeats, its clock, the room and settlement between them, and that it answers at its URL over QUIC and over HTTPS with a publicly issued certificate. The owner RPC shows each check, but nothing promotes a node by them yet. Core nodes say in their link state how many more core peers they take.
  • For tools that watch a network: the owner RPC's packet trace names each packet's condition, its ledgers and the nodes on either side, so its hops can be joined across nodes, and SubscribeHubEvents streams what a member sees of its hubs.

0.3.1

  • Settlement hubs run a new version of their protocol, which a hub's validators move it to with a vote. In it, a peer that rejects a packet signs a release with its Reject, and can no longer take the packet's money from the hub after rejecting it: the payer disputes such a claim with the release, and a claim waits a minute before it pays. The testnet's two hubs move to it a day after their validators vote, so update every node in them before then: a node still on 0.3.0 stops following the hubs once they move.
  • A validator votes to move its hubs only where its owner names the version in its validator config, as hubVersion, and dassie status shows each hub's version and when a move takes effect.
  • The owner sees one balance per asset, in the wallet and in dassie status, and Send pays in an asset. The hub account is the node's to manage, like a hold: deposits go to the owner's own XRP Ledger account, and a payment over a hub that needs more than the hub holds has the node deposit the rest first. The setting for where received money is kept is gone.
  • Peers top up each other's holds sooner: a node asks a peer to settle as soon as its room runs low, and a peer that could not pay at once pays as soon as it can.
  • Every node works out which nodes are in the core from the signed data the network shares, and the wallet's Network page shows whether yours is.
  • A node without a hostname is reached through the dassiepay.net relay again with no configuration, and dassie.land has a docs section for running and using Dassie.

0.3.0

  • Peers settle only over settlement hubs. The testnet's XRP hub and DSUSD hub, both kept by the four bootstrap nodes, are built in, and dassie setup joins the XRP hub on the testnet unless --hub names others or none.
  • A node can be in several hubs, one per asset, and each hub two peers share is a settlement method of their peering. A packet's next hop is drawn at random among the routes, weighted by the fees each peer has earned.
  • A hub can hold a token such as DSUSD, and follows its issuer: it holds still while the issuer freezes its escrow, and a clawback ends it with a payout pro rata. A node without an account in a hub joins it by being paid in by a peer that is a member.
  • Nodes speak peer protocol version 2, dassie/2, which 0.2.x nodes don't, so a node peers only with nodes on 0.3.0 or later. Node IDs now commit to a post-quantum SLH-DSA key as well, and recovery phrases are 20 words in a new format that names the realm; dassie setup takes the realm from the phrase.
  • Peers talk over QUIC only, so a node needs UDP port 443: there's no HTTPS fallback any more, and dassie.service doesn't start while UDP 443 is taken. Only a node without a hostname falls back, to QUIC over a WebSocket, when UDP is blocked, through an HTTP proxy where the network sets one.
  • The testnet was reset for this release: the bootstrap nodes have new IDs, and phrases and databases from 0.2.x don't work. Set a node up again with a new phrase from a fresh database.
  • A node checks what it reads from the XRP Ledger with proofs against ledgers the network's validators signed, and can register a name on the testnet from the wallet. Peers swap assets with each other.
  • dassie market-maker runs on one node, in both hubs, and trades by swapping with its peers (SwapWithPeer) instead of reading the UDP rate feed. Its config changed: socket and passphraseFile are at the top, each asset names its hub ledger and its ownerBook, and targets is gone, since the targets are the node's DASSIE_UPLINKS; caFile now names roots to trust the XRP Ledger server by. A config in the old format is refused, so rewrite it.

0.2.9

  • The testnet's settlement hub runs, kept by the four bootstrap nodes as its validators, and is built in as the default hub. A node joins it when its owner adds the hub-xrp-testnet scheme, which the wallet now offers and describes: the node moves about 2.5 test XRP from its XRP Ledger testnet account into the hub, and then peers over the hub with other members of it.
  • Nothing changes for a node that doesn't add the scheme, and the peerings a node already has stay as they are.

0.2.8

  • A node can settle with its peers through a settlement hub: a small ledger kept by a few validators and backed by an escrow on the XRP Ledger testnet. Over a hub, a payer sets money aside in a hold toward its peer, and that hold is all the credit the peer extends, so neither side can walk away with what it owes. No hub runs on the testnet yet, so nothing changes for a node until one does, and the wallet doesn't offer the hub scheme until there is a default hub.
  • A node keeps its hub account funded from its XRP Ledger testnet account on its own, between a floor and a ceiling, and the owner can move money with dassie hub deposit, dassie hub withdraw and dassie hub status.
  • A node can run as one of a hub's validators: DASSIE_VALIDATOR_CONFIG names the sponsors it agrees to found hubs with, and dassie hub found founds a hub with validators that agreed, and sets up its escrow.
  • The testnet's bootstrap nodes now all run in us-east1, and a fourth, boot4.dassie.xyz, joins the default list.
  • A node no longer aborts when a QUIC stream is read first in order and then out of order, a bug in quinn-proto that the market maker's node ran into.
  • Open Payments grants approved earlier with a limit on what is received but none on what is debited are revoked, since nothing bounded what they could debit.

0.2.7

  • A market maker's periphery node may keep up to 128 uplinks: list them in DASSIE_UPLINKS. A periphery node's self-description to its uplinks no longer lists them as neighbors, since only core nodes have neighbors.
  • dassie market-maker trades through several core nodes with its same two nodes. It follows each one's feed and takes the best trade each time, and its VM trades through boot1, boot2 and boot3 by default.
  • An incoming payment on a periphery node can be received beneath a chosen uplink, with uplink in the owner's CreateIncomingPayment.
  • A settlement channel with a node the node no longer peers with closes after a day idle, once nothing of it is pending. Its place is freed for new peers, and its accounts and sequences stay, so peering again carries on where it left off.
  • An Open Payments grant may limit what is debited and what is received together, but no longer what is received alone, and a receive limit now caps what payments actually deliver.
  • The groundwork for settlement hubs is in the code. No hub runs yet, and nothing changes for a node until one does.

0.2.6

  • A node's STREAM receiver never lowers the most it has told a sender it may send, as the STREAM specification asks. When several payments race into one incoming payment, payments that fit together all complete. A payment the receiver can no longer take is told the receiver takes no more, and closed, rather than refused until its deadline. A Dassie payment that is short by no more than its tolerance then counts as complete.
  • dassie market-maker no longer stalls when one of its nodes is above its band and the other has no room: it trades from the node with no room into the one above its band, which makes room, and then rebalances. The market maker's VM now leaves room for all the XRP the testnet faucet grants.
  • tokio is updated, for advisory RUSTSEC-2026-0386.

0.2.5

  • dassie setup --passphrase-file <file> sets a node up from its recovery phrase without a browser, for a headless node or a market maker's own nodes. It sends the node key only to the node's own certificate, which the node names over its owner socket, and it can add settlement schemes with --scheme. Running it again changes nothing.
  • A constant-time helper the cryptography libraries use is updated, for advisory RUSTSEC-2026-0385.

0.2.4

  • A core node prices what it converts by what it holds. When it runs short of one asset, it pays a little more for that asset and asks more for it, so trading brings it back. The new rebalancing setting beside the spread says how strongly, 5% by default, and each packet pays for its own effect on the price.
  • A core node publishes the rates it converts at as a signed feed on UDP port 7768, from the new dassie-feed.socket, to subscribers that first prove their address. GET /stats and the node's link state name the port. An update turns the socket on, so open UDP 7768 in your firewall for subscribers to reach the feed; on NixOS, openFirewall now opens it.
  • dassie market-maker trades through a node when the node's feed and an AMM pool on the XRP Ledger leave a margin, then swaps its funds back through the pool. It trades through two periphery nodes of your own, each pinned to the node with the new DASSIE_UPLINKS, and signs only for the XRP Ledger testnet.
  • A new settlement scheme, xrpl-testnet-dsusd, settles in DSUSD, Dassie's own testnet dollar, beside RLUSD. There is no DSUSD faucet: buy it with XRP through the testnet's XRP/DSUSD pool, which is kept at the market's XRP price.
  • The owner's Send also pays STREAM credentials, an ILP address and a shared secret.
  • A payment no longer fails at its very end when the receiver's answers arrive out of order.

0.2.3

  • Opening a node's front door name, https://<node ID>.dassiepay.net/, in a browser shows a short page the front door writes itself: the node ID the name stands for, whether that node is connected now, and its wallet address. The page runs no script and sets no cookie.
  • The wallet's Settings lists paired devices, with a Revoke for each, and pairs a new one with a QR code. It also shows which version of Dassie the node runs.
  • A new node with a single bootstrap node always finds its first peers: while it has none, it also asks the bootstrap node for its own link state.
  • Payments finish more reliably when the incoming payment being paid into has less room left than a packet, as when two payers share one: the sender sends what fits, a receiver without room is asked again, and a closed connection keeps saying why it closed.
  • An incoming payment counts as paid once it is within a ten-thousandth of a unit of its amount, under or over, since rounding along the path keeps a payment from landing exactly. Its receivedAmount in Open Payments can therefore exceed its incomingAmount by that much.

0.2.2

  • A node can settle in RLUSD, Ripple's dollar token, on the XRP Ledger testnet, with the xrpl-testnet-rlusd scheme. It shares the node's XRPL account with xrpl-testnet: the node sets up its RLUSD trust line itself, pays the fees in XRP, and books RLUSD as dollars. Test RLUSD comes from Ripple's faucet at tryrlusd.com.
  • The wallet has a page of external assets, showing what the node's XRPL account holds as the ledger reports it: XRP, RLUSD, the reserve, and whether the issuer has frozen the line. Receive says where to send XRP, with the testnet faucet, and RLUSD.
  • While RLUSD's issuer freezes the node's line, the node settles nothing on it. While the issuer deep-freezes the line, freezes RLUSD for every holder, or charges a transfer fee, the node also asks no peer to pay into it, and no peer is cut off for what it could not pay.
  • On NixOS, each release comes as a flake: point a flake input at https://get.dassie.land/flake/latest.tar.gz and enable services.dassie. It runs the release's signed binary, with no updater.
  • A node holds a lock on its data directory, so a second daemon on the same directory refuses to start.
  • A node whose Fulfill is refused because its clock is behind a peer that just restarted sends it again, so the two nodes' books no longer drift apart from this and stall payments between them.

0.2.1

  • A node without a hostname keeps a connection to the dassiepay.net front door by default, so Open Payments clients reach it at <node ID>.dassiepay.net with no setup. The front door, which the project runs, then sees when such a node is online. Set DASSIE_RELAY to another relay, or to nothing to keep none.
  • dassie status describes a periphery node as one: its uplinks, its relay and whether it is connected, and the names it answers to. The wallet says whether its front door can reach the node right now.
  • The log says at startup whether the node has QUIC, and which transport each peer is reached over.
  • Downlinks and core peers have QUIC connection places of their own, so a crowd of periphery nodes or strangers cannot crowd out a node's core links. A node with no room left says so, and the asking node turns to HTTPS.
  • The consent page says what is sent, what is received and for how long, and warns of a receive limit no payment can fit. A payer tells a receiver that stopped a payment early from one that received all of it.

0.2.0

  • Peers talk over QUIC on UDP port 443, each checking the other's node key instead of a certificate authority; a peer that cannot be reached over UDP is asked over HTTPS. Installs gain a dassie-quic.socket unit, which the updater turns on.
  • A node without a hostname joins as a periphery node: it peers with core nodes as their downlink, keeps its connections to them open, and is paid at an address beneath each of them.
  • Any node relays encrypted streams to the nodes connected to it, and a node can keep a connection to a relay of its choice with DASSIE_RELAY.
  • Open Payments answers are signed with the node's key. A node without a hostname answers under <node ID>.dassiepay.net and the names in DASSIE_PUBLIC_NAMES, and dassie front-door runs a front door that passes Open Payments requests on to such nodes.
  • Ending a peering collects what the peer owes first and settles nothing for the end, a peer that stays short of room is set apart, and a ban takes effect at once.
  • Hardening and fixes: XRP Ledger settlement copes with servers that lag or forget history, the updater keeps a node stopped when its database cannot be put back, and skips a version it rolled back, the installer never runs beside an update, and limits hold for strangers' replays, probes and Open Payments clients.

0.1.3

  • The wallet's Network page draws the routing table, and lists peers that have gone offline apart from those still heard from.
  • A grant may limit what it debits or what it delivers, not both, as Open Payments asks; the wallet says which.
  • STREAM backs off once for a burst of rejected packets, so a payment that runs out of credit resumes in moments instead of tens of seconds.
  • The daily updater runs in a systemd sandbox, and the node's unit is tighter.
  • Hardening: another wallet's URL can no longer reach private addresses through an IPv6 literal, a bootstrap key of the wrong length is reported as an invalid DASSIE_BOOTSTRAP_NODES instead of crashing the node, far-apart exchange rates no longer stop the rate task, and every payment ID has one spelling.

0.1.2

  • A new node joins the public testnet on its own: its bootstrap nodes are boot1–boot3.dassie.xyz unless DASSIE_BOOTSTRAP_NODES names others.
  • The installer and the updater keep to the channel a node was installed from.
  • XRP Ledger settlement runs on the testnet only.
  • Connections share the node's slots fairly, and a BTP client that has gone away answers with an ILP Reject.
  • Hardening: the setup URL stays out of the journal, dev flags warn on a public listener, more non-public addresses are refused, and a revoked grant leaves the owner's connected apps.

0.1.1

  • Updates that fail roll back: if a new version does not start, the node goes back to the old one, with its data as the old one left it.
  • dassie status shows how a node is doing, and the setup URL survives restarts; dassie setup-url prints it again.
  • Let's Encrypt accepts the node's certificate requests again.
  • Open Payments: each payment gets a STREAM connection of its own, and each item of a grant keeps to its own limits.
  • The node checks its books and its state machines for consistency as it runs.

0.1.0

  • The first release of Dassie in Rust: one static binary for x64 and arm64 Linux, signed, installed with one command and updated every day.
  • A node finds peers on its own, routes Interledger payments across them, and settles with them on the XRP Ledger testnet.
  • Apps pay through it with Open Payments or BTP, and payments convert between currencies at fetched rates.
  • Each peer gets a grace limit, and a peer that costs more than that is banned.
  • The owner runs the node from a wallet it serves itself.
A kopje of granite blocks against the sun, in veld grass; one dassie climbs its slab, one keeps lookout on top inside the sun, and one sleeps on the next rock; on a wide screen, a pair sits on a kopje to the left