Skip to main content

Overview

Tier 2 and Tier 3 chains both use the same raw signing primitives from Dynamic embedded wallets. Tier 2 includes helper methods and EOA support; Tier 3 is derivation only with no official helpers. Gas handling and policies are not yet supported for either tier. Dynamic supports three Tier 1 embedded wallets: an EVM wallet (secp256k1), a Solana wallet (Ed25519), and a Bitcoin wallet (secp256k1). Because many blockchains share these same elliptic curves, you can derive addresses and sign transactions on additional chains without creating new keys. The technique is straightforward: extract the public key from the existing wallet, apply chain-specific hashing and encoding, and use Dynamic’s raw signing capability to sign chain-native transactions.

User Management

Tier 2 chains are not natively represented in Dynamic’s UI or session model. You are responsible for managing the user-facing experience: displaying derived addresses, associating them with your user records, and handling any chain-specific session or account state yourself.

Key Security Warning

Exporting the root wallet key exposes all derived addresses. The EVM and Solana embedded wallet keys are the cryptographic root of every address you derive from them. If you export the private key of the EVM wallet (secp256k1) or the Solana wallet (Ed25519) — for example via exportWaasPrivateKey — anyone with that key can independently derive and control all Tier 2 addresses generated from it, across every chain. Never expose or transmit root wallet keys unless you have explicitly designed for that use case.

Bitcoin Signing

Bitcoin is a Tier 1 chain with full embedded wallet support. Its secp256k1 signing primitives can also be used for Tier 2-style derivation — signing for other secp256k1 chains using the Bitcoin embedded wallet as the root, in the same way the EVM wallet is used. Complete example code is not yet published, but the signing primitives are available. Reach out if you need guidance.

How It Works

Derived wallets follow a two-step pattern:
  1. Create embedded wallets — When a user authenticates, create both EVM and Solana embedded wallets using Dynamic. These wallets hold the root keys.
  2. Use raw signing — Extract the public key from the appropriate root wallet, derive a chain-native address, and sign transactions using Dynamic’s signMessage or signRawMessage methods.

Ed25519 chains (from Solana wallet)

For Ed25519-based chains (Aptos, Cardano, NEAR, Mavryk), the Solana wallet’s base58 address directly decodes to the 32-byte Ed25519 public key. You apply chain-specific hashing to derive an address, and use signMessage to sign transaction digests.

secp256k1 chains (from EVM wallet)

For secp256k1-based chains (Cosmos, XRP, Tron), you recover the compressed public key by signing a deterministic SHA-256 digest of a recovery string with the EVM wallet using signRawMessage, then using ecrecover:
Tron is a special case — since Tron addresses are derived from the same keccak256 hash as EVM, you can derive a Tron address directly from the EVM address without key recovery. See the Tron page for details.

Common Setup

Initialize Dynamic Client

Create Embedded Wallets

Shared Dependencies

All chain implementations use these utility packages:

Byte Utilities

These helper functions are used across all chain implementations:

Full Example: Aptos (Ed25519)

This walkthrough demonstrates the complete flow using Aptos as an example.
1

Extract Ed25519 public key from Solana wallet

The Solana wallet address is a base58-encoded Ed25519 public key. Decode it to get the raw 32-byte key:
2

Derive the Aptos address

Aptos uses a single-key Ed25519 scheme. The address is SHA3-256 of the public key concatenated with a scheme byte (0x00):
3

Build and sign a transaction

Build an Aptos transaction using the @aptos-labs/ts-sdk, generate the signing bytes, and sign with the Solana wallet:
4

Submit the transaction

Assemble the authenticator and submit via the SDK:
For the complete Aptos implementation including BCS serialization, message signing, and verification, see the Aptos page.

Ed25519 Chains (from Solana Wallet)

Aptos

Aptos uses Ed25519 with SHA3-256 hashing for address derivation and BCS (Binary Canonical Serialization) for transaction encoding. Full implementation with transfers and BCS serialization →

secp256k1 Chains (from EVM Wallet)

Cosmos

Cosmos SDK chains use secp256k1 with bech32-encoded addresses. The public key is recovered from the EVM wallet via ecrecover. The same key derives addresses for any Cosmos chain by changing the bech32 prefix (e.g., cosmos for Cosmos Hub, osmo for Osmosis). Full implementation with Protobuf transactions →

Tron

Tron uses secp256k1 with keccak256 hashing — the same cryptographic scheme as Ethereum. Since Tron addresses are derived from the same public key hash, you can derive a Tron address directly from the EVM address by swapping the 0x prefix for 0x41 and base58check-encoding the result. Full implementation with TRX and TRC20 transfers →
Last modified on March 31, 2026