SETHU (Semantic Electronic Trust Harbour Utility) — A trusted digital harbour for interoperable trust services.
Sign up, connect, and use SETHU services—whether you run a KYC platform, credential issuer, trade platform, or any application that needs verifiable anchored proofs. Getting started →
Searchable reference for architecture, APIs, operations, governance, and migration. SETHU is not limited to TokCredAI—any platform can integrate.
Knowledge Index
How to apply for a SETHU account
Getting started
All applicants must hold a TokCred individual DID with an active TKYC Passport (IST). Entity Customers and Node Operators additionally need an approved TokCred entity DID.
Visit /signup and complete the enquiry form: org name, contact email, phone, TokCred individual DID, entity DID (if applicable), proposed role, service areas, expected monthly volumes, and primary use case.
You receive an acknowledgement email from operations@sethu.foundation within minutes. Our Operations team reviews in 3–5 business days.
Once approved internally, a commercial quotation is emailed with a Commitment ID (format: CMT-YEAR-XXXXXX).
Commercial onboarding pipeline
Getting started
Stage 1 — PENDING_OPS_REVIEW: Application received; ACK email sent immediately.
Stage 2 — OPS_QUOTE_REVIEW: Operations team generates a commercial quotation from your selected services and expected volumes. Tier (Starter / Growth / Enterprise) is auto-selected.
Stage 3 — QUOTE_PENDING_ADMIN: Ops submits the quote for internal Admin approval.
Stage 4 — CONTRACT_PENDING_SIGNATURE: Quote approved; Commitment ID generated (CMT-YEAR-XXXXXX); DocuSign agreement sent to your contact email.
Stage 5 — DEPOSIT_PENDING: Agreement signed; payment slip emailed with SETHU Foundation bank details.
Stage 6 — DEPOSIT_CONFIRMED: Operations confirms receipt of ₹1,00,000 + 18% GST deposit. Include CMT ID in payment narration.
Stage 7 — ACTIVE: Account created; welcome email with one-time Firebase activation link sent.
How to connect and use SETHU
Getting started
After account activation, click the link in the welcome email to set your Firebase password and sign in.
Get API keys: Dashboard → API Keys → Create (shown once — store securely).
Choose integration mode: Dashboard → Integration Center → LEDGER_VIA_SETHU, AGENT_VIA_SETHU, or FULL_VIA_SETHU.
Apply the generated config bundle (SETHU_LEDGER_URL, SETHU_API_KEY, etc.) to your application.
Run validation checks in Integration Center and activate.
How to anchor to the ledger
Getting started
Any platform (KYC, credentials, entitlements, trade) needing verifiable anchored proofs can use SETHU.
POST /v1/sethu/ledger/ist to write; GET /v1/sethu/ledger/mirror/:did to read.
Ledger access to Hiero (and optional Hyperledger Fabric) via JSON-RPC; writes to anchor contract, reads from mirror.
Auth: Authorization: Bearer <SETHU_API_KEY> and X-API-Key header.
What is SETHU?
Platform
SETHU (Semantic Electronic Trust Harbour Utility) is a trusted digital harbour for interoperable trust services. It is a connector DPI for eligibility and proofs. Connects identity systems, document wallets, payment rails, and sector connectors.
Enables proof reuse, selective disclosure, and governed agentic automation via Bharat MCP.
Cost-neutral public good; future CBDC-based event settlement.
Who is SETHU for?
Platform
Entity Customers: organisations issuing or verifying credentials on their own platform using SETHU ledger, DID, and AI blockchain services. Requires approved TokCred entity DID.
Regulators and Observers: government bodies and auditors with read-only access to network activity. Admin-created accounts.
SETHU is not limited to TokCredAI — any platform needing ledger anchoring, DID issuance, or AI blockchain services can integrate.
SETHU customer roles
Platform
ENTITY_CUSTOMER — organisations using SETHU ledger, DID, and AI services. Self-service application. Requires TokCred individual DID (IST) + approved entity DID.
NODE_OPERATOR — organisations operating a SETHU network node. Self-service application. Requires TokCred individual DID (IST) + approved entity DID.
REGULATOR — government or regulatory body. Read-only network access. Admin-created. Requires TokCred individual DID (IST).
OBSERVER — external auditor or watch-group member. Read-only. Admin-created. Requires TokCred individual DID (IST).
SETHU (Foundation staff) — sub-roles: SUPER_ADMIN (full access, direct mutations), ADMIN (all mutations via maker-checker), OPS_STAFF (application and deposit management). Admin-created by SuperAdmin only.
Platform Overview
Platform
SETHU platform operates ledger, AI blockchain services, and DID infrastructure; governed by the SETHU Foundation (Section 8 non-profit). Node operators are for-profit. Serves any platform—TokCredAI is one such platform.
All accounts are identity-gated: every customer must hold a verified TokCred individual DID with an active TKYC Passport. Entity and node accounts additionally require an approved TokCred entity DID.
Ledger (Hedera Hiero + optional Hyperledger Fabric, mirror-read); AI (registration anchoring + negative-events log); DID (issuance, prove, resolve).
Maker-checker governance: ADMIN mutations require SuperAdmin approval via SethuChangeRequest. Full audit trail with severity-graded alerts.
Ledger: Anchored proof write routing, mirror/read access; Hiero (domestic) and Hedera (public); optional Hyperledger Fabric. Access via JSON-RPC.
AI: Registration anchoring to blockchain (on request); negative-events log from TokCredAI runtime to blockchain (on request). Agent registry, enrollment, and runtime are in TokCredAI.
DID: Issuance (did:tokcred:{ISO3}:{type}:{uuid} format), prove, resolve; post-quantum key support (ML-DSA-65/87).
Wallet: Credential store (issuer → holder DID), list, selective disclosure. Supports JWT (SD-JWT) and AnonCreds.
Every SETHU account is gated by a TokCred individual DID with an active TKYC Passport (IST). Entity and node accounts additionally require an approved TokCred entity DID.
Portal access: Firebase bearer token (sign in via welcome email activation link).
Service-to-service access: SETHU API key. Keys are shown once at creation — store securely.
API key lifecycle: create, rotate, revoke; last-used timestamp tracked. Manage in Dashboard → API Keys.
SETHU staff roles: SUPER_ADMIN acts directly; ADMIN mutations go through SethuChangeRequest maker-checker; OPS_STAFF manages applications and deposit confirmations.
Maker-checker and audit
Platform
Every mutation performed by an ADMIN staff account creates a SethuChangeRequest that must be approved by a SuperAdmin before taking effect.
Compliance checklist; health probe every 15 seconds; audit-oriented visibility.
Ledger Services
Ledger
Anchored proof write and mirror-read APIs. Local mode: platform handles writes directly. SETHU-routed: POST /v1/sethu/ledger/ist; GET /v1/sethu/ledger/mirror/:did.
Access to Hiero via JSON-RPC; optional Hyperledger Fabric. Writes to anchor contract; read from mirror. Batch anchoring for auditability.
For any platform anchoring proofs; multiple attestation types supported.
Bharat MCP
AI
AI studio and agent runtime operate in TokCredAI. SETHU provides blockchain services for AI: (1) anchor agent registration to the blockchain on request; (2) log negative events from TokCredAI's AI agent at runtime to the blockchain on request.
Agent registry, enrollment, and runtime (orchestrator, sub-agents, traces) are in TokCredAI.
AI / Agent Services
AI
Registration anchoring: anchor AI agent registration to the blockchain on request; returns blockchain response.
Negative events log: log negative events from TokCredAI's AI agent at runtime to the blockchain on request; returns blockchain response for compliance and audit.
Agent registry, enrollment, runtime, and traces are in TokCredAI.
DID Services
Identity
DID format: did:tokcred:{ISO3}:{type}:{uuid} — embeds ISO 3166-1 alpha-3 country code, immutable at issuance.
Binding paths: Government ID integration; eSignet/MOSIP for open identity; Fallback (Firebase + MFA).
Credentials: SETHU supports both JWT (e.g. SD-JWT) and AnonCreds for issuance, storage, and selective disclosure.
No raw identity persistence; traceable audit events; Gov Attester adapter. Post-quantum keys (ML-DSA-65, ML-DSA-87).
Selective Disclosure
Compliance
Derived proofs (e.g. over 18, meets threshold) without full document sharing. Supported in both JWT (SD-JWT) and AnonCreds flows.
Right to erasure supported. Consent as code; data minimisation.
Usage, Billing, and Reports
Billing
Upfront security deposit: ₹1,00,000 + 18% GST (₹1,18,000 total). Paid by bank transfer after signing commercial agreement. Include Commitment ID (CMT-YEAR-XXXXXX) in payment narration. Refundable on account closure.
Right to erasure; STRIDE threat model; security brief.
Credential formats (JWT and AnonCreds)
Identity
SETHU supports both JWT-based credentials (including SD-JWT for selective disclosure) and AnonCreds.
Issuers and verifiers can use the format that fits their ecosystem; wallet store and disclose APIs work with both.
JWT: compact, widely supported; SD-JWT enables selective disclosure of claims. AnonCreds: privacy-preserving, zero-knowledge presentation; schema-based credentials and proofs.
Choose JWT for interoperability with OID4VCI/OID4VP-style flows; AnonCreds for Hyperledger and ZKP-heavy use cases.
Wallet and Credentials
Platform
Credential storage by holder DID: issuers POST credentials to SETHU wallet; holders list and disclose by claims request. Supports both JWT (e.g. SD-JWT) and AnonCreds.
POST /v1/sethu/wallet/credentials to store; GET to list; POST .../disclose for selective disclosure. Integrates with TokCredAI agent runtime and AI flows.
Platforms may offer claim flows: when an issuer does not have a holder's DID, they create a claim link; holder opens link, signs in, accepts; issuer receives holder DID (callback or poll) and then issues via SETHU wallet.
Encryption and fingerprinting for evidence.
Credential issuance and claim flows
Integration
Issuers with a holder's DID can store credentials directly via POST /v1/sethu/wallet/credentials.
When the issuer does not have the holder's DID, integrating platforms can offer claim flows: create a claim (claimId and claimUrl), send the link to the holder; holder signs in to the platform, accepts; issuer gets holderDid via callback or GET claim endpoint, then issues the credential to that DID via SETHU wallet.
Claim creation and accept APIs are platform-specific; SETHU provides the wallet store so issued credentials land in the holder's wallet.
API Reference (Live)
Generated from live SETHU API metadata endpoint.
Unable to load live API reference.
Try Endpoint
Investor Appendix PDFs
Download-ready appendices for investor and diligence packs.