Create Wallets

Prepare a new Swig wallet from a saved policy template or an inline authority. Your application signs and submits the returned transactions to create it on-chain.

Two create modes

You can create a wallet either:

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

If the policy ID is omitted, the backend creates the wallet from the inline authority you provide. Supported authority shapes are ed25519, secp256k1, and secp256r1.

Basic create flow

TypeScript

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

An application may provide a secp256r1 public key for a passkey-backed authority. Credential creation and signing stay outside the Developer SDK:

TypeScript

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

EVM-backed creation works the same way with secp256k1:

TypeScript

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

What you get back

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

TypeScript / Python	Meaning
`wallet`	the config address, wallet address, and resolved network
`transactions`	full ordered transaction list
`clientAuthorityTransactions` / `client_authority_transactions`	transactions with explicit embedded `secp256r1` or `secp256k1` signature requests
`feePayerOnlyTransactions` / `fee_payer_only_transactions`	transactions without explicit signature requests; verify the Solana required signer set before treating them as fee-payer-only
`creationTransaction` / `creation_transaction`	the create transaction itself

For a plain create, this usually collapses to one creation transaction whose only required transaction signer is the fee payer. Policy-driven follow-up instructions can add other signer requirements.

Networks

Both SDKs resolve the network from the call and then the client default. Wallet creation requires one of those values to be set.

What to submit

Always submit the prepared transactions exactly in the returned order. If the client-authority collection is not empty, your application must obtain and patch each requested embedded signature outside the server SDK before submission. An empty collection does not prove that the transaction needs no application signature; inspect each serialized transaction’s required signer set as well. The field name comes from the hosted API schema; it is not a browser SDK surface.

Signers

Basic signing support for application-owned wallets and passkeys

Add Roles

Attach a scoped role to an existing wallet

Transfer SOL and Tokens

Wallet actions after create

Read Wallet State

Balances, token activity, and roles

Sponsor & Submit

Swig-backed fee sponsorship

Start Here

Wallet Access

Build Wallet Flows

Use Cases

Balances and Funding

Operate in Production

Workspace Admin

Create Wallets

Two create modes

Basic create flow

What you get back

Networks

What to submit

What to read next

Signers

Add Roles

Transfer SOL and Tokens

Read Wallet State

Sponsor & Submit

​Two create modes

​Basic create flow

​What you get back

​Networks

​What to submit

​What to read next

Signers

Add Roles

Transfer SOL and Tokens

Read Wallet State

Sponsor & Submit

Two create modes

Basic create flow

What you get back

Networks

What to submit

What to read next