Skip to content

Developers

Build on Sigcore.

Wallets, rules and signing for your app, through one SDK. Your code never touches a private key, and your users never see a seed phrase.


Quick start

From install to first signature.

These steps retain the existing backend-issued sealed-session integration. For hosted sign-in, use your organisation’s Authentication → Integration setup. The iframe keeps wallet token material outside your page code.

Open Authentication → Integration for the hosted SDK example, backend routes, saved branding and deployment prerequisites.

  1. Step 1

    Install the SDK

    Browser-only, zero runtime dependencies, ES2022 modules.

    terminal
    npm install @sigcore/sdk@2.5.1
    
  2. Step 2

    Load it with your publishable key

    Publishable keys are safe to ship to the browser. On their own they grant no API access.

    sigcore.ts
    import { loadSigcore, type OrgId, type HexString } from "@sigcore/sdk";
    
    // Run in the browser, for example in a Next.js client component.
    const key = process.env.NEXT_PUBLIC_SIGCORE_PUBLISHABLE_KEY;
    const organizationId = process.env.NEXT_PUBLIC_AUTH_ORG_ID;
    if (!key || !organizationId) throw new Error("Missing integration configuration");
    const orgId = organizationId as OrgId;
    const sigcore = await loadSigcore(key);
    
  3. Step 3

    Legacy: create a sealed session from your backend

    For integrations with an existing verified Auth login, your organisation's confidential backend/BFF creates a user-bound wallet session sealed to the SDK receiver key. New hosted integrations should use Authentication → Integration instead.

    session.ts
    const receiverKey = sigcore.client.getIframeReceiverKey();
    if (!receiverKey) throw new Error("This bridge cannot receive sealed sessions");
    
    // Implement this route on your organisation's confidential backend/BFF with CSRF protection.
    // Verify your application's live user session, obtain fresh Auth proof,
    // and seal a user-bound Sigcore client secret to receiverKey.
    // Never trust browser-supplied user or organisation identity.
    const response = await fetch("/api/sigcore/session", {
      method: "POST",
      headers: { "content-type": "application/json" },
      credentials: "same-origin",
      body: JSON.stringify({ receiverKey }),
    });
    if (!response.ok) throw new Error("Could not create a Sigcore session");
    const { envelope } = await response.json();
    await sigcore.client.setClientSession(envelope);
    
  4. Step 4

    Create a wallet and sign

    Keys are generated inside the enclave. Your code only ever sees the public key, the policy ruling and the signature. If a rule requires approval, the intent comes back as pending instead of signed.

    wallet.ts
    const { wallet } = await sigcore.client.createWallet({
      orgId,
      name: 'Treasury',
      algorithm: 'ED25519', // or 'SECP256K1_ECDSA'
    })
    
    const { intent, policyRuling } = await sigcore.client.signMessage({
      orgId,
      walletId: wallet.id,
      messageHex: 'deadbeef' as HexString,
    })
    
    // decision: ALLOW, REQUIRE_APPROVAL,
    // REQUIRE_DELAY or DENY
    policyRuling.decision
    intent.signatureHex  // set when ALLOW
    

One organisation policy, two SDKs

Configure sign-in methods and saved appearance in the console's Authentication page. Its Integration tab connects createHostedAuthClient to @sigcore/sdk for hosted sign-in, session restore and canonical sign-out through your backend.

Install @trustcore/[email protected] from npm. Method discovery requires your real Auth origin, registered application and organisation, and allowed browser origin.

auth-methods.ts
import { createTrustCoreAuth } from "@trustcore/auth";

// Confirmed target: https://auth.sigcore.io; initial RP ID: auth.sigcore.io.
// This discovery factory reads policy; hosted flows use createHostedAuthClient.
const authOrigin = process.env.NEXT_PUBLIC_AUTH_API_URL;
const organizationId = process.env.NEXT_PUBLIC_AUTH_ORG_ID;
const applicationId = process.env.NEXT_PUBLIC_AUTH_APP_ID;
if (!authOrigin || !organizationId || !applicationId) {
  throw new Error("Missing TrustCore Auth configuration");
}

const auth = createTrustCoreAuth({ authOrigin, organizationId, applicationId });
const { descriptors } = await auth.getAvailableMethods();
// Use the returned labels and enabled methods in your sign-in UI.
// Discovery is public policy data; it does not establish a login session.
console.log(descriptors);

// These flags describe this discovery factory, not the hosted BFF transport.
auth.capabilities; // methodDiscovery: true; hostedLogin/session/logout: false

The published @sigcore/sdk 2.5.1 package also re-exports this factory from@sigcore/sdk/auth. Install @sigcore/[email protected] and @trustcore/[email protected] from npm. The wallet SDK remains independent when you import its main entry point.

Each client organisation runs a confidential backend/BFF that handles its exact registered Auth callback, verifies completion and creates a sealed Sigcore wallet session. Customer page JavaScript must never receive raw Auth sessions. Hosted login requires matching reviewed Auth, BFF and official bridge releases before enablement. The console's existing direct Auth client stores a first-party Auth session on sigcore.io; that client is not a hosted login SDK for customer origins. Appearance saves independently from method policy and is used by connected hosted login; the preview can also show unsaved drafts.

