One-liner: Institutional privacy stacks let financial systems decide what becomes public, what stays private, who is allowed to see or enforce policy, and whether operators can assist without taking custody.
Reader's Mental Model
The three systems are easiest to understand as three different privacy stack shapes:
Tempo Zones: a private validium-style L2 attached to Tempo's payment L1. Users bridge assets into a private zone, transact privately inside it, and rely on validity proofs plus the Zone Portal for asset safety.
Canton Network: a permissioned Daml workflow ledger. Instead of creating private rollups or private accounts, Canton lets institutions share business contracts and settlement workflows on a need-to-know basis. Daml defines who must authorize a workflow, who can see it, and what actions can be taken; participant nodes hold the entitled private data; synchronizers coordinate commits.
Miden: a programmable private-account stack. Miden makes private accounts and notes native to the protocol: state can stay off-chain, while the network verifies commitments, nullifiers, and proofs. These private accounts are programmable, so they can encode smart contract-like behavior, custom authorization, policy logic, vault rules, and other account-local programs. Guardian is the non-custodial coordination layer that helps those accounts with backup, sync, recovery, multisig proposals, policy co-signing, and institutional controls.
Summary
Tempo Zones, Canton Network, and Miden Guardian are three different answers to the same institutional demand: private financial workflows that still need compliance, operational guarantees, custody-risk clarity, and usable developer surfaces.
Tempo starts from a payments-optimized L1, then adds privacy through private validium-style zones. Assets move into a zone through the Zone Portal, transact privately inside that zone, then return to mainnet or another zone through proof-backed withdrawals and callbacks. Tempo is the most payment-native design: familiar EVM tooling, stablecoin fees, fast UX, and clear compliance hooks. Its main tradeoff is operator trust: the zone sequencer sees all activity inside the zone and controls liveness/data availability.
Canton starts from institutional workflow synchronization. It is not a private validium and not a private smart-account system. It is a permissioned Daml workflow ledger: Daml contracts model business objects and workflows, parties define who participates, participant nodes store the contract data they are entitled to see, and synchronizers coordinate commits without global plaintext replication. Canton is the most enterprise-native design: strong workflow semantics, need-to-know data distribution, and a natural fit for regulated multi-party business processes.
Miden starts from programmable private accounts. Instead of moving assets into a separate private zone or workflow channel, Miden makes accounts, notes, nullifiers, commitments, and proofs native to the protocol. Private account state can stay off-chain while the network verifies validity. Guardian then makes that account model operational: backup, sync, recovery, multisig coordination, policy co-signing, screening, and audit/export surfaces without becoming a custodian.
The main thesis:
Institutional privacy is converging on selective visibility, not universal secrecy. Tempo uses private validium-style zones. Canton uses Daml contracts with need-to-know visibility across institutions. Miden uses programmable private accounts, then Guardian makes those accounts recoverable, synchronized, policy-aware, and institutionally usable without taking custody.
Why This Is Important
Institutional crypto use cases are blocked less by raw throughput and more by visibility, compliance, and operational risk. Payroll, treasury, OTC trading, tokenized deposits, RWA settlement, private DeFi access, AI-agent payments, and custodial or assisted-custody products cannot expose every balance, counterparty, and workflow to a public block explorer.
The market demand is visible in the Miden Guardian product notes: custodians want privacy-as-a-product without custody liability; trading apps and neobanks want private DeFi access without dropping users into pure self-custody; community banks want crypto services without outsourcing the whole relationship to a custodian; treasury/payroll platforms want private payment rails with spending limits; AI-agent payment products need programmable controls because an agent cannot simply be handed a wallet.
The useful question is not "which privacy chain wins?" The useful question is:
What should be public, what should stay private, who can see inside, who can enforce policy, how does private state communicate with the rest of the financial system, and can the operator help without taking custody?
That is why the comparison needs three distinct mental models: Tempo as private validium-style payment zones, Canton as a permissioned workflow ledger, and Miden as programmable private accounts with Guardian as the non-custodial coordination layer.
Key Terms
Base Layer
The globally authoritative layer in each stack. It may be a public L1, an L2 commitment layer, or a permissioned synchronization network. The key question is what becomes final and visible there.
Privacy Silo
The boundary where sensitive state or activity is hidden from public or non-entitled observers. In Tempo this is a private validium-style Zone. In Canton it is a Daml contract visibility graph across parties and participant nodes. In Miden it is private account and note state, often assisted by Guardian.
Boundary and Interoperability
The mechanisms that let private state interact with the base layer, other silos, and external applications. This includes deposits, withdrawals, reassignment, native transfers, callbacks, proofs, attestations, and off-ledger APIs.
Daml
Daml is Canton's smart contract language for modeling multi-party business workflows. A Daml contract is closer to a shared business record than to an EVM liquidity pool. Developers define templates with parties, signatories, observers, and choices. Those roles determine who must authorize a workflow, who can see contract data, and who can exercise actions on the contract.
Canton Workflow Ledger
The simplest beginner framing for Canton: a permissioned ledger for private institutional workflows. Daml defines the business object and who is allowed to act on it. Participant nodes host the parties and store their entitled private data. Synchronizers coordinate transaction commits so multiple institutions can update shared workflow state without broadcasting all details to everyone.
Daml Party
The on-ledger identity in Canton. Access to data is managed at party granularity. Parties are hosted on participant nodes.
Participant / Validator Node
A Canton node that hosts parties, stores the private contract data it is entitled to see, validates affected transactions, and exposes the Ledger API.
Synchronizer
A Canton coordination layer that orders encrypted messages and coordinates transaction commits between participant nodes. It is not a full-state validator in the public-chain sense.
Tempo Zone
A private validium-style execution environment attached to Tempo Mainnet. It has its own sequencer, keeps transaction data off mainnet, posts commitments/proofs to the base layer, and hides balances, transfers, history, and counterparties from public observers.
Zone Portal
The Tempo mainnet contract that locks deposits, tracks zone batches, verifies proofs, and processes withdrawals.
Miden Account State
The account-local data a Miden account needs to operate: balances, notes, storage, account logic, authentication data, and other private context. Public chains usually make this state globally readable; Miden private accounts can keep it off-chain while publishing commitments and proofs.
Miden Note and Nullifier
A note is a programmable asset/message object used to transfer value or instructions between accounts. A nullifier marks a consumed note so it cannot be spent twice.
Miden Guardian
A non-custodial coordination service for private account state. Guardian is not a rollup, bridge, sequencer, custodian, or private execution environment. It stores and relays snapshots/deltas, helps devices sync, supports recovery, coordinates multisig proposals, and can co-sign or refuse transactions according to account policy. The key exception is Guardian rotation: the user can rotate to a different Guardian provider at any time without needing the current Guardian to co-sign the rotation.
Operator Fund-Control / Custody Risk
Whether the privacy operator can move user assets by itself. Miden Guardian is designed to be non-custodial: it can assist, co-sign, recover state, enforce policy, or refuse service, but cannot unilaterally move funds. Tempo Zones are similar on asset safety: the sequencer cannot steal locked funds or forge withdrawals if the Zone Portal and proofs are correct, though it is trusted for privacy, liveness, ordering, and data availability. Canton is configuration-dependent: local party hosting can give a participant authority to submit for a party, while external-party setups keep submission keys under the party's control.
Reference Model
The reference model is a lens for reading the three systems. It is not a claim that Tempo, Canton, and Miden have the same architecture. The point is to ask the same sequence of questions for each system so the comparison stays fair.
The first question is the Base Layer: what becomes final or globally authoritative? For Tempo, this is the payment L1 and the Zone Portal commitments around private zones. For Canton, it is the governed synchronization fabric that coordinates Daml workflows. For Miden, it is the L2 commitment layer for accounts, notes, and nullifiers.
The second question is the Privacy Silo: what is hidden, who can see inside, and where does private state live? Tempo hides activity inside private validium-style zones. Canton hides contract and workflow data through Daml party visibility and participant-node hosting. Miden hides private account and note state off-chain, with Guardian optionally helping manage that state.
The third question is Boundary and Interoperability: how does private state cross back to the base layer, other private silos, and external applications? Tempo uses deposits, withdrawals, callbacks, and bridge-mediated cross-zone routing. Canton uses Daml transactions, synchronizer routing, contract reassignment, Ledger API streams, and application APIs. Miden uses native account and note transitions, nullifiers, commitments, proofs, and off-chain note exchange.
The last questions are about what institutions can actually do with the silo. Inside-Silo Programmability asks what can be built privately. Policy and Compliance asks where rules, vetoes, attestations, and disclosures are enforced. Operator and Business Model asks who runs the infrastructure, who pays, and whether the operator can assist without gaining unilateral control over user assets.
Architecture 1: Tempo Institutional Privacy Stack
Tempo is the clearest example of a private validium-style payment zone.
Base Layer
Tempo Mainnet is the base layer. It is a payments-optimized L1 with native stablecoin-oriented features: TIP-20 tokens, USD-denominated fees, configurable fee tokens, fee sponsorship, batching, access keys, scheduled transactions, payment lanes, and an enshrined stablecoin DEX. Tempo Zones then behave like private validium-style L2s attached to that payment base.
For zones, the base layer does not see the full zone transaction history. It sees locked deposits, withdrawal processing, state commitments, and validity proofs.
Privacy Silo
A Tempo Zone is a private validium-style execution environment attached to Tempo Mainnet. It acts like a separate private chain with its own sequencer. Balances, transfers, transaction history, and counterparty relationships are hidden from mainnet block explorers, indexers, and ordinary users.
The zone sequencer is inside the trust boundary. It sees all zone activity and controls ordering, inclusion, liveness, and data availability. Validity proofs prevent forged state transitions, but they do not make the sequencer blind.
Boundary and Interoperability
Tempo's boundary mechanism is the Zone Portal bridge.
Entering a zone: a user deposits TIP-20 tokens into the Zone Portal on Tempo Mainnet. Funds are locked on mainnet, then the zone sequencer processes the deposit and credits the user inside the zone.
Exiting a zone: the user creates a withdrawal request inside the zone. The sequencer finalizes withdrawal batches, proofs commit to the withdrawal queue, and withdrawals are processed on Tempo Mainnet.
Silo-to-silo interaction: a zone can withdraw to mainnet, optionally swap through the Stablecoin DEX, and deposit into another zone through composable withdrawal callbacks. This is not native private-to-private settlement. It is bridge-mediated routing through the base layer.
Inside-Silo Programmability
Inside a zone, developers get a private EVM-like environment for payment and application logic. The best-fit use cases are private stablecoin transfers, private payroll, treasury movement, merchant settlement, private swaps routed through mainnet liquidity, and payment workflows where the UX matters more than maximal cryptographic privacy.
Policy / Compliance
Tempo's policy story is payment-native. TIP-20 tokens carry issuer policy through the TIP-403 registry. When tokens are deposited into a zone, the policy is mirrored and validity proofs commit that zone execution respected issuer rules.
This is attractive for regulated stablecoin issuers because compliance follows the asset into the private environment.
Operator / Business Model
The zone operator or sequencer can sell private payment infrastructure to enterprises, processors, issuers, merchants, and payment platforms. The operator assumption is explicit: users trust the operator for privacy, ordering, inclusion, liveness, and data availability, while relying on proofs for asset safety. Put differently, Tempo is non-custodial with respect to unilateral fund movement, but not trustless with respect to privacy or availability: the sequencer should not be able to steal locked assets, but it can see activity and can censor, halt, or delay.
Architecture 2: Canton Institutional Privacy Stack
Canton is best described as a permissioned Daml workflow ledger with need-to-know replication.
Base Layer
Canton's base layer is not a globally replicated public state machine in the same way as Tempo. It is a governed synchronization fabric for Daml workflows. The Global Synchronizer and private synchronizers coordinate transaction commits across participant nodes. Topology determines which parties are hosted where, which packages are vetted, and which synchronizers are suitable for a workflow.
The base-layer comparison needs to include permissioning. In Canton, the important questions are who can run participant nodes, who can connect to a synchronizer, who hosts a party, who sees a contract, and which synchronizer coordinates the transaction.
Privacy Silo
Canton's privacy silo is not a zone and not an account-level private state container. It is a Daml contract visibility graph across parties and participant nodes. A useful analogy is a private shared workflow folder: only the institutions that are parties, signatories, controllers, or observers of a contract receive the relevant data.
Participant nodes store only the ledger data they are entitled to see. Daml contracts define signatories, observers, controllers, and choices. This creates need-to-know visibility: the relevant parties and their hosting participants can see and validate the workflow state, while non-entitled parties do not receive the data.
Boundary and Interoperability
Inside one synchronizer, Canton uses Daml transactions and two-phase commit coordination between participant nodes.
Across synchronizers, Canton uses contract reassignment. Contracts assigned to different synchronizers may need to be reassigned to a common synchronizer before a transaction can execute. The synchronizer router can handle some of this automatically, but the concept is not a token bridge. It is workflow/state reassignment inside Canton's ledger model.
Across applications, Canton supports on-ledger Daml composition and off-ledger APIs exposed by applications. This makes Canton closer to enterprise workflow infrastructure than to a public DeFi composability model.
Inside-Silo Programmability
Canton's programmable layer is Daml. Daml templates define business objects such as assets, IOUs, trades, obligations, credentials, or settlement instructions. Choices define the valid actions on those objects: accept, transfer, settle, redeem, cancel, pledge, or approve. This makes Canton intuitive for institutional workflows: the program describes the business process, not just token movement.
Canton is strong where the private object is not just a balance, but a workflow involving multiple institutions with different rights and obligations.
Policy / Compliance
Canton policy is mostly encoded through Daml authorization, party rights, participant hosting, enterprise IAM, app backends, and institution-specific controls. This is not anonymous privacy. It is selective visibility and authorization for regulated workflows.
Operator / Business Model
Institutions can run participant nodes themselves or rely on node-as-a-service providers. Synchronizers may be public/decentralized, such as the Global Synchronizer, or privately operated for a consortium or regulated domain. Operators assume responsibility for data confidentiality, transaction validation, uptime, integration, and deployment topology.
Canton should not be labeled globally custodial or non-custodial. Control depends on party hosting and key management. A local party hosted by a participant with submission permissions gives that participant authority to submit transactions for the party, which is closer to delegated operational control. External-party setups can keep submission keys under the party's control, which is closer to non-custodial.
Architecture 3: Miden - Programmable Private Accounts With Guardian Coordination
Miden is best described as programmable private accounts with non-custodial Guardian coordination. It is harder to compare than Tempo and Canton because the privacy silo is not a separate zone or workflow channel. In Miden, the privacy silo is the account itself.
Base Layer
Miden is an L2 whose protocol makes accounts, notes, nullifiers, commitments, and validity proofs authoritative. The base layer does not need to read every private account balance or storage slot. It needs enough public data, commitments, nullifiers, and proofs to verify that private state transitions are valid.
This is the main difference from Tempo. Tempo moves assets into a private zone through the Zone Portal. Miden does not need a Zone Portal-style bridge to enter privacy because private accounts and private notes are native protocol objects.
Privacy Silo
The privacy silo is the private account and private note state. State means the account-local data needed to operate: balances, notes, storage, account logic, authentication data, and other private context. In an EVM-style chain, much of this state is globally readable. In a Miden private account, the full state can remain local or off-chain while the network sees commitments and proofs.
This design gives Miden a clean protocol-level privacy story, but it creates a product problem: if the full state is not globally readable, users and signers need backup, sync, recovery, and coordination.
Boundary and Interoperability
Miden's boundary mechanism is protocol-native. Accounts, notes, nullifiers, commitments, and proofs are the interface between private state and public verification.
A transfer is easiest to understand through notes. Alice creates a note that carries assets or instructions, commits it to the network, and sends the note data to Bob through an off-chain channel. Bob later consumes the note and updates his own account state. Nullifiers prevent double spending, and proofs let the network verify validity without exposing the full private state.
Inside-Silo Programmability
Miden's programmable layer is the private account itself. Private accounts can hold code, storage, vaults, authentication logic, policy, and smart contract-like programmable logic. In other words, the account is not just a balance container; it can be used to build private smart accounts, private multisig rules, spending policies, automated vault behavior, and other application logic. Notes are programmable asset/message objects. Users execute locally, keep private state off-chain, and prove valid transitions with STARK proofs.
This opens use cases such as private wallets, private multisig, assisted self-custody, private asset transfers, programmable treasuries, AI-agent spending accounts, private DeFi access, and compliance-aware account products.
Guardian Layer, Policy, and Custody
Guardian is not the private execution environment. It is an off-chain coordination service for private account state. Guardian stores and relays snapshots and deltas, helps devices stay synchronized, supports recovery, coordinates multisig proposals, checks submitted state against the Miden network, and signs acknowledgments over accepted commitments.
Guardian also creates the policy surface. A Guardian operator can co-sign normal transactions, refuse suspicious transactions, apply spending limits, support transaction screening, provide attestations, coordinate recovery, and eventually host delegated proving, TEE privacy modules, compliance dashboards, or audit/export flows. These are account-level controls, not base-layer consensus.
The custody claim is the key product point. A common Guardian-protected account can use a 2-of-3 model: user hot key, user cold key, and Guardian service key. Normal transactions can require hot key plus Guardian. The deliberate exception is Guardian rotation: if the user wants to change Guardian providers, the user can rotate the active Guardian at any time through the user-controlled authorization path, without needing the current Guardian to co-sign the rotation. That means Guardian can help, co-sign, veto, delay, or refuse normal service, but it cannot move funds alone or lock the user into one Guardian provider if the account policy is configured correctly.
Operator / Business Model
Guardian operators can be wallets, custodians, neobanks, community banks, payroll platforms, treasury tools, institutional infrastructure providers, or compliance operators. The business model is state availability, recovery, co-signing, screening, attestations, audit/export services, private-account infrastructure, and SLAs.
This is closer to assisted self-custody than custody. The Guardian may be operator-visible and may observe submitted payloads or access patterns unless additional encryption or TEE modules are used. But visibility is not unilateral control. The product promise is to add recovery, screening, policy, and auditability around private accounts without handing the operator the ability to move assets by itself.
Comparison Matrix
| Layer | Tempo Zones | Canton Network | Miden |
|---|---|---|---|
| Base Layer | Payments L1 with public mainnet state, TIP-20 assets, fees, DEX, Zone commitments, and proofs | Permissioned or governed synchronization fabric with Global Synchronizer and private synchronizers | Miden L2 protocol: accounts, notes, nullifiers, commitments, and proofs |
| Base visibility | Mainnet sees deposits, withdrawals, commitments, proofs, and public activity | Synchronizers coordinate encrypted messages and topology, while participants see entitled shards | Network sees public data, commitments, nullifiers, and proofs, not full private account/note state |
| Privacy Silo | Private validium-style Tempo Zone | Daml workflow / contract visibility graph across parties and participant nodes | Programmable private account and private note state |
| Who sees inside? | Zone sequencer | Entitled parties and participant nodes hosting them | User/client, plus Guardian or configured services for submitted state |
| Operator fund-control / custody risk | Sequencer should not be able to steal locked funds if proofs and portal are correct; operator still controls privacy, liveness, ordering, and data availability | Configuration-dependent: local-party hosting can delegate submission authority to participants; external-party setups can keep submission keys with the party | Guardian cannot move funds alone under a hot/cold/Guardian policy; it can co-sign, veto, delay, or refuse normal service, but Guardian rotation does not require the current Guardian's co-signature |
| Boundary and Interoperability | Zone Portal deposits, withdrawals, encrypted deposits, callbacks, withdraw-swap-deposit routing | Daml transactions, synchronizer routing, contract reassignment, Ledger API, app APIs | Native account/note transitions, nullifiers, commitments, proofs, and off-chain note sharing |
| Inside-Silo Programmability | EVM-like private payment/application execution inside a zone | Daml workflow contracts with templates, parties, signatories, observers, and choices | Programmable private accounts, programmable notes, local execution, STARK proofs |
| Policy / Compliance | TIP-403 issuer policy mirrored into zones and checked in proofs | Daml authorization, party rights, IAM, participant hosting, app controls | Guardian co-signing, veto, screening, limits, attestations, recovery, audit/export flows, future TEE modules |
| Operator | Zone sequencer/operator | Participant operators, synchronizer operators, app providers | Guardian operator for account coordination, not a sequencer |
| Best fit | Private stablecoin payments and payment-adjacent apps | Regulated multi-party workflows, shared business records, and institutional settlement | Private accounts, assisted self-custody, private multisig, programmable treasuries, wallet infrastructure |
Judgement
Tempo is strongest for private stablecoin payments. It has the cleanest payment UX story: stablecoin fees, payment lanes, EVM compatibility, private validium-style zones, and bridge-mediated interoperability. The tradeoff is that privacy is operator-visible.
Canton is strongest for regulated multi-party workflows. It matches enterprise reality: each institution has its own systems, permissions, data boundaries, IAM, and operational requirements. Daml gives a precise way to model business records, obligations, approvals, and settlement actions with need-to-know visibility. The architecture is heavy, but the mental model is understandable: private shared workflows between entitled institutions.
Miden is strongest for programmable private accounts. The clean object is not "Guardian" by itself; it is the private account. Miden lets account and note state stay private while commitments, nullifiers, and proofs anchor validity. Because private accounts are programmable, they can express smart contract-like behavior and account-local logic without making the full state globally readable. Guardian addresses the practical gap: private account state needs backup, sync, recovery, multisig coordination, policy, and auditability without handing an operator unilateral custody.
The market framing for Guardian should be upgraded: it is not merely backup, and it is not custody. It is the institutional coordination layer around programmable private accounts. A Guardian operator can add recovery, screening, policy co-signing, attestations, audit/export flows, and SLAs, but the account can still be designed so the Guardian cannot move customer assets alone.
What The Diagrams Need To Show Later
- Reference model diagram: the reusable Base Layer lens and color legend.
- Tempo architecture diagram: Mainnet, Zone Portal, Zone, sequencer, proofs, TIP-403, DEX/callback path.
- Canton architecture diagram: Daml parties/contracts, participant nodes, synchronizer, Ledger API/PQS/app backend, reassignment path.
- Miden architecture diagram: Miden L2 with accounts, notes, nullifiers, commitments, and proofs as the protocol-native boundary; private account/note state as the silo; Guardian beside it as backup, sync, recovery, co-signing, policy, screening, and audit/export coordination.
- Visibility and custody-risk matrix: who sees plaintext data, and who can move or block assets in each system.
- Boundary flow diagram: Tempo bridge, Canton reassignment/routing, Miden native note/account transitions.
Open Questions
Base Layer
- How should the report describe Canton's permissioning without flattening it into the same category as public L1s?
- For Miden, should the base layer be presented as Miden's L2 commitment layer, or should Ethereum/Agglayer be visually shown underneath as a separate settlement/security anchor?
- For Tempo, what zone data appears on mainnet in practice beyond commitments, proofs, deposits, and withdrawals?
Privacy Silo
- Does Tempo's sequencer-visible privacy satisfy institutional privacy requirements, or does it mostly recreate a private operator ledger with better settlement hooks?
- Can Canton be made visually understandable without overloading the reader with parties, users, participants, synchronizers, topology, and Daml packages?
- How much state should a Guardian see in a production Miden deployment, and where can encryption, TEE modules, or selective disclosure reduce leakage?
Boundary and Interoperability
- Is Tempo's withdraw-swap-deposit cross-zone flow good enough for private cross-zone composability?
- How operationally painful is Canton contract reassignment across synchronizers?
- How should Miden explain private note discovery and off-chain note sharing to institutional users?
Policy / Compliance
- Are TIP-403 mirrored policies expressive enough for complex regulated payment flows?
- Should Canton policy be described as Daml-native, app-layer, or institution-layer?
- Which Guardian modules are core for launch versus future roadmap: screening, attestations, delegated proving, registry, TEE privacy, or policy dashboards?
Source Coverage
| Topic | Primary sources used |
|---|---|
| Tempo | Tempo Protocol, Tempo Zones, Zone architecture, Zone bridging, Zone RPC, Tempo Transactions, Fees, TIP-20, TIP-403, Stablecoin DEX, private zones guides |
| Canton | Digital Asset Build 3.4 overview, key concepts, Daml intro/templates, participants, synchronizers, Ledger API, application architecture, multi-synchronizer reassignment |
| Miden | Miden core concepts, accounts, notes, state, transactions, private account model, commitments, nullifiers, and proofs |
| Miden Guardian | Guardian overview, architecture, components, data structures, security, operator guide, private multisig docs, Product Page: Miden Guardian, Guardian GTM and positioning notes |
Note: the Miden llms.txt sitemap was intentionally not used as authoritative because it is outdated relative to the live docs and product pages.
References
- Tempo Zones: https://docs.tempo.xyz/protocol/zones/
- Tempo Zone architecture: https://docs.tempo.xyz/protocol/zones/architecture
- Tempo Zone bridging: https://docs.tempo.xyz/protocol/zones/bridging
- Tempo Zone RPC: https://docs.tempo.xyz/protocol/zones/rpc
- Tempo Transactions: https://docs.tempo.xyz/protocol/transactions/
- Tempo TIP-20 Tokens: https://docs.tempo.xyz/learn/tempo/native-stablecoins
- Canton Network application overview: https://docs.digitalasset.com/build/3.4/overview/introduction.html
- Canton key concepts: https://docs.digitalasset.com/build/3.4/overview/key_concepts.html
- Daml smart contract intro: https://docs.digitalasset.com/build/3.4/tutorials/smart-contracts/intro.html
- Daml templates: https://docs.digitalasset.com/build/3.4/reference/daml/templates.html
- Canton participants: https://docs.digitalasset.com/operate/3.4/overview/index.html
- Canton synchronizers: https://docs.digitalasset.com/subnet/3.3/overview/index.html
- Canton multi-synchronizer reassignment: https://docs.digitalasset.com/overview/3.5/explanations/canton/multi-synchronizer.html
- Miden Guardian: https://docs.miden.xyz/builder/miden-guardian/
- Miden Guardian architecture: https://docs.miden.xyz/builder/miden-guardian/core-concepts/architecture
- Miden Guardian security: https://docs.miden.xyz/builder/miden-guardian/core-concepts/security
- Miden Guardian components: https://docs.miden.xyz/builder/miden-guardian/core-concepts/components
- Miden Guardian data structures: https://docs.miden.xyz/builder/miden-guardian/core-concepts/data-structures
- Miden Private Multisig: https://docs.miden.xyz/builder/private-multisig/
- Miden notes: https://docs.miden.xyz/core-concepts/miden-base/note/
- Miden state: https://docs.miden.xyz/core-concepts/miden-base/state/
- Product Page: Miden Guardian: https://www.notion.so/31199411cf9080078b0dd36c3d60c975