Skip to main content
Multi-party workflows are where Canton’s architecture shines compared to Ethereum. This page covers the key patterns and how to think about them differently.

The Core Difference

On Ethereum, multi-party agreement is a pattern you implement. On Canton, it’s a protocol guarantee.

The Propose-Accept Pattern

Since Canton requires all signatories to authorize contract creation, you can’t create a multi-party contract unilaterally. The standard pattern is propose-accept:

In Daml

Compare to Ethereum

The Canton version:
  • Authorization is enforced by the protocol, not by application-level checks
  • State transitions are atomic, so partial or inconsistent states don’t arise
  • Visibility is automatically scoped to the involved parties

Delegation Patterns

Canton supports sophisticated delegation where one party grants another the ability to act on their behalf.

Controller Delegation

Delegation via Separate Contract

Multi-Step Workflows

For workflows requiring multiple parties in sequence:

Workflow State Machine

Atomic Multi-Contract Operations

Canton can atomically update multiple contracts in a single transaction:

Why This Matters

On Ethereum, atomic swaps require:
  • Escrow contracts
  • Time-locked phases
  • Failure recovery logic
  • Careful reentrancy protection
On Canton, atomicity is guaranteed by the protocol. If any part fails, nothing happens.

Privacy in Multi-Party Workflows

Each party only sees their relevant portion:

Common Workflow Patterns

Voting Example

Migration Checklist

Practical checklist for migrating from Ethereum.

Module 3: Daml

Start writing Daml smart contracts.