Authentication and policy. TrustCore Auth owns canonical identity and one login-method policy per organisation, including registered providers, RP ID, allowed login origins and redirects. Hosted SDK signIn, restoreSession and signOut require the configured confidential BFF and official capable bridge. Your backend must prove the live user and organisation before minting a wallet session. Sigcore separately enforces wallet scopes, signing rules and the fixed SDK bridge HTTP origin. Hosted transactions bind the registered application origin, authenticated backend, wallet session and SDK bridge. Browser options cannot authorize a user or raise limits.
Passkeys and session projections. The confirmed top-level hosted-login and passkey origin is https://auth.sigcore.io, with initial RP ID auth.sigcore.io. Deploy the matching hosted UI and Auth backend and verify readiness before enabling customer login. Saving settings does not publish packages or deploy those services. Use the RP ID returned by TrustCore Auth for the registered login origin. NYXDB session-status projection is proposed for trusted servers only; it does not authenticate a browser or replace a live Auth check. No live NYXDB login integration ships with this SDK.
Content Security Policy. Allow the bridge and the API: frame-src https://sdk.sigcore.io; connect-src 'self' https://api.sigcore.io

How it fits together

Three parties. One of them never sees a key.

Each client organisation runs a confidential backend/BFF for its exact registered Auth callback and sealed Sigcore wallet-session creation. TrustCore Auth remains independent. Hosted login through the SDK is unavailable in this prerelease.

Your frontend

  • Loads the SDK with a publishable key
  • Calls typed wallet methods
  • Never sees a key or session secret

Your confidential backend/BFF

  • Handles its exact registered Auth callback
  • Verifies the live user and organisation
  • Mints a short-lived Sigcore session
  • Seals it to the SDK's receiver key

Sigcore enclaves

  • Verify the session and your policy
  • Sign inside hardware-encrypted memory
  • Return the signature and a signed receipt

Policy reference

Rules as data.

These examples illustrate server-side controls. They are not SDK options or copy-ready API payloads. Register and enforce tenant and wallet policy on the server.

Spending and destination controls

Per-wallet limits, evaluated before the vault is contacted.

Daily caps on amount and transaction count, destination allowlists or blocklists, and chain restrictions. A request that fails any rule is denied without touching key material.

policy.json
{
  "name": "Treasury limits",
  "effect": "ALLOW",
  "rules": {
    "daily_limit": { "amount_usd": 10000, "tx_count": 50 },
    "destination_rules": {
      "require_whitelist": true,
      "whitelist": ["0x742d35Cc...", "0xA0b86991..."]
    },
    "allowed_chains": ["ethereum", "polygon"]
  }
}

Approvals

M-of-N approval above a threshold.

Transactions above the threshold create a pending activity. Signers approve or reject it; once the quorum is met the signature is produced. Pending activities expire after 24 hours by default.

policy.json
{
  "name": "Large transfers need two approvers",
  "rules": {
    "multi_sig": {
      "threshold": 2,
      "signers": ["user_01HX...", "user_01HY..."],
      "amount_threshold_usd": 5000
    }
  }
}

Time windows and time locks

Signing hours and cancellable delays.

Restrict signing to business hours and add a mandatory delay above a threshold. Time is anchored inside the enclave, so the host cannot roll the clock to bypass a window.

policy.json
{
  "name": "Business hours only",
  "rules": {
    "time_restrictions": {
      "start_hour": 9,
      "end_hour": 17,
      "allowed_days": ["mon", "tue", "wed", "thu", "fri"]
    },
    "time_lock_threshold_usd": 50000,
    "time_lock_duration_seconds": 3600
  }
}

Platform

Signature schemes, chains and the API surface.

Sigcore signs bytes. Any chain that uses one of these signature schemes works, including ones not listed here.

ED25519

Solana and other EdDSA chains

EdDSA signatures. Also the scheme behind signed receipts.

SECP256K1_ECDSA

Bitcoin, Ethereum and every EVM chain

ECDSA signatures on the secp256k1 curve.

HD wallets

BIP-32 and SLIP-10 seeds, BIP-44 accounts

One seed, many derived addresses. The seed never leaves the enclave either.

Supported todayEthereumSolanaBitcoinPolygonArbitrumOptimismBaseAvalanche

What the API covers

Wallets

Create, import, rename, delete. Flat keys or HD seeds with BIP-44 accounts and derived addresses.

Signing

Sign a payload. Returns immediately if policy passes, or a pending activity if approval is required.

Policies

Create and update organisation or wallet policies. Versioned, with a full change history.

Activities

List pending approvals, approve or reject them, and see who did what.

Receipts

Fetch the signed receipt for any wallet mutation and verify it offline.

Sessions

Mint, exchange and revoke the short-lived sessions that the SDK uses.


Your first signature is a few lines away.

Create an account to get a publishable key and a test organisation. No card required.