Portal guide

The Sigil portal is where you manage your company, mint API keys, choose which blockchain networks your users can access, and configure how they sign in.

Creating your company

1. Go to platform.sigilkeys.com/register.
2. Enter your email — you’ll receive a one-time code. Check your inbox.
3. Pick a company name and a unique slug (lowercase, used in URLs).

API keys

Go to API keys in the sidebar.

Key type	Purpose	Where it lives
Publishable (pk_live_…)	Identifies your company from the browser. Safe to commit and ship in your bundle.	Your frontend code / SDK config
Secret (sk_live_…)	Server-to-server calls (list wallets, read shares). Never expose to the browser.	Your backend, env vars

Click New key, choose the type, and copy the value. The cleartext is shown only once — Sigil stores a hash.

Secret keys support IP allowlisting (CIDRs). Use it to lock the key to your server IPs.

Networks

Go to Networks in the sidebar.

This is where you choose which blockchain networks your end users will have wallets on. Ethereum (EVM) is always enabled.

Network	Curve	What it enables
EVM (always on)	secp256k1	Ethereum, Polygon, Arbitrum, Base, BSC…
Solana	Ed25519	Solana ecosystem
Bitcoin	secp256k1	Bitcoin (bech32 addresses)
Cosmos	secp256k1	Cosmos Hub and IBC chains
Near	Ed25519	Near Protocol
Aptos	Ed25519	Aptos
Stellar	Ed25519	Stellar network
Tron	secp256k1	Tron

Toggle the networks you need and click Save. When a user creates a wallet, Sigil generates one keypair per unique curve required by your enabled networks. For example, enabling Ethereum + Solana + Bitcoin creates two keypairs (secp256k1 and Ed25519).

Tip

Enabling a new network for an existing company won’t retroactively create keypairs for users who already have wallets. Those users will generate the missing keypair on their next sign-in.

Authentication

Go to Authentication in the sidebar.

Two modes:

Sigil hosted (default)

Sigil handles the login flow inside the wallet iframe: the user enters their email, receives a one-time code, and gets a session. No integration needed on your side — it just works.

Bring your own (OIDC)

If your app already authenticates users (Auth0, Cognito, Firebase, Keycloak, etc.), choose this mode and enter:

• Issuer URL — the OIDC discovery endpoint (e.g. https://accounts.google.com)
• Audience — the aud claim your JWT carries
• User ID claim (advanced) — defaults to sub
• Email claim (advanced) — defaults to email

Your app passes the JWT to the SDK via getToken(), and Sigil validates it against your provider’s JWKS.

Allowed origins

Go to Settings in the sidebar.

Add every origin where your app runs (e.g. https://app.yourcompany.com). The wallet iframe rejects postMessage from any origin not on this list.

Recovery

Go to Recovery in the sidebar.

Two custody models for the recovery share:

Customer managed (recommended)

You host a webhook endpoint. Sigil sends the recovery share to your backend at wallet creation; your backend stores it and returns it during recovery. You control the share — Sigil can’t recover wallets without your cooperation.

Set up: enter your webhook URL and note the HMAC secret for signature verification.

Sigil managed

Sigil stores the recovery share encrypted under a separate KMS key. Simpler to set up (no webhook needed), but Sigil holds two of the three shares.

Branding

Also under Settings: customize the logo URL, brand color, and support email that appear in the wallet iframe and recovery emails.

What’s next

• Quickstart — embed a wallet in 5 minutes
• Architecture — how the pieces fit together
• SDK install — install the SDK