Create Wallets

Wallet creation is the first place where the SDK’s prepared-transaction model shows up clearly.

Two create modes

You can create a wallet either:

from a policy with policyId / policy_id
from an inline initialUser / initial_user

If the policy ID is omitted, the backend can create a no-recovery wallet from the inline authority you provide. Common authority shapes are ed25519, secp256k1, and secp256r1.

Basic create flow

TypeScript

const created = await swig.wallets.create({
  feePayer,
  initialUser: {
    ed25519: {
      publicKey: userPublicKey,
    },
  },
});

created = await swig.wallets.create(
    fee_payer=fee_payer,
    initial_user={
        "ed25519": {
            "publicKey": user_public_key,
        },
    },
)

Passkey-backed creation works the same way with secp256r1:

TypeScript

const created = await swig.wallets.create({
  feePayer,
  initialUser: {
    secp256r1: {
      publicKey: passkeyPublicKey,
    },
  },
});

created = await swig.wallets.create(
    fee_payer=fee_payer,
    initial_user={
        "secp256r1": {
            "publicKey": passkey_public_key,
        },
    },
)

EVM-backed creation works the same way with secp256k1:

TypeScript

const created = await swig.wallets.create({
  feePayer,
  initialUser: {
    secp256k1: {
      publicKey: evmPublicKey,
    },
  },
});

created = await swig.wallets.create(
    fee_payer=fee_payer,
    initial_user={
        "secp256k1": {
            "publicKey": evm_public_key,
        },
    },
)

What you get back

The result is not just one transaction. It is a categorized create plan:

TypeScript / Python	Meaning
`wallet`	the config address and wallet address
`transactions`	full ordered transaction list
`clientAuthorityTransactions` / `client_authority_transactions`	transactions the initial authority must sign
`operatorSignedTransactions` / `operator_signed_transactions`	transactions already signed by the backend operator
`feePayerOnlyTransactions` / `fee_payer_only_transactions`	transactions that only need fee payer or sponsor handling

For plain non-recovery creates, this usually collapses to one main creation transaction plus any client authority signing the create flow needs.

Recovery-enabled create flows

If the policy is recovery-enabled and the SDK can derive both the requester authority and guardian information, create(...) also returns recoverySetup / recovery_setup. That setup plan is not the same thing as completed recovery setup. It is the follow-up input for wallet.recovery.prepareSetup(...) / wallet.recovery.prepare_setup(...).

What to submit

Always submit the prepared transactions exactly in the returned order. If the client-authority transaction collection is not empty, those transactions must be signed by the client authority before submission. If the operator-signed transaction collection is not empty, treat those transactions as already operator signed. They still need fee payer or sponsor submission, but not another authority signature.

Start Here

Set Up Access

Build Wallet Flows

Add Recovery

Operate in Production

Workspace Admin

Create Wallets

Two create modes

Basic create flow

What you get back

Recovery-enabled create flows

What to submit

What to read next

​Two create modes

​Basic create flow

​What you get back

​Recovery-enabled create flows

​What to submit

​What to read next

Two create modes

Basic create flow

What you get back

Recovery-enabled create flows

What to submit

What to read next