Public issuer profile · anyone can read this
DCS Labs
did:web:dcslabs.ai
Why this score
Fully auditable. This score is reproducible from the public inputs above — issuer age, verification count, revocation rate, audit status, federation reputation. No hidden weighting. Recompute it yourself from the open formula.
Supported credential types
These are the credential types this issuer is provisioned to sign — a capability list, not a count.
FAQ
Frequently asked questions
Receipts, chains, IDs, and how independent verification works.
What is a DCS receipt?
A receipt is a cryptographic record of one AI action — what happened, when, which system did it, and a fingerprint of the result. Unlike a log, it's signed and content-addressed, so anyone can verify it later without trusting us.
Session ID vs Receipt CID vs hash — what's the difference?
A Session ID (a UUID) identifies one build, which contains many receipts. A Receipt CID (bafk…) is the IPFS address of a single receipt. A sha256:… value is a content fingerprint. Rule of thumb: paste a Session ID to verify a whole build, a CID to verify one receipt.
How many receipts does a build create?
One per recorded action (run), plus a few lifecycle receipts (build_complete, memory_write). So 10 runs ≈ 11–12 in chain, and 50 runs ≈ 52–53 in chain. The count tracks actions, not agents — one agent can take several actions.
What does “N in chain” mean?
The number of receipts linked together for that build. Each receipt carries the hash of the one before it (prev_receipt_cid), forming a tamper-evident chain — change any receipt and every later link breaks.
Do I need an account to verify?
No. The Verify, Explorer, and Registry pages are fully public. Anyone can paste an ID and re-check the result — that's the whole point: trust you can't inspect isn't trust.
What does “anchored on Base” mean?
The chain's Merkle root is written to Base mainnet (an Ethereum L2) in a single transaction. That timestamps the receipts on a public blockchain and proves they existed at that moment and haven't changed since.
Can I verify a receipt without DCS at all?
Yes. Fetch the JSON from IPFS (gateway.lighthouse.storage/ipfs/<cid>), recompute its SHA-256 to confirm it matches the CID, and check the Ed25519 signature against the issuer's published key. The reference verifier is open — our servers are a convenience, not a dependency.
What happens if someone edits a receipt?
Its content hash changes, so it no longer matches its CID, and the chain link from the next receipt breaks. Verification fails immediately and visibly. Tampering can't be hidden.
Where do I find my Session ID or CID?
In your dashboard's transaction history (the Project / build column links each build), on the build's certificate PDF, or in the Explorer network feed. Any “View on IPFS” link is a CID.
Why does something say “temporarily unavailable”?
The issuer registry/credential API may be redeploying. Receipt verification by CID still works independently, because it's content-addressed and checked in your browser. Issuer trust scores return once that service is back.
Is my private content exposed in a receipt?
No. A receipt holds action metadata — kind, timestamp, hashes, cost, energy — not the underlying private data. It carries only what's needed to prove the action happened, nothing more.
Which standards does this use?
The open R-Series: R+2 signed receipts (Ed25519 + RFC 8785 JCS canonicalization + SHA-256), R+3 post-quantum hybrid co-signatures, and R+4 zero-knowledge proofs. See the R-Series standard on dcslabs.ai.
