T R U S T · Trustless Registry of Universal Secure Tokens
Qodoonect Trust is the identity and signing layer of the Qodoonect group: an OpenID Connect sign-in provider, document envelopes with electronic signatures, encrypted data capsules, workspace identity passes with did:btc and did:key identifiers, and Merkle anchoring of document hashes in the Sigstore Rekor transparency log. Anchoring those batches to Bitcoin is planned, not active.
Each card is a part of the Trust API and the Trust platform. Where a service depends on an outside provider or on configuration, the card says so and the status card above shows today's state.
An OpenID Connect provider (authorization code, refresh tokens, RS256). The discovery document and signing keys are public at /.well-known/openid-configuration.
Apps connect to it as registered OpenID clients.
Send documents for signature through personal signer links, which can require a one-time code — one at a time, from templates, in bulk or on a schedule.
Signatures are simple electronic signatures today. Qualified seals and QES need an external qualified trust service provider.
Each workspace holds an Ordinal Pass — a free pass registered with a Bitcoin-signed message, or one linked to an existing inscription.
Identifiers follow did:btc (BIP-136 txref); agents get a did:key pass under a person's pass, with an audit trail.
Seal a document into a capsule protected with post-quantum algorithms (ML-KEM-768, ML-DSA-65), then list, extract or destroy it inside your workspace.
A capsule's hash can be anchored like any other record.
Hashes of documents and events are batched into one Merkle root, and the root is recorded in the Sigstore Rekor transparency log.
A batch can be checked later against that public entry. Anchoring batches to Bitcoin (OP_RETURN) is planned, not active. How it works ↓
Resolve decentralized identifiers — did:btc, did:key and other methods through the DIF Universal Resolver — and check signed challenges against them.
Read the EBSI trust registries: pilot network, read-only.
Trust's Bitcoin identifiers follow the public did:btc method. The keys that control an identity are separate from the keys that use it, so a compromised signing key can be rotated without losing the identity. The design document (draft) describes the method in full.
A Bitcoin UTXO controls the DID; its secp256k1 key authorises updates and rotation.
Verification keys live in the DID document and are used for sign-in, signing and capability proofs.
The method inscribes the DID document in Taproot witness data, where a byte weighs a quarter of a base-block byte. Trust's builder writes the creation commitment into an OP_RETURN output, which its resolver reads.
A resolver maps did:btc:<txref> to the current DID document.
A txref (BIP-136): block height and transaction position form the handle.
Verification keys from the DID document; standard signing and verification.
The confirming Bitcoin block fixes when the record existed.
Today: a free pass starts off-chain. A pass's DID key can be attached off-chain, or put on-chain by broadcasting the prepared transaction from your own wallet; the platform does not pay for it. Mainnet is used only when the server's network is set explicitly.
Instead of one public entry per document, Trust batches hashes and records only the Merkle root. These are the steps the Trust API runs; the record today is a Sigstore Rekor entry.
The Trust platform signs in with email and password or with a link sent by email.