From ab8d05c0050ade8723102ad86fa53d135698ced1 Mon Sep 17 00:00:00 2001 From: dalibran Date: Tue, 14 Apr 2026 11:35:04 -0700 Subject: [PATCH 01/25] docs(website): add Use Cases section with Wallet integration guide MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Add Use Cases dropdown to navbar (between Manual and Protocol) - Rename navbar labels: "User manual" → "Manual", "About Mithril" → "Protocol" - Add Wallets use case page covering developer and end-user audiences - Add useCasesSideBar to sidebars.js and versioned sidebars - Wallet page includes: security caution admonition, integration guide, Discord CTA button, and note on server membership Co-Authored-By: Claude Sonnet 4.6 --- docs/website/docusaurus.config.js | 16 +++- docs/website/root/use-cases/wallets.mdx | 93 +++++++++++++++++++ docs/website/sidebars.js | 6 ++ .../version-maintained/use-cases/wallets.mdx | 93 +++++++++++++++++++ .../version-maintained-sidebars.json | 6 ++ 5 files changed, 212 insertions(+), 2 deletions(-) create mode 100644 docs/website/root/use-cases/wallets.mdx create mode 100644 docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx diff --git a/docs/website/docusaurus.config.js b/docs/website/docusaurus.config.js index 7e219492f44..21a2d1883f8 100644 --- a/docs/website/docusaurus.config.js +++ b/docs/website/docusaurus.config.js @@ -248,12 +248,24 @@ const config = { type: "doc", docId: "manual/welcome", position: "left", - label: "User manual", + label: "Manual", + }, + { + type: "dropdown", + label: "Use Cases", + position: "left", + items: [ + { + type: "doc", + docId: "use-cases/wallets", + label: "Wallets", + }, + ], }, { type: "doc", docId: "mithril/intro", - label: "About Mithril", + label: "Protocol", position: "left", }, { diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx new file mode 100644 index 00000000000..2874fb02abe --- /dev/null +++ b/docs/website/root/use-cases/wallets.mdx @@ -0,0 +1,93 @@ +--- +id: wallets +title: Wallets +sidebar_label: Wallets +--- + +# Using Mithril for Light Wallets + +## For Wallet Developers + +Cardano users expect fast, reliable confirmation that their transactions have landed. Traditionally, delivering that required either running a full node or trusting a third-party service. Mithril offers a third option: cryptographic proof of transaction inclusion, backed by Cardano's stake pool operators, that any wallet can verify independently. + +:::caution + +**The Mithril client library is production-ready code, but we recommend caution before deploying certificate verification in a production wallet.** Protocol security guarantees are proportional to stake participation — until the Mithril signer achieves sufficient coverage across the SPO ecosystem, there is a risk that certificates could be compromised. The greater the stake participation, the stronger the guarantees. + +::: + +### What Mithril Gives Your Wallet + +When a user submits a transaction, Mithril lets you confirm it was included in the Cardano chain without running a full node and without trusting a centralized API. Instead of relying on a server telling your wallet "yes, that tx went through," you get a Merkle proof tied to a certificate signed by a quorum of SPOs weighted by stake. Your wallet verifies the proof locally. + +For users, this means faster perceived finality — you can surface a meaningful "confirmed" state sooner, and with stronger guarantees than a block count alone provides. + +### How It Fits Into Your Existing Stack + +Most light wallets already rely on a hosted API or indexer for balance lookups and UTxO queries — services like Blockfrost or Koios. Mithril doesn't replace that. What it adds is a trustless verification layer on top: rather than taking your data provider's word that a transaction landed, you can cryptographically confirm it against a certificate chain secured by Cardano's actual stake distribution. + +This matters for security. If your data provider is compromised or returns bad data, a Mithril proof will fail to verify — your wallet catches the discrepancy rather than silently showing users incorrect state. A compromised API can't fabricate a valid Mithril proof. + +The result is an architecture that keeps what already works while meaningfully reducing the trust your users have to place in third-party infrastructure. + +### Integration + +The easiest path for most wallet teams is the official WASM package: + +```bash +npm install @mithril-dev/mithril-client-wasm +``` + +It works in-browser and in Node.js, covering desktop wallets, web wallets, and mobile wallets built on web technologies — iOS Safari and Android Chrome are both supported. A Rust crate is also available if you're building natively on desktop. + +Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. + +The core flow is straightforward: +1. Submit the transaction as you normally would +2. Query the Mithril aggregator for a transaction proof once the tx hash is known +3. Verify the proof against the current Mithril certificate chain +4. Surface the confirmation to the user + +Proofs are available roughly every 30 blocks, with certification running ~100 blocks behind the tip to ensure finality. Factor this into how you communicate confirmation status to users. + +### Questions? + +Have a question during integration? Reach out in the [#ask-mithril](https://discord.com/channels/826816523368005654/1014019542504185876) channel on the IOG Discord — the team is active there and happy to help. + + + + + + #ask-mithril + + +:::note + +You'll need to be a member of the [IOG Discord server](https://discord.gg/5kaErDKDRq) to access this channel. + +::: + +## For Wallet Users + +If your wallet supports Mithril, transaction confirmations are faster and more trustworthy. Rather than relying on your wallet's servers to tell you a transaction went through, Mithril provides cryptographic proof — verified against Cardano's network of stake pool operators — that your transaction is on the chain. + +In practice, this means fewer anxious minutes wondering if a payment landed, and more confidence when it says it did. + +**Does my wallet support Mithril?** Mithril integration is still being adopted across the ecosystem. Check your wallet's release notes or documentation, or ask their support team. If you're a developer building a wallet, see the section above. diff --git a/docs/website/sidebars.js b/docs/website/sidebars.js index 00853d91bf4..88d385784ea 100644 --- a/docs/website/sidebars.js +++ b/docs/website/sidebars.js @@ -24,6 +24,12 @@ const sidebars = { dirName: "mithril", }, ], + useCasesSideBar: [ + { + type: "autogenerated", + dirName: "use-cases", + }, + ], }; module.exports = sidebars; diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx new file mode 100644 index 00000000000..2874fb02abe --- /dev/null +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx @@ -0,0 +1,93 @@ +--- +id: wallets +title: Wallets +sidebar_label: Wallets +--- + +# Using Mithril for Light Wallets + +## For Wallet Developers + +Cardano users expect fast, reliable confirmation that their transactions have landed. Traditionally, delivering that required either running a full node or trusting a third-party service. Mithril offers a third option: cryptographic proof of transaction inclusion, backed by Cardano's stake pool operators, that any wallet can verify independently. + +:::caution + +**The Mithril client library is production-ready code, but we recommend caution before deploying certificate verification in a production wallet.** Protocol security guarantees are proportional to stake participation — until the Mithril signer achieves sufficient coverage across the SPO ecosystem, there is a risk that certificates could be compromised. The greater the stake participation, the stronger the guarantees. + +::: + +### What Mithril Gives Your Wallet + +When a user submits a transaction, Mithril lets you confirm it was included in the Cardano chain without running a full node and without trusting a centralized API. Instead of relying on a server telling your wallet "yes, that tx went through," you get a Merkle proof tied to a certificate signed by a quorum of SPOs weighted by stake. Your wallet verifies the proof locally. + +For users, this means faster perceived finality — you can surface a meaningful "confirmed" state sooner, and with stronger guarantees than a block count alone provides. + +### How It Fits Into Your Existing Stack + +Most light wallets already rely on a hosted API or indexer for balance lookups and UTxO queries — services like Blockfrost or Koios. Mithril doesn't replace that. What it adds is a trustless verification layer on top: rather than taking your data provider's word that a transaction landed, you can cryptographically confirm it against a certificate chain secured by Cardano's actual stake distribution. + +This matters for security. If your data provider is compromised or returns bad data, a Mithril proof will fail to verify — your wallet catches the discrepancy rather than silently showing users incorrect state. A compromised API can't fabricate a valid Mithril proof. + +The result is an architecture that keeps what already works while meaningfully reducing the trust your users have to place in third-party infrastructure. + +### Integration + +The easiest path for most wallet teams is the official WASM package: + +```bash +npm install @mithril-dev/mithril-client-wasm +``` + +It works in-browser and in Node.js, covering desktop wallets, web wallets, and mobile wallets built on web technologies — iOS Safari and Android Chrome are both supported. A Rust crate is also available if you're building natively on desktop. + +Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. + +The core flow is straightforward: +1. Submit the transaction as you normally would +2. Query the Mithril aggregator for a transaction proof once the tx hash is known +3. Verify the proof against the current Mithril certificate chain +4. Surface the confirmation to the user + +Proofs are available roughly every 30 blocks, with certification running ~100 blocks behind the tip to ensure finality. Factor this into how you communicate confirmation status to users. + +### Questions? + +Have a question during integration? Reach out in the [#ask-mithril](https://discord.com/channels/826816523368005654/1014019542504185876) channel on the IOG Discord — the team is active there and happy to help. + + + + + + #ask-mithril + + +:::note + +You'll need to be a member of the [IOG Discord server](https://discord.gg/5kaErDKDRq) to access this channel. + +::: + +## For Wallet Users + +If your wallet supports Mithril, transaction confirmations are faster and more trustworthy. Rather than relying on your wallet's servers to tell you a transaction went through, Mithril provides cryptographic proof — verified against Cardano's network of stake pool operators — that your transaction is on the chain. + +In practice, this means fewer anxious minutes wondering if a payment landed, and more confidence when it says it did. + +**Does my wallet support Mithril?** Mithril integration is still being adopted across the ecosystem. Check your wallet's release notes or documentation, or ask their support team. If you're a developer building a wallet, see the section above. diff --git a/docs/website/versioned_sidebars/version-maintained-sidebars.json b/docs/website/versioned_sidebars/version-maintained-sidebars.json index c2626a215f4..4f3a637c139 100644 --- a/docs/website/versioned_sidebars/version-maintained-sidebars.json +++ b/docs/website/versioned_sidebars/version-maintained-sidebars.json @@ -20,5 +20,11 @@ "type": "autogenerated", "dirName": "mithril" } + ], + "useCasesSideBar": [ + { + "type": "autogenerated", + "dirName": "use-cases" + } ] } From 114d8c715dbbeeb1e112b86ffa8850029559e658 Mon Sep 17 00:00:00 2001 From: dalibran Date: Tue, 14 Apr 2026 11:38:35 -0700 Subject: [PATCH 02/25] docs(website): fix prettier formatting on wallet use case pages Co-Authored-By: Claude Sonnet 4.6 --- docs/website/root/use-cases/wallets.mdx | 38 ++++++++++++------- .../version-maintained/use-cases/wallets.mdx | 38 ++++++++++++------- 2 files changed, 48 insertions(+), 28 deletions(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 2874fb02abe..8a73fb31819 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -43,6 +43,7 @@ It works in-browser and in Node.js, covering desktop wallets, web wallets, and m Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. The core flow is straightforward: + 1. Submit the transaction as you normally would 2. Query the Mithril aggregator for a transaction proof once the tx hash is known 3. Verify the proof against the current Mithril certificate chain @@ -59,23 +60,32 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc target="_blank" rel="noopener noreferrer" style={{ - display: 'inline-flex', - alignItems: 'center', - gap: '8px', - backgroundColor: '#5865F2', - color: 'white', - padding: '10px 20px', - borderRadius: '8px', - textDecoration: 'none', - fontWeight: 'bold', - marginTop: '4px', - marginBottom: '1rem', + display: "inline-flex", + alignItems: "center", + gap: "8px", + backgroundColor: "#5865F2", + color: "white", + padding: "10px 20px", + borderRadius: "8px", + textDecoration: "none", + fontWeight: "bold", + marginTop: "4px", + marginBottom: "1rem", }} > - - + + - #ask-mithril + + #ask-mithril + :::note diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx index 2874fb02abe..8a73fb31819 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx @@ -43,6 +43,7 @@ It works in-browser and in Node.js, covering desktop wallets, web wallets, and m Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. The core flow is straightforward: + 1. Submit the transaction as you normally would 2. Query the Mithril aggregator for a transaction proof once the tx hash is known 3. Verify the proof against the current Mithril certificate chain @@ -59,23 +60,32 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc target="_blank" rel="noopener noreferrer" style={{ - display: 'inline-flex', - alignItems: 'center', - gap: '8px', - backgroundColor: '#5865F2', - color: 'white', - padding: '10px 20px', - borderRadius: '8px', - textDecoration: 'none', - fontWeight: 'bold', - marginTop: '4px', - marginBottom: '1rem', + display: "inline-flex", + alignItems: "center", + gap: "8px", + backgroundColor: "#5865F2", + color: "white", + padding: "10px 20px", + borderRadius: "8px", + textDecoration: "none", + fontWeight: "bold", + marginTop: "4px", + marginBottom: "1rem", }} > - - + + - #ask-mithril + + #ask-mithril + :::note From 502cd6764ff2b7d4f988a2f05d6b5191492d2d18 Mon Sep 17 00:00:00 2001 From: dalibran Date: Tue, 14 Apr 2026 12:06:38 -0700 Subject: [PATCH 03/25] docs(website): fix Discord button icon/text alignment Wrap button text in a span to prevent MDX from injecting a paragraph element with inherited margin-bottom, and use explicit height on the anchor for reliable vertical centering. Co-Authored-By: Claude Sonnet 4.6 --- docs/website/root/use-cases/wallets.mdx | 8 ++++---- .../version-maintained/use-cases/wallets.mdx | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 8a73fb31819..3381073a8f9 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -65,12 +65,14 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc gap: "8px", backgroundColor: "#5865F2", color: "white", - padding: "10px 20px", + height: "40px", + padding: "0 20px", borderRadius: "8px", textDecoration: "none", fontWeight: "bold", marginTop: "4px", marginBottom: "1rem", + lineHeight: "40px", // fixes vertical alignment }} > - - #ask-mithril - + #ask-mithril :::note diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx index 8a73fb31819..3381073a8f9 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx @@ -65,12 +65,14 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc gap: "8px", backgroundColor: "#5865F2", color: "white", - padding: "10px 20px", + height: "40px", + padding: "0 20px", borderRadius: "8px", textDecoration: "none", fontWeight: "bold", marginTop: "4px", marginBottom: "1rem", + lineHeight: "40px", // fixes vertical alignment }} > - - #ask-mithril - + #ask-mithril :::note From 2a6ebef75e67a173ede0129630cc30a22e5d9640 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:03:36 -0700 Subject: [PATCH 04/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: Jean-Philippe Raynaud --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 3381073a8f9..1e944b45397 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -56,7 +56,7 @@ Proofs are available roughly every 30 blocks, with certification running ~100 bl Have a question during integration? Reach out in the [#ask-mithril](https://discord.com/channels/826816523368005654/1014019542504185876) channel on the IOG Discord — the team is active there and happy to help. Date: Fri, 17 Apr 2026 12:03:48 -0700 Subject: [PATCH 05/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: Jean-Philippe Raynaud --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 1e944b45397..4553bf363cb 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -53,7 +53,7 @@ Proofs are available roughly every 30 blocks, with certification running ~100 bl ### Questions? -Have a question during integration? Reach out in the [#ask-mithril](https://discord.com/channels/826816523368005654/1014019542504185876) channel on the IOG Discord — the team is active there and happy to help. +Have a question during integration? Reach out in the [#ask-mithril](https://discord.gg/5kaErDKDRq) channel on the IOG Discord — the team is active there and happy to help. Date: Fri, 17 Apr 2026 12:04:24 -0700 Subject: [PATCH 06/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 4553bf363cb..2be17ed00c8 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -4,7 +4,7 @@ title: Wallets sidebar_label: Wallets --- -# Using Mithril for Light Wallets +# Using Mithril for light wallets ## For Wallet Developers From d387a80eded74e99faefb84eb6cf9821de114e58 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:05:20 -0700 Subject: [PATCH 07/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 2be17ed00c8..6d7168a37c4 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -16,11 +16,11 @@ Cardano users expect fast, reliable confirmation that their transactions have la ::: -### What Mithril Gives Your Wallet +### What Mithril provides for wallets -When a user submits a transaction, Mithril lets you confirm it was included in the Cardano chain without running a full node and without trusting a centralized API. Instead of relying on a server telling your wallet "yes, that tx went through," you get a Merkle proof tied to a certificate signed by a quorum of SPOs weighted by stake. Your wallet verifies the proof locally. +When a user submits a transaction, Mithril verifies that it was included on the Cardano blockchain without running a full node or relying on a centralized API. Instead of depending on a server response, the wallet receives a Merkle proof linked to a certificate signed by a stake-weighted quorum of SPOs. The wallet verifies this proof locally. -For users, this means faster perceived finality — you can surface a meaningful "confirmed" state sooner, and with stronger guarantees than a block count alone provides. +For users, this provides faster perceived finality. A wallet can present a meaningful ‘confirmed’ state earlier, with stronger guarantees than relying on block confirmations alone. ### How It Fits Into Your Existing Stack From 3a869b5f0f179fa3d3a5286593af99f5ffe3fd39 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:05:35 -0700 Subject: [PATCH 08/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 6d7168a37c4..62fb1a08b70 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -22,13 +22,13 @@ When a user submits a transaction, Mithril verifies that it was included on the For users, this provides faster perceived finality. A wallet can present a meaningful ‘confirmed’ state earlier, with stronger guarantees than relying on block confirmations alone. -### How It Fits Into Your Existing Stack +### How it fits into existing stacks -Most light wallets already rely on a hosted API or indexer for balance lookups and UTxO queries — services like Blockfrost or Koios. Mithril doesn't replace that. What it adds is a trustless verification layer on top: rather than taking your data provider's word that a transaction landed, you can cryptographically confirm it against a certificate chain secured by Cardano's actual stake distribution. +Most light wallets already rely on a hosted API or indexer for balance lookups and UTXO queries, such as Blockfrost or Koios. Mithril does not replace these services. Instead, it adds a trustless verification layer: rather than relying on a data provider to confirm that a transaction was included, the wallet can verify this cryptographically against a certificate chain secured by Cardano’s stake distribution. -This matters for security. If your data provider is compromised or returns bad data, a Mithril proof will fail to verify — your wallet catches the discrepancy rather than silently showing users incorrect state. A compromised API can't fabricate a valid Mithril proof. +This improves security. If a data provider is compromised or returns incorrect data, a Mithril proof will fail to verify, allowing the wallet to detect the discrepancy instead of presenting an incorrect state. A compromised API cannot produce a valid Mithril proof. -The result is an architecture that keeps what already works while meaningfully reducing the trust your users have to place in third-party infrastructure. +The result is an architecture that preserves existing components while reducing the level of trust required in third-party infrastructure. ### Integration From 619f8e2f1141f636e15a807976e4ce5d02c129e6 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:06:25 -0700 Subject: [PATCH 09/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 62fb1a08b70..b0222651641 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -32,7 +32,7 @@ The result is an architecture that preserves existing components while reducing ### Integration -The easiest path for most wallet teams is the official WASM package: +The easiest path for most wallet teams to integrate is using the official WASM package: ```bash npm install @mithril-dev/mithril-client-wasm From 78e0817868781c9f05d594401054b724187907b9 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:06:52 -0700 Subject: [PATCH 10/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index b0222651641..fdc9a358f66 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -38,7 +38,7 @@ The easiest path for most wallet teams to integrate is using the official WASM p npm install @mithril-dev/mithril-client-wasm ``` -It works in-browser and in Node.js, covering desktop wallets, web wallets, and mobile wallets built on web technologies — iOS Safari and Android Chrome are both supported. A Rust crate is also available if you're building natively on desktop. +It works in the browser and in Node.js, supporting desktop, web, and mobile wallets built on web technologies – including iOS Safari and Android Chrome. A Rust crate is also available for native desktop applications. Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. From 4158d0043487c56f51fa9ebeac428f3efe7d2f8d Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:07:20 -0700 Subject: [PATCH 11/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index fdc9a358f66..646abc7aa4a 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -47,7 +47,7 @@ The core flow is straightforward: 1. Submit the transaction as you normally would 2. Query the Mithril aggregator for a transaction proof once the tx hash is known 3. Verify the proof against the current Mithril certificate chain -4. Surface the confirmation to the user +4. Surface the confirmation to the user. Proofs are available roughly every 30 blocks, with certification running ~100 blocks behind the tip to ensure finality. Factor this into how you communicate confirmation status to users. From bd1f5780f75a868052a75d50e971bff2f23ea07a Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:07:38 -0700 Subject: [PATCH 12/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 646abc7aa4a..23f9ad98a7c 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -49,7 +49,7 @@ The core flow is straightforward: 3. Verify the proof against the current Mithril certificate chain 4. Surface the confirmation to the user. -Proofs are available roughly every 30 blocks, with certification running ~100 blocks behind the tip to ensure finality. Factor this into how you communicate confirmation status to users. +Proofs are generated approximately every 30 blocks, with certification operating around 100 blocks behind the chain tip to ensure finality. This should be considered when presenting confirmation status to users. ### Questions? From 88eca6501c586d0bee84cb2708167242f91871d3 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Fri, 17 Apr 2026 12:08:55 -0700 Subject: [PATCH 13/25] Update docs/website/root/use-cases/wallets.mdx Co-authored-by: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> --- docs/website/root/use-cases/wallets.mdx | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 23f9ad98a7c..dc7731ef154 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -94,10 +94,11 @@ You'll need to be a member of the [IOG Discord server](https://discord.gg/5kaErD ::: -## For Wallet Users +## For wallet users -If your wallet supports Mithril, transaction confirmations are faster and more trustworthy. Rather than relying on your wallet's servers to tell you a transaction went through, Mithril provides cryptographic proof — verified against Cardano's network of stake pool operators — that your transaction is on the chain. +If a wallet supports Mithril, transaction confirmations are faster and more reliable. Instead of relying on the wallet’s servers to confirm that a transaction was included, Mithril provides a cryptographic proof, verified against Cardano’s network of stake pool operators. -In practice, this means fewer anxious minutes wondering if a payment landed, and more confidence when it says it did. +In practice, this reduces uncertainty around transaction status and provides greater confidence when a transaction is confirmed. -**Does my wallet support Mithril?** Mithril integration is still being adopted across the ecosystem. Check your wallet's release notes or documentation, or ask their support team. If you're a developer building a wallet, see the section above. +**Does my wallet support Mithril?** +Mithril integration is still being adopted across the ecosystem. Check the wallet’s release notes or documentation, or contact the support team. Developers building a wallet can refer to the section above. From 434a85da5a2c640f3260da32e4e8061c0b2b7964 Mon Sep 17 00:00:00 2001 From: dalibran Date: Fri, 17 Apr 2026 12:39:17 -0700 Subject: [PATCH 14/25] Refine Light Wallets use case page and navbar - Rename page/sidebar label to "Light wallets" (sentence case) - Move Use Cases dropdown to end of left navbar - Remove unused spoCta note about IOG Discord membership - Update browser support paragraph with compatibility link, example, and Rust crate link - Remove "For wallet developers" title casing Co-Authored-By: Claude Sonnet 4.6 --- docs/website/docusaurus.config.js | 14 +++--- docs/website/root/use-cases/wallets.mdx | 14 ++---- .../version-maintained/use-cases/wallets.mdx | 49 +++++++++---------- 3 files changed, 33 insertions(+), 44 deletions(-) diff --git a/docs/website/docusaurus.config.js b/docs/website/docusaurus.config.js index 21a2d1883f8..ec1147d3906 100644 --- a/docs/website/docusaurus.config.js +++ b/docs/website/docusaurus.config.js @@ -250,6 +250,12 @@ const config = { position: "left", label: "Manual", }, + { + type: "doc", + docId: "mithril/intro", + label: "Protocol", + position: "left", + }, { type: "dropdown", label: "Use Cases", @@ -258,16 +264,10 @@ const config = { { type: "doc", docId: "use-cases/wallets", - label: "Wallets", + label: "Light wallets", }, ], }, - { - type: "doc", - docId: "mithril/intro", - label: "Protocol", - position: "left", - }, { type: "docsVersionDropdown", position: "right", diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index dc7731ef154..05d13e36fc0 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -1,12 +1,12 @@ --- id: wallets -title: Wallets -sidebar_label: Wallets +title: Light Wallets +sidebar_label: Light wallets --- # Using Mithril for light wallets -## For Wallet Developers +## For wallet developers Cardano users expect fast, reliable confirmation that their transactions have landed. Traditionally, delivering that required either running a full node or trusting a third-party service. Mithril offers a third option: cryptographic proof of transaction inclusion, backed by Cardano's stake pool operators, that any wallet can verify independently. @@ -38,7 +38,7 @@ The easiest path for most wallet teams to integrate is using the official WASM p npm install @mithril-dev/mithril-client-wasm ``` -It works in the browser and in Node.js, supporting desktop, web, and mobile wallets built on web technologies – including iOS Safari and Android Chrome. A Rust crate is also available for native desktop applications. +It works in the browser and in Node.js. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [browser integration example](https://github.com/input-output-hk/mithril/tree/main/examples/client-wasm-web) is available if you want to see it in action. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native desktop applications. Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. @@ -88,12 +88,6 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc #ask-mithril -:::note - -You'll need to be a member of the [IOG Discord server](https://discord.gg/5kaErDKDRq) to access this channel. - -::: - ## For wallet users If a wallet supports Mithril, transaction confirmations are faster and more reliable. Instead of relying on the wallet’s servers to confirm that a transaction was included, Mithril provides a cryptographic proof, verified against Cardano’s network of stake pool operators. diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx index 3381073a8f9..05d13e36fc0 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx @@ -1,12 +1,12 @@ --- id: wallets -title: Wallets -sidebar_label: Wallets +title: Light Wallets +sidebar_label: Light wallets --- -# Using Mithril for Light Wallets +# Using Mithril for light wallets -## For Wallet Developers +## For wallet developers Cardano users expect fast, reliable confirmation that their transactions have landed. Traditionally, delivering that required either running a full node or trusting a third-party service. Mithril offers a third option: cryptographic proof of transaction inclusion, backed by Cardano's stake pool operators, that any wallet can verify independently. @@ -16,29 +16,29 @@ Cardano users expect fast, reliable confirmation that their transactions have la ::: -### What Mithril Gives Your Wallet +### What Mithril provides for wallets -When a user submits a transaction, Mithril lets you confirm it was included in the Cardano chain without running a full node and without trusting a centralized API. Instead of relying on a server telling your wallet "yes, that tx went through," you get a Merkle proof tied to a certificate signed by a quorum of SPOs weighted by stake. Your wallet verifies the proof locally. +When a user submits a transaction, Mithril verifies that it was included on the Cardano blockchain without running a full node or relying on a centralized API. Instead of depending on a server response, the wallet receives a Merkle proof linked to a certificate signed by a stake-weighted quorum of SPOs. The wallet verifies this proof locally. -For users, this means faster perceived finality — you can surface a meaningful "confirmed" state sooner, and with stronger guarantees than a block count alone provides. +For users, this provides faster perceived finality. A wallet can present a meaningful ‘confirmed’ state earlier, with stronger guarantees than relying on block confirmations alone. -### How It Fits Into Your Existing Stack +### How it fits into existing stacks -Most light wallets already rely on a hosted API or indexer for balance lookups and UTxO queries — services like Blockfrost or Koios. Mithril doesn't replace that. What it adds is a trustless verification layer on top: rather than taking your data provider's word that a transaction landed, you can cryptographically confirm it against a certificate chain secured by Cardano's actual stake distribution. +Most light wallets already rely on a hosted API or indexer for balance lookups and UTXO queries, such as Blockfrost or Koios. Mithril does not replace these services. Instead, it adds a trustless verification layer: rather than relying on a data provider to confirm that a transaction was included, the wallet can verify this cryptographically against a certificate chain secured by Cardano’s stake distribution. -This matters for security. If your data provider is compromised or returns bad data, a Mithril proof will fail to verify — your wallet catches the discrepancy rather than silently showing users incorrect state. A compromised API can't fabricate a valid Mithril proof. +This improves security. If a data provider is compromised or returns incorrect data, a Mithril proof will fail to verify, allowing the wallet to detect the discrepancy instead of presenting an incorrect state. A compromised API cannot produce a valid Mithril proof. -The result is an architecture that keeps what already works while meaningfully reducing the trust your users have to place in third-party infrastructure. +The result is an architecture that preserves existing components while reducing the level of trust required in third-party infrastructure. ### Integration -The easiest path for most wallet teams is the official WASM package: +The easiest path for most wallet teams to integrate is using the official WASM package: ```bash npm install @mithril-dev/mithril-client-wasm ``` -It works in-browser and in Node.js, covering desktop wallets, web wallets, and mobile wallets built on web technologies — iOS Safari and Android Chrome are both supported. A Rust crate is also available if you're building natively on desktop. +It works in the browser and in Node.js. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [browser integration example](https://github.com/input-output-hk/mithril/tree/main/examples/client-wasm-web) is available if you want to see it in action. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native desktop applications. Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. @@ -47,16 +47,16 @@ The core flow is straightforward: 1. Submit the transaction as you normally would 2. Query the Mithril aggregator for a transaction proof once the tx hash is known 3. Verify the proof against the current Mithril certificate chain -4. Surface the confirmation to the user +4. Surface the confirmation to the user. -Proofs are available roughly every 30 blocks, with certification running ~100 blocks behind the tip to ensure finality. Factor this into how you communicate confirmation status to users. +Proofs are generated approximately every 30 blocks, with certification operating around 100 blocks behind the chain tip to ensure finality. This should be considered when presenting confirmation status to users. ### Questions? -Have a question during integration? Reach out in the [#ask-mithril](https://discord.com/channels/826816523368005654/1014019542504185876) channel on the IOG Discord — the team is active there and happy to help. +Have a question during integration? Reach out in the [#ask-mithril](https://discord.gg/5kaErDKDRq) channel on the IOG Discord — the team is active there and happy to help. #ask-mithril -:::note +## For wallet users -You'll need to be a member of the [IOG Discord server](https://discord.gg/5kaErDKDRq) to access this channel. +If a wallet supports Mithril, transaction confirmations are faster and more reliable. Instead of relying on the wallet’s servers to confirm that a transaction was included, Mithril provides a cryptographic proof, verified against Cardano’s network of stake pool operators. -::: - -## For Wallet Users - -If your wallet supports Mithril, transaction confirmations are faster and more trustworthy. Rather than relying on your wallet's servers to tell you a transaction went through, Mithril provides cryptographic proof — verified against Cardano's network of stake pool operators — that your transaction is on the chain. - -In practice, this means fewer anxious minutes wondering if a payment landed, and more confidence when it says it did. +In practice, this reduces uncertainty around transaction status and provides greater confidence when a transaction is confirmed. -**Does my wallet support Mithril?** Mithril integration is still being adopted across the ecosystem. Check your wallet's release notes or documentation, or ask their support team. If you're a developer building a wallet, see the section above. +**Does my wallet support Mithril?** +Mithril integration is still being adopted across the ecosystem. Check the wallet’s release notes or documentation, or contact the support team. Developers building a wallet can refer to the section above. From 240fd882ede365955a39750e082b2e87606617ee Mon Sep 17 00:00:00 2001 From: dalibran Date: Thu, 23 Apr 2026 08:16:44 -0700 Subject: [PATCH 15/25] Trim wallet page security admonition and mobile bindings note Remove specific security caveat content from the caution admonition, replacing it with a neutral info admonition pointing to the Protocol security page. Drop the Swift/Kotlin mobile bindings paragraph. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/root/use-cases/wallets.mdx | 6 ++---- .../versioned_docs/version-maintained/use-cases/wallets.mdx | 6 ++---- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets.mdx index 05d13e36fc0..089908765e1 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets.mdx @@ -10,9 +10,9 @@ sidebar_label: Light wallets Cardano users expect fast, reliable confirmation that their transactions have landed. Traditionally, delivering that required either running a full node or trusting a third-party service. Mithril offers a third option: cryptographic proof of transaction inclusion, backed by Cardano's stake pool operators, that any wallet can verify independently. -:::caution +:::info -**The Mithril client library is production-ready code, but we recommend caution before deploying certificate verification in a production wallet.** Protocol security guarantees are proportional to stake participation — until the Mithril signer achieves sufficient coverage across the SPO ecosystem, there is a risk that certificates could be compromised. The greater the stake participation, the stronger the guarantees. +Before integrating, review the [Protocol security](/mithril/advanced/mithril-protocol/security) page to understand the protocol's guarantees. ::: @@ -40,8 +40,6 @@ npm install @mithril-dev/mithril-client-wasm It works in the browser and in Node.js. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [browser integration example](https://github.com/input-output-hk/mithril/tree/main/examples/client-wasm-web) is available if you want to see it in action. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native desktop applications. -Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. - The core flow is straightforward: 1. Submit the transaction as you normally would diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx index 05d13e36fc0..089908765e1 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx @@ -10,9 +10,9 @@ sidebar_label: Light wallets Cardano users expect fast, reliable confirmation that their transactions have landed. Traditionally, delivering that required either running a full node or trusting a third-party service. Mithril offers a third option: cryptographic proof of transaction inclusion, backed by Cardano's stake pool operators, that any wallet can verify independently. -:::caution +:::info -**The Mithril client library is production-ready code, but we recommend caution before deploying certificate verification in a production wallet.** Protocol security guarantees are proportional to stake participation — until the Mithril signer achieves sufficient coverage across the SPO ecosystem, there is a risk that certificates could be compromised. The greater the stake participation, the stronger the guarantees. +Before integrating, review the [Protocol security](/mithril/advanced/mithril-protocol/security) page to understand the protocol's guarantees. ::: @@ -40,8 +40,6 @@ npm install @mithril-dev/mithril-client-wasm It works in the browser and in Node.js. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [browser integration example](https://github.com/input-output-hk/mithril/tree/main/examples/client-wasm-web) is available if you want to see it in action. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native desktop applications. -Native mobile bindings for Swift and Kotlin are not yet available, but are on the roadmap. If you're building a native iOS or Android wallet and want to get ahead of this, reach out — the underlying C libraries are already being compiled as part of the build. - The core flow is straightforward: 1. Submit the transaction as you normally would From f8c07fd6c8a3e2977f06e6fe0ed5588159c181a7 Mon Sep 17 00:00:00 2001 From: dalibran Date: Wed, 13 May 2026 15:08:36 +0900 Subject: [PATCH 16/25] docs(website): add Bridges use case page Adds a Bridges page under Use Cases following the same structure as Light wallets. Wires it into the Use Cases navbar dropdown and mirrors the page into the maintained docs version. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/docusaurus.config.js | 5 + docs/website/root/use-cases/bridges.mdx | 98 +++++++++++++++++++ .../version-maintained/use-cases/bridges.mdx | 98 +++++++++++++++++++ 3 files changed, 201 insertions(+) create mode 100644 docs/website/root/use-cases/bridges.mdx create mode 100644 docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx diff --git a/docs/website/docusaurus.config.js b/docs/website/docusaurus.config.js index ec1147d3906..fb24a1cdc7d 100644 --- a/docs/website/docusaurus.config.js +++ b/docs/website/docusaurus.config.js @@ -266,6 +266,11 @@ const config = { docId: "use-cases/wallets", label: "Light wallets", }, + { + type: "doc", + docId: "use-cases/bridges", + label: "Bridges", + }, ], }, { diff --git a/docs/website/root/use-cases/bridges.mdx b/docs/website/root/use-cases/bridges.mdx new file mode 100644 index 00000000000..1ed0c35ff18 --- /dev/null +++ b/docs/website/root/use-cases/bridges.mdx @@ -0,0 +1,98 @@ +--- +id: bridges +title: Bridges +sidebar_label: Bridges +--- + +# Using Mithril for bridges + +## For bridge developers + +A bridge is only as secure as the data it acts on. When a relayer or validator authorizes a mint on a destination chain, it is asserting that a corresponding lock or burn really happened on Cardano. Today, bridges learn about Cardano state in one of a few ways: by querying a centralized API, by relying on a federation of trusted nodes, or by running a full Cardano node. The first two options place trust in infrastructure that can be compromised, and a compromise can lead to unauthorized mints. Running a full node avoids that trust assumption, but at a real cost: a fully synced Cardano node requires substantial compute, storage, and ongoing operational effort. + +Mithril offers a fourth option: cryptographic proof that a Cardano transaction was included, backed by a stake-weighted quorum of SPOs, that the bridge can verify independently — without trusting a third party, and without operating a full node. + +:::info + +Before integrating, review the [Protocol security](/mithril/advanced/mithril-protocol/security) page to understand the protocol's guarantees. + +::: + +### What Mithril provides for bridges + +When a user locks assets on Cardano, the bridge needs to confirm that the lock transaction was included on-chain before authorizing the corresponding action on the destination chain. With Mithril, the bridge can verify this using a Merkle proof linked to a certificate signed by a stake-weighted quorum of SPOs. The proof can be checked locally, without trusting the source of the data. + +This changes the bridge's security posture. The integrity of cross-chain transfers no longer depends on the honesty of any single data provider or on the operational security of any one node. A compromised API, a misconfigured indexer, or a hostile relayer cannot produce a valid Mithril proof — and a bridge that verifies proofs will reject anything that fails verification. + +Crucially, the bridge gets this assurance from a lightweight client. The proof is fetched and verified on demand, with no full Cardano node to sync, store, or operate. For bridge teams, that means the most secure verification path is also the cheapest one — there is no longer a trade-off between trust assumptions and infrastructure overhead. + +### How it fits into existing bridge architectures + +Most bridges have an off-chain component — relayers, validators, or watchers — that observes events on the source chain and submits attestations to the destination chain. Mithril does not replace this component. It strengthens it: instead of trusting whatever endpoint the relayer happens to query, the relayer verifies a Mithril proof against the current certificate chain before treating a Cardano transaction as final. + +This preserves the existing architecture while removing the implicit trust placed in centralized infrastructure. For bridge designs that already rely on a multi-signature or threshold scheme among relayers, Mithril provides an additional, independent check rooted in Cardano's stake distribution — making collusion among relayers insufficient to forge a transfer if proofs are verified. + +### Integration + +The easiest path for most bridge teams to integrate is using the official WASM package: + +```bash +npm install @mithril-dev/mithril-client-wasm +``` + +It works in Node.js and in the browser, making it suitable for relayers, monitoring services, and validator software. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native services. + +The core flow is straightforward: + +1. Observe the lock or burn transaction on Cardano +2. Query the Mithril aggregator for a transaction proof once the tx hash is known +3. Verify the proof against the current Mithril certificate chain +4. Treat the transaction as final and authorize the corresponding action on the destination chain. + +Proofs are generated approximately every 30 blocks, with certification operating around 100 blocks behind the chain tip to ensure finality. Bridge teams should factor this into their finality model and user-facing expectations around transfer latency. + +### Questions? + +Have a question during integration? Reach out in the [#ask-mithril](https://discord.gg/5kaErDKDRq) channel on the IOG Discord — the team is active there and happy to help. + + + + + + #ask-mithril + + +## For bridge users + +When a bridge supports Mithril, cross-chain transfers from Cardano are more secure. Whether you interact with the bridge directly, or through a wallet or aggregator that abstracts the swap behind a simpler interface, the underlying assertion is the same: that your Cardano transaction was actually included on-chain before the bridge took action on the other side. + +With Mithril, that assertion is backed by a cryptographic proof signed by a stake-weighted quorum of Cardano's stake pool operators, rather than by the bridge's own infrastructure. This means a transfer cannot be authorized on the basis of a compromised API, a faulty indexer, or a single dishonest operator — the proof would simply fail to verify. + +**Does my bridge support Mithril?** +Mithril integration is still being adopted across the ecosystem. Check the bridge's release notes or documentation, or contact the support team. Developers building a bridge can refer to the section above. diff --git a/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx b/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx new file mode 100644 index 00000000000..1ed0c35ff18 --- /dev/null +++ b/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx @@ -0,0 +1,98 @@ +--- +id: bridges +title: Bridges +sidebar_label: Bridges +--- + +# Using Mithril for bridges + +## For bridge developers + +A bridge is only as secure as the data it acts on. When a relayer or validator authorizes a mint on a destination chain, it is asserting that a corresponding lock or burn really happened on Cardano. Today, bridges learn about Cardano state in one of a few ways: by querying a centralized API, by relying on a federation of trusted nodes, or by running a full Cardano node. The first two options place trust in infrastructure that can be compromised, and a compromise can lead to unauthorized mints. Running a full node avoids that trust assumption, but at a real cost: a fully synced Cardano node requires substantial compute, storage, and ongoing operational effort. + +Mithril offers a fourth option: cryptographic proof that a Cardano transaction was included, backed by a stake-weighted quorum of SPOs, that the bridge can verify independently — without trusting a third party, and without operating a full node. + +:::info + +Before integrating, review the [Protocol security](/mithril/advanced/mithril-protocol/security) page to understand the protocol's guarantees. + +::: + +### What Mithril provides for bridges + +When a user locks assets on Cardano, the bridge needs to confirm that the lock transaction was included on-chain before authorizing the corresponding action on the destination chain. With Mithril, the bridge can verify this using a Merkle proof linked to a certificate signed by a stake-weighted quorum of SPOs. The proof can be checked locally, without trusting the source of the data. + +This changes the bridge's security posture. The integrity of cross-chain transfers no longer depends on the honesty of any single data provider or on the operational security of any one node. A compromised API, a misconfigured indexer, or a hostile relayer cannot produce a valid Mithril proof — and a bridge that verifies proofs will reject anything that fails verification. + +Crucially, the bridge gets this assurance from a lightweight client. The proof is fetched and verified on demand, with no full Cardano node to sync, store, or operate. For bridge teams, that means the most secure verification path is also the cheapest one — there is no longer a trade-off between trust assumptions and infrastructure overhead. + +### How it fits into existing bridge architectures + +Most bridges have an off-chain component — relayers, validators, or watchers — that observes events on the source chain and submits attestations to the destination chain. Mithril does not replace this component. It strengthens it: instead of trusting whatever endpoint the relayer happens to query, the relayer verifies a Mithril proof against the current certificate chain before treating a Cardano transaction as final. + +This preserves the existing architecture while removing the implicit trust placed in centralized infrastructure. For bridge designs that already rely on a multi-signature or threshold scheme among relayers, Mithril provides an additional, independent check rooted in Cardano's stake distribution — making collusion among relayers insufficient to forge a transfer if proofs are verified. + +### Integration + +The easiest path for most bridge teams to integrate is using the official WASM package: + +```bash +npm install @mithril-dev/mithril-client-wasm +``` + +It works in Node.js and in the browser, making it suitable for relayers, monitoring services, and validator software. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native services. + +The core flow is straightforward: + +1. Observe the lock or burn transaction on Cardano +2. Query the Mithril aggregator for a transaction proof once the tx hash is known +3. Verify the proof against the current Mithril certificate chain +4. Treat the transaction as final and authorize the corresponding action on the destination chain. + +Proofs are generated approximately every 30 blocks, with certification operating around 100 blocks behind the chain tip to ensure finality. Bridge teams should factor this into their finality model and user-facing expectations around transfer latency. + +### Questions? + +Have a question during integration? Reach out in the [#ask-mithril](https://discord.gg/5kaErDKDRq) channel on the IOG Discord — the team is active there and happy to help. + + + + + + #ask-mithril + + +## For bridge users + +When a bridge supports Mithril, cross-chain transfers from Cardano are more secure. Whether you interact with the bridge directly, or through a wallet or aggregator that abstracts the swap behind a simpler interface, the underlying assertion is the same: that your Cardano transaction was actually included on-chain before the bridge took action on the other side. + +With Mithril, that assertion is backed by a cryptographic proof signed by a stake-weighted quorum of Cardano's stake pool operators, rather than by the bridge's own infrastructure. This means a transfer cannot be authorized on the basis of a compromised API, a faulty indexer, or a single dishonest operator — the proof would simply fail to verify. + +**Does my bridge support Mithril?** +Mithril integration is still being adopted across the ecosystem. Check the bridge's release notes or documentation, or contact the support team. Developers building a bridge can refer to the section above. From 4fc11d0592124b9c365b14659ebe7a1df8951172 Mon Sep 17 00:00:00 2001 From: dalibran Date: Wed, 13 May 2026 15:55:58 +0900 Subject: [PATCH 17/25] docs(website): add Daedalus case study page Introduce a Case Studies docs section with a Daedalus entry covering Mithril-based initial sync, including navbar dropdown, sidebar, and wordmark styling. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/docusaurus.config.js | 12 ++ docs/website/root/case-studies/daedalus.mdx | 46 ++++++++ docs/website/sidebars.js | 6 + docs/website/src/css/custom.css | 6 + docs/website/static/img/daedalus-logo.svg | 105 ++++++++++++++++++ .../case-studies/daedalus.mdx | 46 ++++++++ 6 files changed, 221 insertions(+) create mode 100644 docs/website/root/case-studies/daedalus.mdx create mode 100644 docs/website/static/img/daedalus-logo.svg create mode 100644 docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx diff --git a/docs/website/docusaurus.config.js b/docs/website/docusaurus.config.js index fb24a1cdc7d..10dc851f2bc 100644 --- a/docs/website/docusaurus.config.js +++ b/docs/website/docusaurus.config.js @@ -273,6 +273,18 @@ const config = { }, ], }, + { + type: "dropdown", + label: "Case Studies", + position: "left", + items: [ + { + type: "doc", + docId: "case-studies/daedalus", + label: "Daedalus", + }, + ], + }, { type: "docsVersionDropdown", position: "right", diff --git a/docs/website/root/case-studies/daedalus.mdx b/docs/website/root/case-studies/daedalus.mdx new file mode 100644 index 00000000000..d64e89245a1 --- /dev/null +++ b/docs/website/root/case-studies/daedalus.mdx @@ -0,0 +1,46 @@ +--- +id: daedalus +title: Daedalus +sidebar_label: Daedalus +--- + +# Daedalus: faster initial sync with Mithril + +
+ Daedalus logo +
+ Daedalus Wallet +
+
+ +[Daedalus](https://daedaluswallet.io/) is a full-node Cardano wallet, supported by Input Output. In its 8.0.0 release, Daedalus integrated Mithril bootstrapping to dramatically reduce the time required for a fresh installation to start using the wallet for the first time. + +## The problem + +Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this takes many hours and significant bandwidth — historically a major friction point for users picking up a full-node wallet. + +## How Mithril helps + +Fresh installations of Daedalus now download a Mithril-certified snapshot of the Cardano node database and restore it locally, rather than replaying the chain. The snapshot's integrity is verified against the Mithril certificate chain, anchored in Cardano's stake distribution — so users get the same trust guarantees as a chain-replayed node, without the wait. + +## What's next + +The current integration covers fresh installations. Partial sync resumption via Mithril — using snapshots to fast-forward a wallet that has been offline for a while — is planned for a future release. diff --git a/docs/website/sidebars.js b/docs/website/sidebars.js index 88d385784ea..16cd394e676 100644 --- a/docs/website/sidebars.js +++ b/docs/website/sidebars.js @@ -30,6 +30,12 @@ const sidebars = { dirName: "use-cases", }, ], + caseStudiesSideBar: [ + { + type: "autogenerated", + dirName: "case-studies", + }, + ], }; module.exports = sidebars; diff --git a/docs/website/src/css/custom.css b/docs/website/src/css/custom.css index 001688f91fc..ad9cc0f9de2 100644 --- a/docs/website/src/css/custom.css +++ b/docs/website/src/css/custom.css @@ -15,6 +15,8 @@ @tailwind components; @tailwind utilities; +@import url("https://fonts.googleapis.com/css2?family=Montserrat:wght@300;600&display=swap"); + @font-face { font-family: "Lexend"; font-weight: 400; @@ -259,6 +261,10 @@ a.menu__link { margin-bottom: 1.5rem; } +.markdown .daedalus-wordmark p { + margin-bottom: 0; +} + .markdown a { text-decoration: underline; text-underline-offset: 2px; diff --git a/docs/website/static/img/daedalus-logo.svg b/docs/website/static/img/daedalus-logo.svg new file mode 100644 index 00000000000..4ebeab907ee --- /dev/null +++ b/docs/website/static/img/daedalus-logo.svg @@ -0,0 +1,105 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx new file mode 100644 index 00000000000..d64e89245a1 --- /dev/null +++ b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx @@ -0,0 +1,46 @@ +--- +id: daedalus +title: Daedalus +sidebar_label: Daedalus +--- + +# Daedalus: faster initial sync with Mithril + +
+ Daedalus logo +
+ Daedalus Wallet +
+
+ +[Daedalus](https://daedaluswallet.io/) is a full-node Cardano wallet, supported by Input Output. In its 8.0.0 release, Daedalus integrated Mithril bootstrapping to dramatically reduce the time required for a fresh installation to start using the wallet for the first time. + +## The problem + +Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this takes many hours and significant bandwidth — historically a major friction point for users picking up a full-node wallet. + +## How Mithril helps + +Fresh installations of Daedalus now download a Mithril-certified snapshot of the Cardano node database and restore it locally, rather than replaying the chain. The snapshot's integrity is verified against the Mithril certificate chain, anchored in Cardano's stake distribution — so users get the same trust guarantees as a chain-replayed node, without the wait. + +## What's next + +The current integration covers fresh installations. Partial sync resumption via Mithril — using snapshots to fast-forward a wallet that has been offline for a while — is planned for a future release. From 62dde8c9b6ce00cd3e2c3233b52ad440b3dfda96 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Thu, 14 May 2026 15:56:57 +0900 Subject: [PATCH 18/25] Update docs/website/root/case-studies/daedalus.mdx Co-authored-by: Jean-Philippe Raynaud --- docs/website/root/case-studies/daedalus.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/case-studies/daedalus.mdx b/docs/website/root/case-studies/daedalus.mdx index d64e89245a1..7abc99e2f66 100644 --- a/docs/website/root/case-studies/daedalus.mdx +++ b/docs/website/root/case-studies/daedalus.mdx @@ -35,7 +35,7 @@ sidebar_label: Daedalus ## The problem -Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this takes many hours and significant bandwidth — historically a major friction point for users picking up a full-node wallet. +Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this usually takes more than 24-36 hours — historically a major friction point for users picking up a full-node wallet. ## How Mithril helps From e2ae6805fa716196d98cea4e49aa400c1f6b1b51 Mon Sep 17 00:00:00 2001 From: Dana Alibrandi <2665651+dalibran@users.noreply.github.com> Date: Thu, 14 May 2026 15:57:32 +0900 Subject: [PATCH 19/25] Update docs/website/root/use-cases/bridges.mdx Co-authored-by: Jean-Philippe Raynaud --- docs/website/root/use-cases/bridges.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/website/root/use-cases/bridges.mdx b/docs/website/root/use-cases/bridges.mdx index 1ed0c35ff18..9fb35d71e99 100644 --- a/docs/website/root/use-cases/bridges.mdx +++ b/docs/website/root/use-cases/bridges.mdx @@ -45,7 +45,7 @@ It works in Node.js and in the browser, making it suitable for relayers, monitor The core flow is straightforward: 1. Observe the lock or burn transaction on Cardano -2. Query the Mithril aggregator for a transaction proof once the tx hash is known +2. Query the Mithril aggregator for a transaction proof of membership once the transation hash is known 3. Verify the proof against the current Mithril certificate chain 4. Treat the transaction as final and authorize the corresponding action on the destination chain. From 63e0d0de5f71d1316911746f809a7043c2a01afe Mon Sep 17 00:00:00 2001 From: dalibran Date: Thu, 14 May 2026 16:57:48 +0900 Subject: [PATCH 20/25] docs(website): restructure Wallets use case with card landing Replace the standalone Light Wallets page with a Wallets landing that introduces both wallet shapes and surfaces the Light wallets integration guide and the Daedalus case study as cards. Merge the separate Case Studies section into Use Cases so the Daedalus study lives under Wallets in the sidebar. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/docusaurus.config.js | 16 +----- docs/website/root/case-studies/daedalus.mdx | 2 +- docs/website/root/use-cases/wallets/index.mdx | 34 ++++++++++++ .../light-wallets.mdx} | 4 +- docs/website/sidebars.js | 17 +++--- docs/website/src/css/custom.css | 54 +++++++++++++++++++ .../case-studies/daedalus.mdx | 2 +- .../use-cases/wallets/index.mdx | 34 ++++++++++++ .../light-wallets.mdx} | 4 +- .../version-maintained-sidebars.json | 13 +++-- 10 files changed, 149 insertions(+), 31 deletions(-) create mode 100644 docs/website/root/use-cases/wallets/index.mdx rename docs/website/root/use-cases/{wallets.mdx => wallets/light-wallets.mdx} (99%) create mode 100644 docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx rename docs/website/versioned_docs/version-maintained/use-cases/{wallets.mdx => wallets/light-wallets.mdx} (99%) diff --git a/docs/website/docusaurus.config.js b/docs/website/docusaurus.config.js index 10dc851f2bc..908ace2ce07 100644 --- a/docs/website/docusaurus.config.js +++ b/docs/website/docusaurus.config.js @@ -263,8 +263,8 @@ const config = { items: [ { type: "doc", - docId: "use-cases/wallets", - label: "Light wallets", + docId: "use-cases/wallets/index", + label: "Wallets", }, { type: "doc", @@ -273,18 +273,6 @@ const config = { }, ], }, - { - type: "dropdown", - label: "Case Studies", - position: "left", - items: [ - { - type: "doc", - docId: "case-studies/daedalus", - label: "Daedalus", - }, - ], - }, { type: "docsVersionDropdown", position: "right", diff --git a/docs/website/root/case-studies/daedalus.mdx b/docs/website/root/case-studies/daedalus.mdx index 7abc99e2f66..9e4dc76b3ca 100644 --- a/docs/website/root/case-studies/daedalus.mdx +++ b/docs/website/root/case-studies/daedalus.mdx @@ -1,7 +1,7 @@ --- id: daedalus title: Daedalus -sidebar_label: Daedalus +sidebar_label: "Case Study: Daedalus Wallet" --- # Daedalus: faster initial sync with Mithril diff --git a/docs/website/root/use-cases/wallets/index.mdx b/docs/website/root/use-cases/wallets/index.mdx new file mode 100644 index 00000000000..24d7409f9e2 --- /dev/null +++ b/docs/website/root/use-cases/wallets/index.mdx @@ -0,0 +1,34 @@ +--- +title: Wallets +sidebar_label: Wallets +--- + +import Link from '@docusaurus/Link'; + +# Mithril for wallets + +Cardano wallets come in two broad shapes: **light wallets** that delegate ledger storage to hosted infrastructure, and **full-node wallets** that run a Cardano node locally. Mithril improves user experience for both — in different ways. + +For **light wallets**, Mithril enables trustless verification of transaction inclusion. Instead of trusting a hosted API response, a wallet verifies a stake-weighted Mithril proof locally — preserving familiar infrastructure while adding a cryptographic guarantee. + +For **full-node wallets**, Mithril dramatically shortens the time to a usable wallet on first install. Rather than replaying the chain from genesis, the wallet bootstraps from a Mithril-certified snapshot of the Cardano node database, with the same trust guarantees as a chain-replayed node. + +
+ +
+

Light wallets

+

An integration guide for light wallets

+
+ + +
+

Daedalus Wallet

+

A full-node wallet case study

+
+ Daedalus + +
diff --git a/docs/website/root/use-cases/wallets.mdx b/docs/website/root/use-cases/wallets/light-wallets.mdx similarity index 99% rename from docs/website/root/use-cases/wallets.mdx rename to docs/website/root/use-cases/wallets/light-wallets.mdx index 089908765e1..17183e438e3 100644 --- a/docs/website/root/use-cases/wallets.mdx +++ b/docs/website/root/use-cases/wallets/light-wallets.mdx @@ -1,6 +1,6 @@ --- -id: wallets -title: Light Wallets +id: light-wallets +title: Light wallets sidebar_label: Light wallets --- diff --git a/docs/website/sidebars.js b/docs/website/sidebars.js index 16cd394e676..7eeb3590489 100644 --- a/docs/website/sidebars.js +++ b/docs/website/sidebars.js @@ -26,15 +26,16 @@ const sidebars = { ], useCasesSideBar: [ { - type: "autogenerated", - dirName: "use-cases", - }, - ], - caseStudiesSideBar: [ - { - type: "autogenerated", - dirName: "case-studies", + type: "category", + label: "Wallets", + link: { type: "doc", id: "use-cases/wallets/index" }, + collapsed: false, + items: [ + { type: "doc", id: "use-cases/wallets/light-wallets" }, + { type: "doc", label: "Case Study: Daedalus Wallet", id: "case-studies/daedalus"}, + ], }, + { type: "doc", id: "use-cases/bridges" }, ], }; diff --git a/docs/website/src/css/custom.css b/docs/website/src/css/custom.css index ad9cc0f9de2..2305d074422 100644 --- a/docs/website/src/css/custom.css +++ b/docs/website/src/css/custom.css @@ -265,6 +265,60 @@ a.menu__link { margin-bottom: 0; } +.wallet-card-grid { + display: grid; + grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); + gap: 1rem; + margin: 2rem 0; +} + +.wallet-card { + display: flex; + align-items: center; + justify-content: space-between; + gap: 1rem; + padding: 1.25rem 1.5rem; + border: 1px solid var(--ifm-color-emphasis-200); + border-radius: 0.5rem; + color: inherit; + background: var(--ifm-card-background-color, var(--ifm-background-surface-color)); + transition: border-color 0.15s ease, transform 0.15s ease, box-shadow 0.15s ease; +} + +.markdown .wallet-card, +.markdown .wallet-card:hover { + text-decoration: none; +} + +.wallet-card:hover { + border-color: var(--ifm-color-primary); + transform: translateY(-1px); + box-shadow: 0 4px 12px var(--ifm-color-emphasis-200); +} + +.wallet-card__content { + flex: 1; + min-width: 0; +} + +.wallet-card__content h3 { + margin: 0 0 0.25rem; + font-size: 1.125rem; + font-weight: 600; +} + +.wallet-card__content p { + margin: 0; + color: var(--ifm-color-emphasis-700); + font-size: 0.9375rem; +} + +.wallet-card__logo { + flex-shrink: 0; + width: 70px; + height: auto; +} + .markdown a { text-decoration: underline; text-underline-offset: 2px; diff --git a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx index d64e89245a1..6caba2d333f 100644 --- a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx +++ b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx @@ -1,7 +1,7 @@ --- id: daedalus title: Daedalus -sidebar_label: Daedalus +sidebar_label: "Case Study: Daedalus Wallet" --- # Daedalus: faster initial sync with Mithril diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx new file mode 100644 index 00000000000..24d7409f9e2 --- /dev/null +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx @@ -0,0 +1,34 @@ +--- +title: Wallets +sidebar_label: Wallets +--- + +import Link from '@docusaurus/Link'; + +# Mithril for wallets + +Cardano wallets come in two broad shapes: **light wallets** that delegate ledger storage to hosted infrastructure, and **full-node wallets** that run a Cardano node locally. Mithril improves user experience for both — in different ways. + +For **light wallets**, Mithril enables trustless verification of transaction inclusion. Instead of trusting a hosted API response, a wallet verifies a stake-weighted Mithril proof locally — preserving familiar infrastructure while adding a cryptographic guarantee. + +For **full-node wallets**, Mithril dramatically shortens the time to a usable wallet on first install. Rather than replaying the chain from genesis, the wallet bootstraps from a Mithril-certified snapshot of the Cardano node database, with the same trust guarantees as a chain-replayed node. + +
+ +
+

Light wallets

+

An integration guide for light wallets

+
+ + +
+

Daedalus Wallet

+

A full-node wallet case study

+
+ Daedalus + +
diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets/light-wallets.mdx similarity index 99% rename from docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx rename to docs/website/versioned_docs/version-maintained/use-cases/wallets/light-wallets.mdx index 089908765e1..17183e438e3 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/wallets.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets/light-wallets.mdx @@ -1,6 +1,6 @@ --- -id: wallets -title: Light Wallets +id: light-wallets +title: Light wallets sidebar_label: Light wallets --- diff --git a/docs/website/versioned_sidebars/version-maintained-sidebars.json b/docs/website/versioned_sidebars/version-maintained-sidebars.json index 4f3a637c139..04c374d5b35 100644 --- a/docs/website/versioned_sidebars/version-maintained-sidebars.json +++ b/docs/website/versioned_sidebars/version-maintained-sidebars.json @@ -23,8 +23,15 @@ ], "useCasesSideBar": [ { - "type": "autogenerated", - "dirName": "use-cases" - } + "type": "category", + "label": "Wallets", + "link": { "type": "doc", "id": "use-cases/wallets/index" }, + "collapsed": false, + "items": [ + { "type": "doc", "id": "use-cases/wallets/light-wallets" }, + { "type": "doc", "id": "case-studies/daedalus", "label": "Case Study: Daedalus Wallet" } + ] + }, + { "type": "doc", "id": "use-cases/bridges" } ] } From 54abbc4ac37231ea14155ab26e0a5581ab3c9a5c Mon Sep 17 00:00:00 2001 From: dalibran Date: Wed, 20 May 2026 16:25:44 +0900 Subject: [PATCH 21/25] docs(website): refine bridges page integration guidance and finality framing Apply lead-dev review feedback: promote Rust client library and CLI as the primary integration path (with WASM scoped to browser-facing components), rework the finality framing so it's clear the bridge sets its own confirmation threshold under both current and upcoming Mithril certification, tighten the "compromised provider" clause to name the concrete consequence, and clarify the user-facing "aggregator" term with a 1inch example. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/root/use-cases/bridges.mdx | 20 +++++++++---------- .../version-maintained/use-cases/bridges.mdx | 20 +++++++++---------- 2 files changed, 18 insertions(+), 22 deletions(-) diff --git a/docs/website/root/use-cases/bridges.mdx b/docs/website/root/use-cases/bridges.mdx index 9fb35d71e99..c9796747028 100644 --- a/docs/website/root/use-cases/bridges.mdx +++ b/docs/website/root/use-cases/bridges.mdx @@ -22,34 +22,32 @@ Before integrating, review the [Protocol security](/mithril/advanced/mithril-pro When a user locks assets on Cardano, the bridge needs to confirm that the lock transaction was included on-chain before authorizing the corresponding action on the destination chain. With Mithril, the bridge can verify this using a Merkle proof linked to a certificate signed by a stake-weighted quorum of SPOs. The proof can be checked locally, without trusting the source of the data. -This changes the bridge's security posture. The integrity of cross-chain transfers no longer depends on the honesty of any single data provider or on the operational security of any one node. A compromised API, a misconfigured indexer, or a hostile relayer cannot produce a valid Mithril proof — and a bridge that verifies proofs will reject anything that fails verification. +This changes the bridge's security posture. The integrity of cross-chain transfers no longer depends on the honesty of any single data provider or on the operational security of any one node. A compromised API, a misconfigured indexer, or a hostile relayer cannot produce a valid Mithril proof. If verification fails, the bridge treats the underlying Cardano transaction as unconfirmed and does not authorize the corresponding action on the destination chain. Crucially, the bridge gets this assurance from a lightweight client. The proof is fetched and verified on demand, with no full Cardano node to sync, store, or operate. For bridge teams, that means the most secure verification path is also the cheapest one — there is no longer a trade-off between trust assumptions and infrastructure overhead. ### How it fits into existing bridge architectures -Most bridges have an off-chain component — relayers, validators, or watchers — that observes events on the source chain and submits attestations to the destination chain. Mithril does not replace this component. It strengthens it: instead of trusting whatever endpoint the relayer happens to query, the relayer verifies a Mithril proof against the current certificate chain before treating a Cardano transaction as final. +Most bridges have an off-chain component — relayers, validators, or watchers — that observes events on the source chain and submits attestations to the destination chain. Mithril does not replace this component. It strengthens it: instead of trusting whatever endpoint the relayer happens to query, the relayer verifies a Mithril proof against the current certificate chain before treating a Cardano transaction as certified. This preserves the existing architecture while removing the implicit trust placed in centralized infrastructure. For bridge designs that already rely on a multi-signature or threshold scheme among relayers, Mithril provides an additional, independent check rooted in Cardano's stake distribution — making collusion among relayers insufficient to forge a transfer if proofs are verified. ### Integration -The easiest path for most bridge teams to integrate is using the official WASM package: +Bridge relayers, validators, and watchers typically run as server-side services, so most bridge teams will integrate via the [Rust client library](https://crates.io/crates/mithril-client) or the [Mithril client CLI](https://mithril.network/doc/manual/develop/nodes/mithril-client). The library is the most direct path for native services that want to embed proof verification in their existing process; the CLI is a good fit for teams that prefer to shell out from a relayer written in another language. -```bash -npm install @mithril-dev/mithril-client-wasm -``` - -It works in Node.js and in the browser, making it suitable for relayers, monitoring services, and validator software. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native services. +A [WASM package](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm) is also available for any browser-facing component of the bridge (e.g. a status dashboard or user-facing transfer UI that verifies proofs client-side). The core flow is straightforward: 1. Observe the lock or burn transaction on Cardano 2. Query the Mithril aggregator for a transaction proof of membership once the transation hash is known 3. Verify the proof against the current Mithril certificate chain -4. Treat the transaction as final and authorize the corresponding action on the destination chain. +4. Apply your finality criteria, then authorize the corresponding action on the destination chain. + +Proofs are generated approximately every 30 blocks. Mithril certifies that a Cardano transaction was included, but the bridge decides how many additional confirmations to require before acting on it. Under the current [Cardano transaction certification](/mithril/advanced/mithril-certification/cardano-transactions), certification runs around 100 blocks behind the chain tip — generally sufficient for smaller transfers, but bridge teams may want a wider margin for high-value ones. -Proofs are generated approximately every 30 blocks, with certification operating around 100 blocks behind the chain tip to ensure finality. Bridge teams should factor this into their finality model and user-facing expectations around transfer latency. +Under the upcoming [Cardano blocks and transactions certification](/mithril/advanced/mithril-certification/cardano-blocks-and-transactions), each proof carries a depth from the chain tip at snapshot time, so the bridge can pick its own threshold per transfer. Bridge teams should factor this into their finality model and user-facing expectations around transfer latency. ### Questions? @@ -90,7 +88,7 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc ## For bridge users -When a bridge supports Mithril, cross-chain transfers from Cardano are more secure. Whether you interact with the bridge directly, or through a wallet or aggregator that abstracts the swap behind a simpler interface, the underlying assertion is the same: that your Cardano transaction was actually included on-chain before the bridge took action on the other side. +When a bridge supports Mithril, cross-chain transfers from Cardano are more secure. Whether you interact with the bridge directly, or through a wallet or cross-chain DEX aggregator (e.g. 1inch) that abstracts the swap behind a simpler interface, the underlying assertion is the same: that your Cardano transaction was actually included on-chain before the bridge took action on the other side. With Mithril, that assertion is backed by a cryptographic proof signed by a stake-weighted quorum of Cardano's stake pool operators, rather than by the bridge's own infrastructure. This means a transfer cannot be authorized on the basis of a compromised API, a faulty indexer, or a single dishonest operator — the proof would simply fail to verify. diff --git a/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx b/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx index 1ed0c35ff18..52c886460c5 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx @@ -22,34 +22,32 @@ Before integrating, review the [Protocol security](/mithril/advanced/mithril-pro When a user locks assets on Cardano, the bridge needs to confirm that the lock transaction was included on-chain before authorizing the corresponding action on the destination chain. With Mithril, the bridge can verify this using a Merkle proof linked to a certificate signed by a stake-weighted quorum of SPOs. The proof can be checked locally, without trusting the source of the data. -This changes the bridge's security posture. The integrity of cross-chain transfers no longer depends on the honesty of any single data provider or on the operational security of any one node. A compromised API, a misconfigured indexer, or a hostile relayer cannot produce a valid Mithril proof — and a bridge that verifies proofs will reject anything that fails verification. +This changes the bridge's security posture. The integrity of cross-chain transfers no longer depends on the honesty of any single data provider or on the operational security of any one node. A compromised API, a misconfigured indexer, or a hostile relayer cannot produce a valid Mithril proof. If verification fails, the bridge treats the underlying Cardano transaction as unconfirmed and does not authorize the corresponding action on the destination chain. Crucially, the bridge gets this assurance from a lightweight client. The proof is fetched and verified on demand, with no full Cardano node to sync, store, or operate. For bridge teams, that means the most secure verification path is also the cheapest one — there is no longer a trade-off between trust assumptions and infrastructure overhead. ### How it fits into existing bridge architectures -Most bridges have an off-chain component — relayers, validators, or watchers — that observes events on the source chain and submits attestations to the destination chain. Mithril does not replace this component. It strengthens it: instead of trusting whatever endpoint the relayer happens to query, the relayer verifies a Mithril proof against the current certificate chain before treating a Cardano transaction as final. +Most bridges have an off-chain component — relayers, validators, or watchers — that observes events on the source chain and submits attestations to the destination chain. Mithril does not replace this component. It strengthens it: instead of trusting whatever endpoint the relayer happens to query, the relayer verifies a Mithril proof against the current certificate chain before treating a Cardano transaction as certified. This preserves the existing architecture while removing the implicit trust placed in centralized infrastructure. For bridge designs that already rely on a multi-signature or threshold scheme among relayers, Mithril provides an additional, independent check rooted in Cardano's stake distribution — making collusion among relayers insufficient to forge a transfer if proofs are verified. ### Integration -The easiest path for most bridge teams to integrate is using the official WASM package: +Bridge relayers, validators, and watchers typically run as server-side services, so most bridge teams will integrate via the [Rust client library](https://crates.io/crates/mithril-client) or the [Mithril client CLI](https://mithril.network/doc/manual/develop/nodes/mithril-client). The library is the most direct path for native services that want to embed proof verification in their existing process; the CLI is a good fit for teams that prefer to shell out from a relayer written in another language. -```bash -npm install @mithril-dev/mithril-client-wasm -``` - -It works in Node.js and in the browser, making it suitable for relayers, monitoring services, and validator software. All major browsers are supported — see the [Browser Compatibility](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm#browser-compatibility) section of the npm package for details. A [Rust crate](https://crates.io/crates/mithril-client) is also available for native services. +A [WASM package](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm) is also available for any browser-facing component of the bridge (e.g. a status dashboard or user-facing transfer UI that verifies proofs client-side). The core flow is straightforward: 1. Observe the lock or burn transaction on Cardano 2. Query the Mithril aggregator for a transaction proof once the tx hash is known 3. Verify the proof against the current Mithril certificate chain -4. Treat the transaction as final and authorize the corresponding action on the destination chain. +4. Apply your finality criteria, then authorize the corresponding action on the destination chain. + +Proofs are generated approximately every 30 blocks. Mithril certifies that a Cardano transaction was included, but the bridge decides how many additional confirmations to require before acting on it. Under the current [Cardano transaction certification](/mithril/advanced/mithril-certification/cardano-transactions), certification runs around 100 blocks behind the chain tip — generally sufficient for smaller transfers, but bridge teams may want a wider margin for high-value ones. -Proofs are generated approximately every 30 blocks, with certification operating around 100 blocks behind the chain tip to ensure finality. Bridge teams should factor this into their finality model and user-facing expectations around transfer latency. +Under the upcoming [Cardano blocks and transactions certification](/mithril/advanced/mithril-certification/cardano-blocks-and-transactions), each proof carries a depth from the chain tip at snapshot time, so the bridge can pick its own threshold per transfer. Bridge teams should factor this into their finality model and user-facing expectations around transfer latency. ### Questions? @@ -90,7 +88,7 @@ Have a question during integration? Reach out in the [#ask-mithril](https://disc ## For bridge users -When a bridge supports Mithril, cross-chain transfers from Cardano are more secure. Whether you interact with the bridge directly, or through a wallet or aggregator that abstracts the swap behind a simpler interface, the underlying assertion is the same: that your Cardano transaction was actually included on-chain before the bridge took action on the other side. +When a bridge supports Mithril, cross-chain transfers from Cardano are more secure. Whether you interact with the bridge directly, or through a wallet or cross-chain DEX aggregator (e.g. 1inch) that abstracts the swap behind a simpler interface, the underlying assertion is the same: that your Cardano transaction was actually included on-chain before the bridge took action on the other side. With Mithril, that assertion is backed by a cryptographic proof signed by a stake-weighted quorum of Cardano's stake pool operators, rather than by the bridge's own infrastructure. This means a transfer cannot be authorized on the basis of a compromised API, a faulty indexer, or a single dishonest operator — the proof would simply fail to verify. From 21c90f2e83311e05688eb2c2d85d1f764131add5 Mon Sep 17 00:00:00 2001 From: dalibran Date: Wed, 20 May 2026 17:02:12 +0900 Subject: [PATCH 22/25] docs(website): add sync timing to Daedalus case study, tidy punctuation Add the with-Mithril sync figure (roughly 30 minutes to an hour, depending on hardware and connection) to the "How Mithril helps" section, and replace em dashes with commas across the page for a less stylized read. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/root/case-studies/daedalus.mdx | 6 +++--- .../version-maintained/case-studies/daedalus.mdx | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/website/root/case-studies/daedalus.mdx b/docs/website/root/case-studies/daedalus.mdx index 9e4dc76b3ca..05510f2073d 100644 --- a/docs/website/root/case-studies/daedalus.mdx +++ b/docs/website/root/case-studies/daedalus.mdx @@ -35,12 +35,12 @@ sidebar_label: "Case Study: Daedalus Wallet" ## The problem -Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this usually takes more than 24-36 hours — historically a major friction point for users picking up a full-node wallet. +Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this usually takes more than 24-36 hours, historically a major friction point for users picking up a full-node wallet. ## How Mithril helps -Fresh installations of Daedalus now download a Mithril-certified snapshot of the Cardano node database and restore it locally, rather than replaying the chain. The snapshot's integrity is verified against the Mithril certificate chain, anchored in Cardano's stake distribution — so users get the same trust guarantees as a chain-replayed node, without the wait. +Fresh installations of Daedalus now download a Mithril-certified snapshot of the Cardano node database and restore it locally, rather than replaying the chain. The snapshot's integrity is verified against the Mithril certificate chain, anchored in Cardano's stake distribution, so users get the same trust guarantees as a chain-replayed node, without the wait. In practice, this brings the initial sync down to roughly 30 minutes to an hour, depending on hardware and internet connection. ## What's next -The current integration covers fresh installations. Partial sync resumption via Mithril — using snapshots to fast-forward a wallet that has been offline for a while — is planned for a future release. +The current integration covers fresh installations. Partial sync resumption via Mithril, using snapshots to fast-forward a wallet that has been offline for a while, is planned for a future release. diff --git a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx index 6caba2d333f..22d03602024 100644 --- a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx +++ b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx @@ -35,12 +35,12 @@ sidebar_label: "Case Study: Daedalus Wallet" ## The problem -Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this takes many hours and significant bandwidth — historically a major friction point for users picking up a full-node wallet. +Daedalus runs a full Cardano node locally. On first install, that node must sync the entire Cardano blockchain from genesis, replaying every block. Even on modern hardware, this takes many hours and significant bandwidth, historically a major friction point for users picking up a full-node wallet. ## How Mithril helps -Fresh installations of Daedalus now download a Mithril-certified snapshot of the Cardano node database and restore it locally, rather than replaying the chain. The snapshot's integrity is verified against the Mithril certificate chain, anchored in Cardano's stake distribution — so users get the same trust guarantees as a chain-replayed node, without the wait. +Fresh installations of Daedalus now download a Mithril-certified snapshot of the Cardano node database and restore it locally, rather than replaying the chain. The snapshot's integrity is verified against the Mithril certificate chain, anchored in Cardano's stake distribution, so users get the same trust guarantees as a chain-replayed node, without the wait. In practice, this brings the initial sync down to roughly 30 minutes to an hour, depending on hardware and internet connection. ## What's next -The current integration covers fresh installations. Partial sync resumption via Mithril — using snapshots to fast-forward a wallet that has been offline for a while — is planned for a future release. +The current integration covers fresh installations. Partial sync resumption via Mithril, using snapshots to fast-forward a wallet that has been offline for a while, is planned for a future release. From b5ba231a483ab0059a9e62c28db30e32c339bfb5 Mon Sep 17 00:00:00 2001 From: dalibran Date: Fri, 29 May 2026 20:27:36 +0900 Subject: [PATCH 23/25] docs(website): replace Daedalus wordmark text with SVG, link bridges example Extract the official DAEDALUS wordmark paths already embedded in daedalus-logo.svg into a standalone SVG so the case-study page no longer needs the Montserrat font import from Google Fonts. Add a sentence in the bridges integration section pointing to the client-cardano-transaction example for the full Rust-library proof flow. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/website/root/case-studies/daedalus.mdx | 16 ++--------- docs/website/root/use-cases/bridges.mdx | 2 +- docs/website/src/css/custom.css | 2 -- docs/website/static/img/daedalus-wordmark.svg | 27 +++++++++++++++++++ .../case-studies/daedalus.mdx | 16 ++--------- .../version-maintained/use-cases/bridges.mdx | 2 +- 6 files changed, 33 insertions(+), 32 deletions(-) create mode 100644 docs/website/static/img/daedalus-wordmark.svg diff --git a/docs/website/root/case-studies/daedalus.mdx b/docs/website/root/case-studies/daedalus.mdx index 05510f2073d..6d5c59a4446 100644 --- a/docs/website/root/case-studies/daedalus.mdx +++ b/docs/website/root/case-studies/daedalus.mdx @@ -11,24 +11,12 @@ sidebar_label: "Case Study: Daedalus Wallet" display: "flex", flexDirection: "column", alignItems: "center", - gap: "0.5rem", + gap: "0.75rem", margin: "0 auto 2rem", }} > Daedalus logo -
- Daedalus Wallet -
+ Daedalus [Daedalus](https://daedaluswallet.io/) is a full-node Cardano wallet, supported by Input Output. In its 8.0.0 release, Daedalus integrated Mithril bootstrapping to dramatically reduce the time required for a fresh installation to start using the wallet for the first time. diff --git a/docs/website/root/use-cases/bridges.mdx b/docs/website/root/use-cases/bridges.mdx index c9796747028..f270d29f187 100644 --- a/docs/website/root/use-cases/bridges.mdx +++ b/docs/website/root/use-cases/bridges.mdx @@ -34,7 +34,7 @@ This preserves the existing architecture while removing the implicit trust place ### Integration -Bridge relayers, validators, and watchers typically run as server-side services, so most bridge teams will integrate via the [Rust client library](https://crates.io/crates/mithril-client) or the [Mithril client CLI](https://mithril.network/doc/manual/develop/nodes/mithril-client). The library is the most direct path for native services that want to embed proof verification in their existing process; the CLI is a good fit for teams that prefer to shell out from a relayer written in another language. +Bridge relayers, validators, and watchers typically run as server-side services, so most bridge teams will integrate via the [Rust client library](https://crates.io/crates/mithril-client) or the [Mithril client CLI](https://mithril.network/doc/manual/develop/nodes/mithril-client). The library is the most direct path for native services that want to embed proof verification in their existing process; the CLI is a good fit for teams that prefer to shell out from a relayer written in another language. The [`client-cardano-transaction`](https://github.com/input-output-hk/mithril/tree/main/examples/client-cardano-transaction) example walks through the full Rust-library flow for fetching and verifying a transaction proof. A [WASM package](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm) is also available for any browser-facing component of the bridge (e.g. a status dashboard or user-facing transfer UI that verifies proofs client-side). diff --git a/docs/website/src/css/custom.css b/docs/website/src/css/custom.css index 2305d074422..dbf8462003e 100644 --- a/docs/website/src/css/custom.css +++ b/docs/website/src/css/custom.css @@ -15,8 +15,6 @@ @tailwind components; @tailwind utilities; -@import url("https://fonts.googleapis.com/css2?family=Montserrat:wght@300;600&display=swap"); - @font-face { font-family: "Lexend"; font-weight: 400; diff --git a/docs/website/static/img/daedalus-wordmark.svg b/docs/website/static/img/daedalus-wordmark.svg new file mode 100644 index 00000000000..a19a9e56141 --- /dev/null +++ b/docs/website/static/img/daedalus-wordmark.svg @@ -0,0 +1,27 @@ + + + + + + + + + + + + + diff --git a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx index 22d03602024..c4aef897842 100644 --- a/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx +++ b/docs/website/versioned_docs/version-maintained/case-studies/daedalus.mdx @@ -11,24 +11,12 @@ sidebar_label: "Case Study: Daedalus Wallet" display: "flex", flexDirection: "column", alignItems: "center", - gap: "0.5rem", + gap: "0.75rem", margin: "0 auto 2rem", }} > Daedalus logo -
- Daedalus Wallet -
+ Daedalus [Daedalus](https://daedaluswallet.io/) is a full-node Cardano wallet, supported by Input Output. In its 8.0.0 release, Daedalus integrated Mithril bootstrapping to dramatically reduce the time required for a fresh installation to start using the wallet for the first time. diff --git a/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx b/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx index 52c886460c5..3c10d6ef87a 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/bridges.mdx @@ -34,7 +34,7 @@ This preserves the existing architecture while removing the implicit trust place ### Integration -Bridge relayers, validators, and watchers typically run as server-side services, so most bridge teams will integrate via the [Rust client library](https://crates.io/crates/mithril-client) or the [Mithril client CLI](https://mithril.network/doc/manual/develop/nodes/mithril-client). The library is the most direct path for native services that want to embed proof verification in their existing process; the CLI is a good fit for teams that prefer to shell out from a relayer written in another language. +Bridge relayers, validators, and watchers typically run as server-side services, so most bridge teams will integrate via the [Rust client library](https://crates.io/crates/mithril-client) or the [Mithril client CLI](https://mithril.network/doc/manual/develop/nodes/mithril-client). The library is the most direct path for native services that want to embed proof verification in their existing process; the CLI is a good fit for teams that prefer to shell out from a relayer written in another language. The [`client-cardano-transaction`](https://github.com/input-output-hk/mithril/tree/main/examples/client-cardano-transaction) example walks through the full Rust-library flow for fetching and verifying a transaction proof. A [WASM package](https://www.npmjs.com/package/@mithril-dev/mithril-client-wasm) is also available for any browser-facing component of the bridge (e.g. a status dashboard or user-facing transfer UI that verifies proofs client-side). From 25798d55d3d7926449b4baaf150c692e9a919a4b Mon Sep 17 00:00:00 2001 From: dalibran Date: Fri, 29 May 2026 22:34:53 +0900 Subject: [PATCH 24/25] chore(website): prettier --write Co-Authored-By: Claude Opus 4.7 (1M context) --- .../blog/2022-10-11-keys-certification-badge/index.md | 1 + docs/website/blog/2024-12-17-era-switch-pythagoras.md | 2 ++ .../2025-06-17-client-cli-cardano-database-backends.md | 5 +++++ .../blog/2025-09-17-pre-built-linux-arm-binaries.md | 6 +++--- docs/website/root/manual/operate/run-aggregator-node.md | 7 +++++++ docs/website/root/manual/operate/run-signer-node.md | 3 +++ .../root/mithril/advanced/mithril-protocol/protocol.md | 1 + docs/website/root/mithril/advanced/threat-model.md | 2 ++ docs/website/sidebars.js | 2 +- .../manual/operate/run-aggregator-node.md | 7 +++++++ .../version-maintained/manual/operate/run-signer-node.md | 3 +++ .../mithril/advanced/mithril-protocol/protocol.md | 1 + .../version-maintained/mithril/advanced/threat-model.md | 2 ++ 13 files changed, 38 insertions(+), 4 deletions(-) diff --git a/docs/website/blog/2022-10-11-keys-certification-badge/index.md b/docs/website/blog/2022-10-11-keys-certification-badge/index.md index 6ba6691b7a2..22ed01f1be0 100644 --- a/docs/website/blog/2022-10-11-keys-certification-badge/index.md +++ b/docs/website/blog/2022-10-11-keys-certification-badge/index.md @@ -50,6 +50,7 @@ sqlite3 ${DATA_STORES_DIRECTORY}/signer.sqlite3 "UPDATE protocol_initializer SET From now, SPOs can either run their node by: - **Declaring their Cardano `PoolId`**: + - This is the mode that all nodes were running prior to this release - This mode is still the **stable** mode - We intend to deprecate this mode in the near future diff --git a/docs/website/blog/2024-12-17-era-switch-pythagoras.md b/docs/website/blog/2024-12-17-era-switch-pythagoras.md index c3211bfd610..eac8592e0b2 100644 --- a/docs/website/blog/2024-12-17-era-switch-pythagoras.md +++ b/docs/website/blog/2024-12-17-era-switch-pythagoras.md @@ -47,10 +47,12 @@ curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/input-out #### Era switch plan for `Pythagoras` - **pre-release-preview** network: + - [x] Create the era switch transaction (done at epoch `757`) - [x] Complete the era switch to `Pythagoras` at the transition to epoch `759` - **release-preprod** network: + - [x] Create the era switch transaction (done at epoch `184`) - [x] Complete the era switch to `Pythagoras` at the transition to epoch `186` diff --git a/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md b/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md index 04f9605cd4e..704829d8a56 100644 --- a/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md +++ b/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md @@ -35,22 +35,27 @@ In particular, the `cardano-db` command in the Mithril client CLI has been updat To support this transition, both certification versions will remain available during the migration period, allowing users to adapt at their own pace. - [x] **Distribution [2524](https://github.com/input-output-hk/mithril/releases/tag/2524.0)**: + - Introduced the `--backend` parameter in the `cardano-db` command - The default backend is `v1`; the `v2` backend is still considered **unstable** - No breaking changes in the client CLI - The `v2` backend is accessible via the `cardano_database_v2` function in the client library. - [x] **Distribution [2537](https://github.com/input-output-hk/mithril/releases/tag/2537.0)**: + - The `v2` backend is promoted to **stable** status but will remain optional - The `v1` backend is still the default. - [x] **Distribution [2543](https://github.com/input-output-hk/mithril/releases/tag/2543.0)**: + - The `v2` backend is the default - [x] **Distribution [2603](https://github.com/input-output-hk/mithril/releases/tag/2603.1)**: + - The `v1` backend is deprecated. - [x] **Distribution [2617](https://github.com/input-output-hk/mithril/releases/tag/2617.0)**: + - The `v1` backend is decommissioned and removed from the client CLI and library. - [ ] **Distribution +5**: diff --git a/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md b/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md index 0cba0e551ad..7477f3021e0 100644 --- a/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md +++ b/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md @@ -17,9 +17,9 @@ To provide a clear overview of supported platforms, the team has added a new 'Pl | Binary | Linux x64 | Linux arm64 | macOS arm64 | Windows x64 | | ------------------ | :-------: | :---------: | :---------: | :---------: | -| mithril-aggregator | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | -| mithril-signer | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | -| mithril-client | ✔ | ✔ ⁽\*⁾ | ✔ | ✔ | +| mithril-aggregator | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | +| mithril-signer | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | +| mithril-client | ✔ | ✔ ⁽\*⁾ | ✔ | ✔ | ⁽\*⁾⚠️ Linux arm64 builds are provided on a best-effort basis and are not officially supported. diff --git a/docs/website/root/manual/operate/run-aggregator-node.md b/docs/website/root/manual/operate/run-aggregator-node.md index 7313d3c3f03..437b539ff1f 100644 --- a/docs/website/root/manual/operate/run-aggregator-node.md +++ b/docs/website/root/manual/operate/run-aggregator-node.md @@ -60,6 +60,7 @@ Note that this guide works only on a Linux machine. - Operate a **Cardano full node** - To access the file system of the **Cardano full node**, you will need the following permissions: + - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -273,10 +274,12 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are - `CUSTOM_ORIGIN_TAG_WHITE_LIST`: Comma-separated list of custom origin tags to whitelist for client requests (default: `EXPLORER,BENCHMARK,CI,NA`). - **Base configuration** **optional** values are: + - `BLOCKFROST_PARAMETERS`: Parameters to connect to the Blockfrost API. Used to fetch the ticker and name of the registered stake pools. Example: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - `SIGNER_IMPORTER_RUN_INTERVAL`: Time interval at which the pools names and ticker in blockfrost will be imported (in minutes, default: `720`). - The **Cardano database** configuration values are (only needed if supporting Cardano database certification): + - `DB_DIRECTORY`: Directory of the Cardano node database stores (same as the `--database-path` setting of the Cardano node) - `DATA_STORES_DIRECTORY`: Directory where the aggregator will store its databases (eg, `/opt/mithril/stores`) - `GOOGLE_APPLICATION_CREDENTIALS_JSON`: JSON content of the GCP service account credentials (required if using GCP for snapshot storage) @@ -300,6 +303,7 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are Here is an **example** set of values for **release-preprod** that will be used in this guide in the **tip** boxes to illustrate some commands: - **Base configuration**: + - **SIGNED_ENTITY_TYPES**: `MithrilStakeDistribution,CardanoStakeDistribution,CardanoTransactions` (only supporting stake distributions and transactions, excluding database snapshots) - **SERVER_PORT**: `8080` - **PUBLIC_SERVER_URL**: `https://aggregator.example.com/aggregator` @@ -319,10 +323,12 @@ Here is an **example** set of values for **release-preprod** that will be used i - **CUSTOM_ORIGIN_TAG_WHITE_LIST**: `EXPLORER,BENCHMARK,CI,NA` - **Optional configuration**: + - **BLOCKFROST_PARAMETERS**: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - **SIGNER_IMPORTER_RUN_INTERVAL**: 720 - **Cardano database configuration**: + - **DB_DIRECTORY**: `/cardano/db` - **DATA_STORES_DIRECTORY**: `/opt/mithril/stores` - **GOOGLE_APPLICATION_CREDENTIALS_JSON**: `**YOUR_SECRET**` @@ -1296,6 +1302,7 @@ If you want to make your follower aggregator publicly discoverable, you should: 1. **Ensure your aggregator is accessible via HTTPS** by setting up Traefik or another reverse proxy with a valid SSL certificate (as described in the [Set up the SSL certificate](#setup-the-ssl-certificate-traefik) section). 2. **Register your aggregator in the networks configuration**. You can do this by: + - Opening an issue in the [Mithril GitHub repository](https://github.com/input-output-hk/mithril/issues) - Or by creating a pull request that modifies the [`networks.json`](https://github.com/input-output-hk/mithril/blob/main/networks.json) file and updates the `aggregators` field in the Cardano network you are targeting. diff --git a/docs/website/root/manual/operate/run-signer-node.md b/docs/website/root/manual/operate/run-signer-node.md index bb31bd5cdfe..4eb6cab1840 100644 --- a/docs/website/root/manual/operate/run-signer-node.md +++ b/docs/website/root/manual/operate/run-signer-node.md @@ -99,10 +99,12 @@ Note that this guide works only on a Linux machine. ::: - To operate a **Cardano node** as a **stake pool**, you need: + - The pool's `operational certificate` - The pool's `KES secret key` - To access the file system of the **Cardano block-producing** node for **production** deployment (or of the **Cardano relay** node for **naive** deployment), you will need the following permissions: + - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -546,6 +548,7 @@ sudo systemctl restart mithril-signer :::info - If you have already installed `Squid` via the `apt` package manager, we recommend that you delete it before manually building it from source by running the following commands: + - `sudo systemctl stop squid` - `sudo apt remove squid` - `sudo apt autoremove` diff --git a/docs/website/root/mithril/advanced/mithril-protocol/protocol.md b/docs/website/root/mithril/advanced/mithril-protocol/protocol.md index c92d90d7167..b898f4254f5 100644 --- a/docs/website/root/mithril/advanced/mithril-protocol/protocol.md +++ b/docs/website/root/mithril/advanced/mithril-protocol/protocol.md @@ -103,6 +103,7 @@ a quorum of `k` valid signatures must be submitted. - For every valid signature, the party creates a proof (`π`) containing a signature of the message, verification key, stake, and paths of the party in the Merkle tree. - Then, multiple signatures can be aggregated together to form a certificate (`τ`) by: + - Verifying signatures from each party: - Checking the party is authorized to sign for the given index (using the same procedure as signing) - Checking the proof is valid which means: diff --git a/docs/website/root/mithril/advanced/threat-model.md b/docs/website/root/mithril/advanced/threat-model.md index 8878b1a7173..e4c292ef1aa 100644 --- a/docs/website/root/mithril/advanced/threat-model.md +++ b/docs/website/root/mithril/advanced/threat-model.md @@ -114,6 +114,7 @@ For each asset, we first identify which part of the **CIA triad** (Confidentiali - The KES key is present only on the block-producing (BP) node but needs to be shared with both the `cardano-node` process and the `mithril-signer` process. - KES keys are needed by `mithril-signer` to sign a verification key along with an operational certificate that authenticates the key for this stake pool ID. - This signing happens at every epoch. + - **Confidentiality**: Yes Capturing KES private keys allows an attacker to impersonate a registered SPO on-chain and produce blocks on its behalf until the keys are rotated. @@ -324,6 +325,7 @@ A DoS on the `mithril-aggregator`. Data integrity of the Cardano block producer’s on-disk database could be compromised either by the action of the Mithril signer or by an attacker with access to the signer. - **Assets at risk**: + - [Block production](#block-production) - [Cardano chain database](#cardano-chain-database). diff --git a/docs/website/sidebars.js b/docs/website/sidebars.js index 7eeb3590489..b70bf82d521 100644 --- a/docs/website/sidebars.js +++ b/docs/website/sidebars.js @@ -32,7 +32,7 @@ const sidebars = { collapsed: false, items: [ { type: "doc", id: "use-cases/wallets/light-wallets" }, - { type: "doc", label: "Case Study: Daedalus Wallet", id: "case-studies/daedalus"}, + { type: "doc", label: "Case Study: Daedalus Wallet", id: "case-studies/daedalus" }, ], }, { type: "doc", id: "use-cases/bridges" }, diff --git a/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md b/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md index 953cc191a7d..c2ad372bb0e 100644 --- a/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md +++ b/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md @@ -60,6 +60,7 @@ Note that this guide works only on a Linux machine. - Operate a **Cardano full node** - To access the file system of the **Cardano full node**, you will need the following permissions: + - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -273,10 +274,12 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are - `CUSTOM_ORIGIN_TAG_WHITE_LIST`: Comma-separated list of custom origin tags to whitelist for client requests (default: `EXPLORER,BENCHMARK,CI,NA`). - **Base configuration** **optional** values are: + - `BLOCKFROST_PARAMETERS`: Parameters to connect to the Blockfrost API. Used to fetch the ticker and name of the registered stake pools. Example: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - `SIGNER_IMPORTER_RUN_INTERVAL`: Time interval at which the pools names and ticker in blockfrost will be imported (in minutes, default: `720`). - The **Cardano database** configuration values are (only needed if supporting Cardano database certification): + - `DB_DIRECTORY`: Directory of the Cardano node database stores (same as the `--database-path` setting of the Cardano node) - `DATA_STORES_DIRECTORY`: Directory where the aggregator will store its databases (eg, `/opt/mithril/stores`) - `GOOGLE_APPLICATION_CREDENTIALS_JSON`: JSON content of the GCP service account credentials (required if using GCP for snapshot storage) @@ -300,6 +303,7 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are Here is an **example** set of values for **release-preprod** that will be used in this guide in the **tip** boxes to illustrate some commands: - **Base configuration**: + - **SIGNED_ENTITY_TYPES**: `MithrilStakeDistribution,CardanoStakeDistribution,CardanoTransactions` (only supporting stake distributions and transactions, excluding database snapshots) - **SERVER_PORT**: `8080` - **PUBLIC_SERVER_URL**: `https://aggregator.example.com/aggregator` @@ -319,10 +323,12 @@ Here is an **example** set of values for **release-preprod** that will be used i - **CUSTOM_ORIGIN_TAG_WHITE_LIST**: `EXPLORER,BENCHMARK,CI,NA` - **Optional configuration**: + - **BLOCKFROST_PARAMETERS**: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - **SIGNER_IMPORTER_RUN_INTERVAL**: 720 - **Cardano database configuration**: + - **DB_DIRECTORY**: `/cardano/db` - **DATA_STORES_DIRECTORY**: `/opt/mithril/stores` - **GOOGLE_APPLICATION_CREDENTIALS_JSON**: `**YOUR_SECRET**` @@ -1296,6 +1302,7 @@ If you want to make your follower aggregator publicly discoverable, you should: 1. **Ensure your aggregator is accessible via HTTPS** by setting up Traefik or another reverse proxy with a valid SSL certificate (as described in the [Set up the SSL certificate](#setup-the-ssl-certificate-traefik) section). 2. **Register your aggregator in the networks configuration**. You can do this by: + - Opening an issue in the [Mithril GitHub repository](https://github.com/input-output-hk/mithril/issues) - Or by creating a pull request that modifies the [`networks.json`](https://github.com/input-output-hk/mithril/blob/main/networks.json) file and updates the `aggregators` field in the Cardano network you are targeting. diff --git a/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md b/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md index bb31bd5cdfe..4eb6cab1840 100644 --- a/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md +++ b/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md @@ -99,10 +99,12 @@ Note that this guide works only on a Linux machine. ::: - To operate a **Cardano node** as a **stake pool**, you need: + - The pool's `operational certificate` - The pool's `KES secret key` - To access the file system of the **Cardano block-producing** node for **production** deployment (or of the **Cardano relay** node for **naive** deployment), you will need the following permissions: + - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -546,6 +548,7 @@ sudo systemctl restart mithril-signer :::info - If you have already installed `Squid` via the `apt` package manager, we recommend that you delete it before manually building it from source by running the following commands: + - `sudo systemctl stop squid` - `sudo apt remove squid` - `sudo apt autoremove` diff --git a/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md b/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md index c92d90d7167..b898f4254f5 100644 --- a/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md +++ b/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md @@ -103,6 +103,7 @@ a quorum of `k` valid signatures must be submitted. - For every valid signature, the party creates a proof (`π`) containing a signature of the message, verification key, stake, and paths of the party in the Merkle tree. - Then, multiple signatures can be aggregated together to form a certificate (`τ`) by: + - Verifying signatures from each party: - Checking the party is authorized to sign for the given index (using the same procedure as signing) - Checking the proof is valid which means: diff --git a/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md b/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md index 2fa3166fef6..619103233f3 100644 --- a/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md +++ b/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md @@ -114,6 +114,7 @@ For each asset, we first identify which part of the **CIA triad** (Confidentiali - The KES key is present only on the block-producing (BP) node but needs to be shared with both the `cardano-node` process and the `mithril-signer` process. - KES keys are needed by `mithril-signer` to sign a verification key along with an operational certificate that authenticates the key for this stake pool ID. - This signing happens at every epoch. + - **Confidentiality**: Yes Capturing KES private keys allows an attacker to impersonate a registered SPO on-chain and produce blocks on its behalf until the keys are rotated. @@ -324,6 +325,7 @@ A DoS on the `mithril-aggregator`. Data integrity of the Cardano block producer’s on-disk database could be compromised either by the action of the Mithril signer or by an attacker with access to the signer. - **Assets at risk**: + - [Block production](#block-production) - [Cardano chain database](#cardano-chain-database). From 4382f521862c88642db5d7981504818754cb7dd6 Mon Sep 17 00:00:00 2001 From: dalibran Date: Fri, 29 May 2026 23:18:51 +0900 Subject: [PATCH 25/25] chore(website): prettier --write (repo-root, matching CI version) The previous `npm run pretty:write` in docs/website only covered **/*.{js,md} with prettier 3.3.2 (pinned). CI runs `prettier --check .` from repo root with prettier 3.8.3 (latest, from `npm install -g`), which formats a broader set of files and uses slightly different markdown rules. Run repo-root prettier so the formatting matches what CI checks. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../blog/2022-10-11-keys-certification-badge/index.md | 1 - docs/website/blog/2024-12-17-era-switch-pythagoras.md | 2 -- .../2025-06-17-client-cli-cardano-database-backends.md | 5 ----- .../blog/2025-09-17-pre-built-linux-arm-binaries.md | 6 +++--- .../website/root/manual/operate/run-aggregator-node.md | 7 ------- docs/website/root/manual/operate/run-signer-node.md | 3 --- .../root/mithril/advanced/mithril-protocol/protocol.md | 1 - docs/website/root/mithril/advanced/threat-model.md | 2 -- docs/website/root/use-cases/wallets/index.mdx | 2 +- docs/website/src/css/custom.css | 10 ++++++++-- .../manual/operate/run-aggregator-node.md | 7 ------- .../manual/operate/run-signer-node.md | 3 --- .../mithril/advanced/mithril-protocol/protocol.md | 1 - .../mithril/advanced/threat-model.md | 2 -- .../version-maintained/use-cases/wallets/index.mdx | 2 +- .../version-maintained-sidebars.json | 6 +++++- 16 files changed, 18 insertions(+), 42 deletions(-) diff --git a/docs/website/blog/2022-10-11-keys-certification-badge/index.md b/docs/website/blog/2022-10-11-keys-certification-badge/index.md index 22ed01f1be0..6ba6691b7a2 100644 --- a/docs/website/blog/2022-10-11-keys-certification-badge/index.md +++ b/docs/website/blog/2022-10-11-keys-certification-badge/index.md @@ -50,7 +50,6 @@ sqlite3 ${DATA_STORES_DIRECTORY}/signer.sqlite3 "UPDATE protocol_initializer SET From now, SPOs can either run their node by: - **Declaring their Cardano `PoolId`**: - - This is the mode that all nodes were running prior to this release - This mode is still the **stable** mode - We intend to deprecate this mode in the near future diff --git a/docs/website/blog/2024-12-17-era-switch-pythagoras.md b/docs/website/blog/2024-12-17-era-switch-pythagoras.md index eac8592e0b2..c3211bfd610 100644 --- a/docs/website/blog/2024-12-17-era-switch-pythagoras.md +++ b/docs/website/blog/2024-12-17-era-switch-pythagoras.md @@ -47,12 +47,10 @@ curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/input-out #### Era switch plan for `Pythagoras` - **pre-release-preview** network: - - [x] Create the era switch transaction (done at epoch `757`) - [x] Complete the era switch to `Pythagoras` at the transition to epoch `759` - **release-preprod** network: - - [x] Create the era switch transaction (done at epoch `184`) - [x] Complete the era switch to `Pythagoras` at the transition to epoch `186` diff --git a/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md b/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md index 704829d8a56..04f9605cd4e 100644 --- a/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md +++ b/docs/website/blog/2025-06-17-client-cli-cardano-database-backends.md @@ -35,27 +35,22 @@ In particular, the `cardano-db` command in the Mithril client CLI has been updat To support this transition, both certification versions will remain available during the migration period, allowing users to adapt at their own pace. - [x] **Distribution [2524](https://github.com/input-output-hk/mithril/releases/tag/2524.0)**: - - Introduced the `--backend` parameter in the `cardano-db` command - The default backend is `v1`; the `v2` backend is still considered **unstable** - No breaking changes in the client CLI - The `v2` backend is accessible via the `cardano_database_v2` function in the client library. - [x] **Distribution [2537](https://github.com/input-output-hk/mithril/releases/tag/2537.0)**: - - The `v2` backend is promoted to **stable** status but will remain optional - The `v1` backend is still the default. - [x] **Distribution [2543](https://github.com/input-output-hk/mithril/releases/tag/2543.0)**: - - The `v2` backend is the default - [x] **Distribution [2603](https://github.com/input-output-hk/mithril/releases/tag/2603.1)**: - - The `v1` backend is deprecated. - [x] **Distribution [2617](https://github.com/input-output-hk/mithril/releases/tag/2617.0)**: - - The `v1` backend is decommissioned and removed from the client CLI and library. - [ ] **Distribution +5**: diff --git a/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md b/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md index 7477f3021e0..0cba0e551ad 100644 --- a/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md +++ b/docs/website/blog/2025-09-17-pre-built-linux-arm-binaries.md @@ -17,9 +17,9 @@ To provide a clear overview of supported platforms, the team has added a new 'Pl | Binary | Linux x64 | Linux arm64 | macOS arm64 | Windows x64 | | ------------------ | :-------: | :---------: | :---------: | :---------: | -| mithril-aggregator | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | -| mithril-signer | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | -| mithril-client | ✔ | ✔ ⁽\*⁾ | ✔ | ✔ | +| mithril-aggregator | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | +| mithril-signer | ✔ | ✔ ⁽\*⁾ | ⛔ | ⛔ | +| mithril-client | ✔ | ✔ ⁽\*⁾ | ✔ | ✔ | ⁽\*⁾⚠️ Linux arm64 builds are provided on a best-effort basis and are not officially supported. diff --git a/docs/website/root/manual/operate/run-aggregator-node.md b/docs/website/root/manual/operate/run-aggregator-node.md index 437b539ff1f..7313d3c3f03 100644 --- a/docs/website/root/manual/operate/run-aggregator-node.md +++ b/docs/website/root/manual/operate/run-aggregator-node.md @@ -60,7 +60,6 @@ Note that this guide works only on a Linux machine. - Operate a **Cardano full node** - To access the file system of the **Cardano full node**, you will need the following permissions: - - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -274,12 +273,10 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are - `CUSTOM_ORIGIN_TAG_WHITE_LIST`: Comma-separated list of custom origin tags to whitelist for client requests (default: `EXPLORER,BENCHMARK,CI,NA`). - **Base configuration** **optional** values are: - - `BLOCKFROST_PARAMETERS`: Parameters to connect to the Blockfrost API. Used to fetch the ticker and name of the registered stake pools. Example: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - `SIGNER_IMPORTER_RUN_INTERVAL`: Time interval at which the pools names and ticker in blockfrost will be imported (in minutes, default: `720`). - The **Cardano database** configuration values are (only needed if supporting Cardano database certification): - - `DB_DIRECTORY`: Directory of the Cardano node database stores (same as the `--database-path` setting of the Cardano node) - `DATA_STORES_DIRECTORY`: Directory where the aggregator will store its databases (eg, `/opt/mithril/stores`) - `GOOGLE_APPLICATION_CREDENTIALS_JSON`: JSON content of the GCP service account credentials (required if using GCP for snapshot storage) @@ -303,7 +300,6 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are Here is an **example** set of values for **release-preprod** that will be used in this guide in the **tip** boxes to illustrate some commands: - **Base configuration**: - - **SIGNED_ENTITY_TYPES**: `MithrilStakeDistribution,CardanoStakeDistribution,CardanoTransactions` (only supporting stake distributions and transactions, excluding database snapshots) - **SERVER_PORT**: `8080` - **PUBLIC_SERVER_URL**: `https://aggregator.example.com/aggregator` @@ -323,12 +319,10 @@ Here is an **example** set of values for **release-preprod** that will be used i - **CUSTOM_ORIGIN_TAG_WHITE_LIST**: `EXPLORER,BENCHMARK,CI,NA` - **Optional configuration**: - - **BLOCKFROST_PARAMETERS**: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - **SIGNER_IMPORTER_RUN_INTERVAL**: 720 - **Cardano database configuration**: - - **DB_DIRECTORY**: `/cardano/db` - **DATA_STORES_DIRECTORY**: `/opt/mithril/stores` - **GOOGLE_APPLICATION_CREDENTIALS_JSON**: `**YOUR_SECRET**` @@ -1302,7 +1296,6 @@ If you want to make your follower aggregator publicly discoverable, you should: 1. **Ensure your aggregator is accessible via HTTPS** by setting up Traefik or another reverse proxy with a valid SSL certificate (as described in the [Set up the SSL certificate](#setup-the-ssl-certificate-traefik) section). 2. **Register your aggregator in the networks configuration**. You can do this by: - - Opening an issue in the [Mithril GitHub repository](https://github.com/input-output-hk/mithril/issues) - Or by creating a pull request that modifies the [`networks.json`](https://github.com/input-output-hk/mithril/blob/main/networks.json) file and updates the `aggregators` field in the Cardano network you are targeting. diff --git a/docs/website/root/manual/operate/run-signer-node.md b/docs/website/root/manual/operate/run-signer-node.md index 4eb6cab1840..bb31bd5cdfe 100644 --- a/docs/website/root/manual/operate/run-signer-node.md +++ b/docs/website/root/manual/operate/run-signer-node.md @@ -99,12 +99,10 @@ Note that this guide works only on a Linux machine. ::: - To operate a **Cardano node** as a **stake pool**, you need: - - The pool's `operational certificate` - The pool's `KES secret key` - To access the file system of the **Cardano block-producing** node for **production** deployment (or of the **Cardano relay** node for **naive** deployment), you will need the following permissions: - - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -548,7 +546,6 @@ sudo systemctl restart mithril-signer :::info - If you have already installed `Squid` via the `apt` package manager, we recommend that you delete it before manually building it from source by running the following commands: - - `sudo systemctl stop squid` - `sudo apt remove squid` - `sudo apt autoremove` diff --git a/docs/website/root/mithril/advanced/mithril-protocol/protocol.md b/docs/website/root/mithril/advanced/mithril-protocol/protocol.md index b898f4254f5..c92d90d7167 100644 --- a/docs/website/root/mithril/advanced/mithril-protocol/protocol.md +++ b/docs/website/root/mithril/advanced/mithril-protocol/protocol.md @@ -103,7 +103,6 @@ a quorum of `k` valid signatures must be submitted. - For every valid signature, the party creates a proof (`π`) containing a signature of the message, verification key, stake, and paths of the party in the Merkle tree. - Then, multiple signatures can be aggregated together to form a certificate (`τ`) by: - - Verifying signatures from each party: - Checking the party is authorized to sign for the given index (using the same procedure as signing) - Checking the proof is valid which means: diff --git a/docs/website/root/mithril/advanced/threat-model.md b/docs/website/root/mithril/advanced/threat-model.md index e4c292ef1aa..8878b1a7173 100644 --- a/docs/website/root/mithril/advanced/threat-model.md +++ b/docs/website/root/mithril/advanced/threat-model.md @@ -114,7 +114,6 @@ For each asset, we first identify which part of the **CIA triad** (Confidentiali - The KES key is present only on the block-producing (BP) node but needs to be shared with both the `cardano-node` process and the `mithril-signer` process. - KES keys are needed by `mithril-signer` to sign a verification key along with an operational certificate that authenticates the key for this stake pool ID. - This signing happens at every epoch. - - **Confidentiality**: Yes Capturing KES private keys allows an attacker to impersonate a registered SPO on-chain and produce blocks on its behalf until the keys are rotated. @@ -325,7 +324,6 @@ A DoS on the `mithril-aggregator`. Data integrity of the Cardano block producer’s on-disk database could be compromised either by the action of the Mithril signer or by an attacker with access to the signer. - **Assets at risk**: - - [Block production](#block-production) - [Cardano chain database](#cardano-chain-database). diff --git a/docs/website/root/use-cases/wallets/index.mdx b/docs/website/root/use-cases/wallets/index.mdx index 24d7409f9e2..e3158eda0aa 100644 --- a/docs/website/root/use-cases/wallets/index.mdx +++ b/docs/website/root/use-cases/wallets/index.mdx @@ -3,7 +3,7 @@ title: Wallets sidebar_label: Wallets --- -import Link from '@docusaurus/Link'; +import Link from "@docusaurus/Link"; # Mithril for wallets diff --git a/docs/website/src/css/custom.css b/docs/website/src/css/custom.css index dbf8462003e..35fc73eafd9 100644 --- a/docs/website/src/css/custom.css +++ b/docs/website/src/css/custom.css @@ -279,8 +279,14 @@ a.menu__link { border: 1px solid var(--ifm-color-emphasis-200); border-radius: 0.5rem; color: inherit; - background: var(--ifm-card-background-color, var(--ifm-background-surface-color)); - transition: border-color 0.15s ease, transform 0.15s ease, box-shadow 0.15s ease; + background: var( + --ifm-card-background-color, + var(--ifm-background-surface-color) + ); + transition: + border-color 0.15s ease, + transform 0.15s ease, + box-shadow 0.15s ease; } .markdown .wallet-card, diff --git a/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md b/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md index c2ad372bb0e..953cc191a7d 100644 --- a/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md +++ b/docs/website/versioned_docs/version-maintained/manual/operate/run-aggregator-node.md @@ -60,7 +60,6 @@ Note that this guide works only on a Linux machine. - Operate a **Cardano full node** - To access the file system of the **Cardano full node**, you will need the following permissions: - - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -274,12 +273,10 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are - `CUSTOM_ORIGIN_TAG_WHITE_LIST`: Comma-separated list of custom origin tags to whitelist for client requests (default: `EXPLORER,BENCHMARK,CI,NA`). - **Base configuration** **optional** values are: - - `BLOCKFROST_PARAMETERS`: Parameters to connect to the Blockfrost API. Used to fetch the ticker and name of the registered stake pools. Example: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - `SIGNER_IMPORTER_RUN_INTERVAL`: Time interval at which the pools names and ticker in blockfrost will be imported (in minutes, default: `720`). - The **Cardano database** configuration values are (only needed if supporting Cardano database certification): - - `DB_DIRECTORY`: Directory of the Cardano node database stores (same as the `--database-path` setting of the Cardano node) - `DATA_STORES_DIRECTORY`: Directory where the aggregator will store its databases (eg, `/opt/mithril/stores`) - `GOOGLE_APPLICATION_CREDENTIALS_JSON`: JSON content of the GCP service account credentials (required if using GCP for snapshot storage) @@ -303,7 +300,6 @@ The configuration values for the `/opt/mithril/mithril-aggregator.env` file are Here is an **example** set of values for **release-preprod** that will be used in this guide in the **tip** boxes to illustrate some commands: - **Base configuration**: - - **SIGNED_ENTITY_TYPES**: `MithrilStakeDistribution,CardanoStakeDistribution,CardanoTransactions` (only supporting stake distributions and transactions, excluding database snapshots) - **SERVER_PORT**: `8080` - **PUBLIC_SERVER_URL**: `https://aggregator.example.com/aggregator` @@ -323,12 +319,10 @@ Here is an **example** set of values for **release-preprod** that will be used i - **CUSTOM_ORIGIN_TAG_WHITE_LIST**: `EXPLORER,BENCHMARK,CI,NA` - **Optional configuration**: - - **BLOCKFROST_PARAMETERS**: `{"project_id":"preprodWuV1ICdtOWfZYfdcxpZ0tsS1N9rVZomQ"}` - **SIGNER_IMPORTER_RUN_INTERVAL**: 720 - **Cardano database configuration**: - - **DB_DIRECTORY**: `/cardano/db` - **DATA_STORES_DIRECTORY**: `/opt/mithril/stores` - **GOOGLE_APPLICATION_CREDENTIALS_JSON**: `**YOUR_SECRET**` @@ -1302,7 +1296,6 @@ If you want to make your follower aggregator publicly discoverable, you should: 1. **Ensure your aggregator is accessible via HTTPS** by setting up Traefik or another reverse proxy with a valid SSL certificate (as described in the [Set up the SSL certificate](#setup-the-ssl-certificate-traefik) section). 2. **Register your aggregator in the networks configuration**. You can do this by: - - Opening an issue in the [Mithril GitHub repository](https://github.com/input-output-hk/mithril/issues) - Or by creating a pull request that modifies the [`networks.json`](https://github.com/input-output-hk/mithril/blob/main/networks.json) file and updates the `aggregators` field in the Cardano network you are targeting. diff --git a/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md b/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md index 4eb6cab1840..bb31bd5cdfe 100644 --- a/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md +++ b/docs/website/versioned_docs/version-maintained/manual/operate/run-signer-node.md @@ -99,12 +99,10 @@ Note that this guide works only on a Linux machine. ::: - To operate a **Cardano node** as a **stake pool**, you need: - - The pool's `operational certificate` - The pool's `KES secret key` - To access the file system of the **Cardano block-producing** node for **production** deployment (or of the **Cardano relay** node for **naive** deployment), you will need the following permissions: - - Read rights on the `Database` folder (specified by the `--database-path` setting of the **Cardano node**) - Read and write rights on the `Inter Process Communication` file (typically defined by the `CARDANO_NODE_SOCKET_PATH` environment variable used to launch the **Cardano node**) @@ -548,7 +546,6 @@ sudo systemctl restart mithril-signer :::info - If you have already installed `Squid` via the `apt` package manager, we recommend that you delete it before manually building it from source by running the following commands: - - `sudo systemctl stop squid` - `sudo apt remove squid` - `sudo apt autoremove` diff --git a/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md b/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md index b898f4254f5..c92d90d7167 100644 --- a/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md +++ b/docs/website/versioned_docs/version-maintained/mithril/advanced/mithril-protocol/protocol.md @@ -103,7 +103,6 @@ a quorum of `k` valid signatures must be submitted. - For every valid signature, the party creates a proof (`π`) containing a signature of the message, verification key, stake, and paths of the party in the Merkle tree. - Then, multiple signatures can be aggregated together to form a certificate (`τ`) by: - - Verifying signatures from each party: - Checking the party is authorized to sign for the given index (using the same procedure as signing) - Checking the proof is valid which means: diff --git a/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md b/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md index 619103233f3..2fa3166fef6 100644 --- a/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md +++ b/docs/website/versioned_docs/version-maintained/mithril/advanced/threat-model.md @@ -114,7 +114,6 @@ For each asset, we first identify which part of the **CIA triad** (Confidentiali - The KES key is present only on the block-producing (BP) node but needs to be shared with both the `cardano-node` process and the `mithril-signer` process. - KES keys are needed by `mithril-signer` to sign a verification key along with an operational certificate that authenticates the key for this stake pool ID. - This signing happens at every epoch. - - **Confidentiality**: Yes Capturing KES private keys allows an attacker to impersonate a registered SPO on-chain and produce blocks on its behalf until the keys are rotated. @@ -325,7 +324,6 @@ A DoS on the `mithril-aggregator`. Data integrity of the Cardano block producer’s on-disk database could be compromised either by the action of the Mithril signer or by an attacker with access to the signer. - **Assets at risk**: - - [Block production](#block-production) - [Cardano chain database](#cardano-chain-database). diff --git a/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx b/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx index 24d7409f9e2..e3158eda0aa 100644 --- a/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx +++ b/docs/website/versioned_docs/version-maintained/use-cases/wallets/index.mdx @@ -3,7 +3,7 @@ title: Wallets sidebar_label: Wallets --- -import Link from '@docusaurus/Link'; +import Link from "@docusaurus/Link"; # Mithril for wallets diff --git a/docs/website/versioned_sidebars/version-maintained-sidebars.json b/docs/website/versioned_sidebars/version-maintained-sidebars.json index 04c374d5b35..41247e4ca2d 100644 --- a/docs/website/versioned_sidebars/version-maintained-sidebars.json +++ b/docs/website/versioned_sidebars/version-maintained-sidebars.json @@ -29,7 +29,11 @@ "collapsed": false, "items": [ { "type": "doc", "id": "use-cases/wallets/light-wallets" }, - { "type": "doc", "id": "case-studies/daedalus", "label": "Case Study: Daedalus Wallet" } + { + "type": "doc", + "id": "case-studies/daedalus", + "label": "Case Study: Daedalus Wallet" + } ] }, { "type": "doc", "id": "use-cases/bridges" }