Skip to content

Commit 937c770

Browse files
gregnazariogregnazario
committed
docs: refocus multi-sig page on MultiKeyAccount, remove keyless
- Move MultiKeyAccount to top as the recommended approach - Demote MultiEd25519Account to legacy/compatibility section - Remove keyless accounts section (doesn't belong on multi-sig page) - Update Spanish and Chinese translations accordingly
1 parent dc6c58a commit 937c770

File tree

3 files changed

+120
-336
lines changed

3 files changed

+120
-336
lines changed

‎src/content/docs/build/sdks/rust-sdk/account/multi-sig-accounts.mdx‎

Lines changed: 40 additions & 112 deletions
Original file line numberDiff line numberDiff line change
@@ -1,66 +1,21 @@
11
---
2-
title: "Multi-Signature and Keyless Accounts"
3-
description: "Learn how to create and use multi-signature and keyless accounts with the Aptos Rust SDK"
2+
title: "Multi-Signature Accounts"
3+
description: "Learn how to create and use multi-signature accounts with the Aptos Rust SDK"
44
sidebar:
5-
label: "Multi-Sig & Keyless"
5+
label: "Multi-Sig Accounts"
66
---
77

88
import { Aside } from '@astrojs/starlight/components';
99

10-
The Aptos Rust SDK supports advanced account types beyond single-key accounts. This page covers multi-signature accounts that require multiple parties to authorize a transaction, and keyless accounts that authenticate through OpenID Connect (OIDC) providers instead of private keys.
10+
The Aptos Rust SDK supports multi-signature accounts that require multiple parties to authorize a transaction. This is useful for shared custody, organizational wallets, and governance scenarios where no single party should have unilateral control.
1111

12-
## MultiEd25519Account
12+
## MultiKeyAccount
1313

14-
A `MultiEd25519Account` implements an M-of-N threshold signing scheme using Ed25519 keys. This means you define N total signers, and any M of them must sign a transaction for it to be valid. This is useful for shared custody, organizational wallets, and governance scenarios where no single party should have unilateral control.
14+
A `MultiKeyAccount` implements an M-of-N threshold signing scheme that supports mixed cryptographic key types. You can combine Ed25519, Secp256k1, and Secp256r1 keys in a single account. This is the recommended approach for multi-signature accounts.
1515

1616
### Creating a Multi-Signature Account
1717

18-
To create a `MultiEd25519Account`, generate the individual Ed25519 key pairs first, then combine their public keys with a signing threshold:
19-
20-
```rust
21-
use aptos_sdk::account::{Ed25519Account, MultiEd25519Account};
22-
23-
// Generate three individual signers
24-
let signer_1 = Ed25519Account::generate();
25-
let signer_2 = Ed25519Account::generate();
26-
let signer_3 = Ed25519Account::generate();
27-
28-
// Create a 2-of-3 multi-signature account
29-
let multi_account = MultiEd25519Account::new(
30-
vec![
31-
signer_1.public_key().clone(),
32-
signer_2.public_key().clone(),
33-
signer_3.public_key().clone(),
34-
],
35-
2, // signatures_required
36-
)?;
37-
38-
println!("Multi-sig address: {}", multi_account.address());
39-
```
40-
41-
In this example, any two of the three signers can authorize a transaction. The `signatures_required` parameter must be between 1 and the total number of public keys (inclusive).
42-
43-
### Signing with a MultiEd25519Account
44-
45-
When signing a transaction, you provide the individual signers that will participate. The number of signers must meet or exceed the threshold:
46-
47-
```rust
48-
// Sign with signer_1 and signer_3 (2-of-3 threshold met)
49-
let signature = multi_account.sign_with_signers(
50-
&message,
51-
vec![&signer_1, &signer_3],
52-
)?;
53-
```
54-
55-
<Aside type="note">
56-
All public keys used in a `MultiEd25519Account` must be Ed25519 keys. If you need to mix different key types, use `MultiKeyAccount` instead.
57-
</Aside>
58-
59-
## MultiKeyAccount
60-
61-
A `MultiKeyAccount` extends the multi-signature concept by allowing different cryptographic key types in the same threshold scheme. You can combine Ed25519, Secp256k1, and Secp256r1 keys in a single account. This is useful when signers use different wallet software or hardware with different cryptographic capabilities.
62-
63-
### Creating a Mixed-Key Multi-Signature Account
18+
To create a `MultiKeyAccount`, generate the individual key pairs first, then combine their public keys with a signing threshold:
6419

6520
```rust
6621
use aptos_sdk::account::{
@@ -70,95 +25,68 @@ use aptos_sdk::account::{
7025
// Generate signers with different key types
7126
let ed25519_signer = Ed25519Account::generate();
7227
let secp256k1_signer = Secp256k1Account::generate();
28+
let ed25519_signer_2 = Ed25519Account::generate();
7329

74-
// Create a 2-of-2 multi-key account with mixed key types
30+
// Create a 2-of-3 multi-key account with mixed key types
7531
let multi_key_account = MultiKeyAccount::new(
7632
vec![
7733
AnyPublicKey::Ed25519(ed25519_signer.public_key().clone()),
7834
AnyPublicKey::Secp256k1(secp256k1_signer.public_key().clone()),
35+
AnyPublicKey::Ed25519(ed25519_signer_2.public_key().clone()),
7936
],
8037
2, // signatures_required
8138
)?;
8239

8340
println!("Multi-key address: {}", multi_key_account.address());
8441
```
8542

43+
In this example, any two of the three signers can authorize a transaction. The `signatures_required` parameter must be between 1 and the total number of public keys (inclusive). Signers can use any supported key type — Ed25519, Secp256k1, or Secp256r1 — allowing one signer to use a software wallet while another uses a hardware device with different cryptographic capabilities.
44+
8645
### Signing with a MultiKeyAccount
8746

88-
Similar to `MultiEd25519Account`, you provide the individual signers that will participate:
47+
When signing a transaction, you provide the individual signers that will participate. The number of signers must meet or exceed the threshold:
8948

9049
```rust
50+
// Sign with ed25519_signer and secp256k1_signer (2-of-3 threshold met)
9151
let signature = multi_key_account.sign_with_signers(
9252
&message,
9353
vec![&ed25519_signer, &secp256k1_signer],
9454
)?;
9555
```
9656

97-
The key advantage of `MultiKeyAccount` over `MultiEd25519Account` is flexibility: one signer might use an Ed25519 key stored in a software wallet, while another uses a Secp256k1 key from a hardware device that only supports Bitcoin-style cryptography.
98-
99-
## Keyless Accounts
100-
101-
Keyless accounts allow users to authenticate with their existing identity provider (such as Google or Apple) instead of managing private keys. Under the hood, the SDK uses OpenID Connect (OIDC) tokens combined with ephemeral key pairs and zero-knowledge proofs to produce valid transaction signatures.
57+
## MultiEd25519Account (Legacy)
10258

103-
<Aside type="note">
104-
Keyless accounts require the `keyless` feature flag, which is not enabled by default. Add it to your `Cargo.toml`:
105-
106-
```toml filename="Cargo.toml"
107-
[dependencies]
108-
aptos-sdk = { git = "https://github.com/aptos-labs/aptos-rust-sdk", package = "aptos-sdk", features = ["keyless"] }
109-
```
59+
<Aside type="caution">
60+
`MultiEd25519Account` exists for compatibility with older accounts on-chain. For new multi-signature accounts, use `MultiKeyAccount` instead — it supports the same Ed25519-only configurations plus mixed key types.
11061
</Aside>
11162

112-
### How Keyless Authentication Works
113-
114-
1. **Ephemeral Key Pair** -- The SDK generates a short-lived `EphemeralKeyPair` that is used for signing during a single session.
115-
2. **OIDC Authentication** -- The user authenticates with their identity provider (Google, Apple, etc.) and receives a JWT token.
116-
3. **Proof Generation** -- A zero-knowledge proof is generated that links the OIDC identity to the ephemeral key pair without revealing the user's identity on-chain.
117-
4. **Transaction Signing** -- The ephemeral key pair signs the transaction, and the proof is included in the authenticator.
118-
119-
### Creating a Keyless Account
63+
A `MultiEd25519Account` implements an M-of-N threshold signing scheme restricted to Ed25519 keys only. If you need to interact with an existing on-chain multi-sig account that was created with `MultiEd25519`, you can load it as follows:
12064

12165
```rust
122-
use aptos_sdk::account::keyless::{EphemeralKeyPair, KeylessAccount};
123-
124-
// Step 1: Generate an ephemeral key pair
125-
let ephemeral_key_pair = EphemeralKeyPair::generate();
126-
127-
// Step 2: Get the nonce to include in the OIDC authentication request
128-
let nonce = ephemeral_key_pair.nonce();
66+
use aptos_sdk::account::{Ed25519Account, MultiEd25519Account};
12967

130-
// Step 3: Use the nonce in your OIDC flow to obtain a JWT token
131-
// This step happens externally (redirect user to identity provider)
132-
// let jwt_token = authenticate_with_provider(nonce);
68+
// Generate three individual signers (all must be Ed25519)
69+
let signer_1 = Ed25519Account::generate();
70+
let signer_2 = Ed25519Account::generate();
71+
let signer_3 = Ed25519Account::generate();
13372

134-
// Step 4: Create the keyless account using the JWT and ephemeral key pair
135-
// let keyless_account = KeylessAccount::new(jwt_token, ephemeral_key_pair)?;
136-
// println!("Keyless address: {}", keyless_account.address());
73+
// Create a 2-of-3 multi-signature account
74+
let multi_account = MultiEd25519Account::new(
75+
vec![
76+
signer_1.public_key().clone(),
77+
signer_2.public_key().clone(),
78+
signer_3.public_key().clone(),
79+
],
80+
2, // signatures_required
81+
)?;
13782
```
13883

139-
<Aside type="caution" title="External Service Dependency">
140-
Keyless accounts depend on external OIDC providers and the Aptos pepper and prover services. Your application must handle the OIDC redirect flow and token exchange outside of the SDK. The SDK handles the cryptographic operations once you have a valid JWT token.
141-
</Aside>
142-
143-
For a complete walkthrough of setting up keyless authentication, including the OIDC integration and proof generation, see the [Aptos Keyless guide](/build/guides/aptos-keyless).
144-
145-
## Choosing an Account Type
146-
147-
The following table compares the available account types to help you select the right one for your use case:
84+
Signing works the same way as `MultiKeyAccount`:
14885

149-
| Account Type | Signers Required | Key Types Supported | Best For |
150-
| --------------------- | ---------------- | ----------------------------- | -------------------------------------------------------- |
151-
| `Ed25519Account` | 1 | Ed25519 only | General purpose wallets and applications |
152-
| `Secp256k1Account` | 1 | Secp256k1 only | Interoperability with Bitcoin/Ethereum tooling |
153-
| `Secp256r1Account` | 1 | Secp256r1 (P-256) only | WebAuthn, passkeys, and secure hardware enclaves |
154-
| `MultiEd25519Account` | M-of-N | Ed25519 only | Shared custody with uniform key infrastructure |
155-
| `MultiKeyAccount` | M-of-N | Ed25519, Secp256k1, Secp256r1 | Shared custody across diverse signer environments |
156-
| `KeylessAccount` | 1 (OIDC) | Ephemeral + OIDC proof | Consumer applications where users should not manage keys |
157-
158-
### Decision Guidelines
159-
160-
- **Single user, standard wallet** -- Use `Ed25519Account`. It is the most widely supported and has the best performance.
161-
- **Cross-chain compatibility** -- Use `Secp256k1Account` if your users come from the Bitcoin or Ethereum ecosystem and already have Secp256k1 keys.
162-
- **Hardware-backed authentication** -- Use `Secp256r1Account` for passkey and WebAuthn integrations where the private key lives in a secure enclave.
163-
- **Organizational or shared funds** -- Use `MultiEd25519Account` when all signers use Ed25519 keys, or `MultiKeyAccount` when signers use different key types.
164-
- **Consumer-facing applications** -- Use `KeylessAccount` to let users sign in with Google, Apple, or other OIDC providers without needing to understand private keys or mnemonics.
86+
```rust
87+
// Sign with signer_1 and signer_3 (2-of-3 threshold met)
88+
let signature = multi_account.sign_with_signers(
89+
&message,
90+
vec![&signer_1, &signer_3],
91+
)?;
92+
```

0 commit comments

Comments
 (0)