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.
- Step 1
Install the SDK
Browser-only, zero runtime dependencies, ES2022 modules.
terminalnpm install @sigcore/sdk@2.5.1 - 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.tsimport { 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); - 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.tsconst 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); - 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.tsconst { 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.
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.
frame-src https://sdk.sigcore.io; connect-src 'self' https://api.sigcore.ioHow 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.
{
"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.
{
"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.
{
"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.
Solana and other EdDSA chains
EdDSA signatures. Also the scheme behind signed receipts.
Bitcoin, Ethereum and every EVM chain
ECDSA signatures on the secp256k1 curve.
BIP-32 and SLIP-10 seeds, BIP-44 accounts
One seed, many derived addresses. The seed never leaves the enclave either.
What the API covers
Create, import, rename, delete. Flat keys or HD seeds with BIP-44 accounts and derived addresses.
Sign a payload. Returns immediately if policy passes, or a pending activity if approval is required.
Create and update organisation or wallet policies. Versioned, with a full change history.
List pending approvals, approve or reject them, and see who did what.
Fetch the signed receipt for any wallet mutation and verify it offline.
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.