> ## Documentation Index
> Fetch the complete documentation index at: https://build.onswig.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<CodeGroup dropdown>
  ```typescript TypeScript theme={null}
  const created = await swig.wallets.create({
    feePayer,
    initialUser: {
      ed25519: {
        publicKey: userPublicKey,
      },
    },
  });
  ```

  ```python Python theme={null}
  created = await swig.wallets.create(
      fee_payer=fee_payer,
      initial_user={
          "ed25519": {
              "publicKey": user_public_key,
          },
      },
  )
  ```
</CodeGroup>

Passkey-backed creation works the same way with `secp256r1`:

<CodeGroup dropdown>
  ```typescript TypeScript theme={null}
  const created = await swig.wallets.create({
    feePayer,
    initialUser: {
      secp256r1: {
        publicKey: passkeyPublicKey,
      },
    },
  });
  ```

  ```python Python theme={null}
  created = await swig.wallets.create(
      fee_payer=fee_payer,
      initial_user={
          "secp256r1": {
              "publicKey": passkey_public_key,
          },
      },
  )
  ```
</CodeGroup>

EVM-backed creation works the same way with `secp256k1`:

<CodeGroup dropdown>
  ```typescript TypeScript theme={null}
  const created = await swig.wallets.create({
    feePayer,
    initialUser: {
      secp256k1: {
        publicKey: evmPublicKey,
      },
    },
  });
  ```

  ```python Python theme={null}
  created = await swig.wallets.create(
      fee_payer=fee_payer,
      initial_user={
          "secp256k1": {
              "publicKey": evm_public_key,
          },
      },
  )
  ```
</CodeGroup>

## 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.

## What to read next

* Use [Transfers and Swaps](/developer-sdk/transfers-swaps-and-signing) for
  wallet actions after create
* Use [Recovery](/developer-sdk/recovery-flows) if the created wallet should
  support a guardian flow
* Use [Client Signing](/developer-sdk/client-signing) for Ed25519, passkey, and
  EVM client signatures
* Use [Sponsor & Submit](/developer-sdk/sponsor-and-submit) if your app wants
  Swig-backed fee sponsorship