dSSL Manager — Cosmos-wide Verification Layer

What dSSL Manager does

dSSL Manager is a Cosmos-native trust & verification layer. It lets any project publish an identity document (cosmos.toml), then prove that they control the subject (domain, repo, app, chain address, contract, etc). Verified records can be attested by third parties and evaluated via namespace policies to produce an on-chain trust level.

Big idea: a single standard that wallets, explorers, browsers, registries, launchpads, and security tools can all read. One verification primitive, many consumers.

Core primitives

Subject: what is being verified Namespace: policy domain (e.g., “cosmos”, “atomos”, “github”) Record: on-chain pointer to cosmos.toml + hash OwnershipProof: adapter / signature / attestor Attestation: third-party score signal LevelRules: translate scores → trust tier

Minimum workflow

The shortest path from “nothing” → “verifiable identity”:

Host cosmos.toml at /.well-known/cosmos.toml (and/or /cosmos.toml).
Compute hash (ex: sha256:<hex>).
Submit an on-chain record: subject + uri + hash.
Prove ownership via: Adapter (on-chain registry), Signature (owner signs the hash), or Attestor (approved attestors confirm owner).
Optional: collect attestations; resolve trust level per namespace policy.

Deployment notes

This site is content-first and intentionally avoids fragile JS stacks. If you later want live chain reads, you add a small REST query layer and render results.

dSSL Contract

set on deploy

Chain ID

set on deploy

REST

set on deploy

Trust tiers (example)

Policies map a score → level. Names are arbitrary per namespace.

Spark 0+ Beacon 2500+ Crest 5000+ Citadel 8500+

Tip: make tiers ecosystem-branded (“Verified”, “Audited”, “Battle-tested”), but keep the math deterministic.

How verification works (end-to-end)

dSSL is built around a simple invariant: the chain stores an immutable pointer to a claimed identity document (URI + hash), then enforces one of several ownership proofs to bind that record to a controller.

Step 1 — Publish cosmos.toml

cosmos.toml is your project’s canonical identity + security metadata document. It can include keys, endpoints, contract addresses, repos, contacts, audits, and policy links.

Recommended locations: /.well-known/cosmos.toml then /cosmos.toml.

Step 2 — Create/Update a Record on-chain

A record binds a Subject to cosmos.toml URI + hash. Consumers can fetch the file and verify the hash matches the chain record.

Record = { subject, namespace, cosmos_toml_uri, cosmos_toml_hash, timestamps, expiry }

Step 3 — Ownership proof (choose one)

Your contract supports multiple ownership proofs so the same system can work for domains, repos, contracts, and non-domain subjects.

Adapter: query a configured on-chain registry for owner Signature: owner signs the cosmos.toml hash Attestor: approved attestors confirm ownership

Step 4 — Attestations + policy → trust level

Attestations add score signals. Policies define how score translates into levels. Consumers can show a badge (“Citadel”) and also the underlying evidence.

cosmos.toml schema (recommended)

Your contract is chain-agnostic and stores URI + hash. The schema is where you standardize what the file means. This is a practical schema designed for verifiers, browsers, explorers, and security tooling.

Sample cosmos.toml

# cosmos.toml — dSSL identity document (example) [dssl] schema_version = "1.0.0" namespace = "cosmos" subject = "domain:example.com" # or "repo:github.com/org/repo" / "contract:cosmos1..." / "address:cosmos1..." display_name = "Example Protocol" description = "Cross-chain liquidity protocol on Cosmos." website = "https://example.com" updated_at = "2026-02-08T00:00:00Z" [dssl.ownership] # One or more proof methods supported by the project. # Verifier preference order should match your on-chain configuration: # adapter -> signature -> attestor methods = ["signature"] [dssl.keys] # Public keys used for verification / signing statements (base64 or bech32, declare encoding explicitly) # (These keys can correspond to the signature proof the owner submits on-chain.) operator_pubkey_b64 = "BASE64_PUBKEY_HERE" security_contact = "security@example.com" [dssl.endpoints] rpc = "https://rpc.example.com" rest = "https://rest.example.com" grcp = "https://grpc.example.com" [dssl.contracts] # On-chain contracts that belong to the project mainnet_router = "cosmos1..." staking = "cosmos1..." [dssl.repos] github = ["https://github.com/example/protocol", "https://github.com/example/audits"] [dssl.security] bug_bounty = "https://immunefi.com/bounty/example" audits = [ { firm="Halborn", date="2025-11-01", report="https://example.com/audits/halborn.pdf" }, { firm="Informal Systems", date="2026-01-10", report="https://example.com/audits/informal.pdf" } ] [dssl.attestation_policy] # Optional hints for attestors (does not override chain policy) preferred_attestors = ["cosmos1attestor...", "cosmos1attestor2..."] notes = "Attest the router + governance module; include report links."

Hashing rule (verifier)

Canonical approach: fetch bytes of the file → SHA-256 → represent as sha256:<hex>. That string is what gets signed (signature proof) and stored on-chain.

Where it should live

For a universal verifier tool, keep it predictable:

1) https://HOST/.well-known/cosmos.toml 2) https://HOST/cosmos.toml 3) If chain record includes cosmos_toml_uri: use that exact URI

Why this matters

If every project follows the same resolution order, wallets and browsers can show “Verified” badges without bespoke integrations for each project.

Smart contract API (dSSL Manager)

The dSSL Manager contract you uploaded is built around: Subjects, Namespaces, Records, Ownership Proofs, Attestors, and Policies. Below is an accurate “developer-facing map” of the main message surface.

Execute messages (high-level)

Admin / Governance - UpdateConfig - SetNamespacePolicy - AddAttestor / RemoveAttestor Record lifecycle - UpsertRecord - ClearRecord - RenewRecord - RevokeRecord / UnrevokeRecord Attestations - Attest - RevokeAttestation - ClaimOwnership (prove control via adapter/signature/attestor)

Query messages (high-level)

Core - GetConfig - GetRecord - ListRecords - Verify (resolve status / trust level) Policies & Attestors - GetNamespacePolicy - IsAttestor - GetAttestations - GetRevocations

Ownership proofs supported

Your contract supports three ownership proof paths:

OwnershipProof 1) Adapter → on-chain ownership adapter for that namespace 2) Signature → sender signs the ASCII bytes of cosmos_toml_hash (e.g. "sha256:abcd...") 3) Attestor → approved attestors assert claimed_owner == sender

Implementation note: keep signature verification strictly typed (pubkey encoding, signature scheme, domain separation string).

Examples (what dSSL enables)

1) “Verified Project” badge in wallets + explorers

A wallet sees a token, checks its issuer contract, calls dSSL Verify, and displays a badge: “Citadel Verified” + evidence links (audit reports, keys, repo).

2) Domain → security profile + IPFS publishing

A domain hosts cosmos.toml. The chain stores the hash and validates ownership. Browser integration reads the file and shows a trust panel before loading the site.

3) Repo verification (GitHub / GitLab)

A repo commits cosmos.toml. The chain record points to raw content URL or IPFS. Ownership is proven via signature from the project key, plus attestations by auditors.

Simple trust scoring model (illustrative)

score = base_score + Σ(attestor_boost) level = policy.resolve(score) Example: base_score = 4000 two attestations: +1200 +800 total = 6000 → "Crest"

Integrations

Build once, reuse everywhere. A few “first-class” integration targets:

Browser integration (dSSL-aware browsing)

Before loading a site, browser fetches cosmos.toml, verifies hash against chain record, then shows: owner proof type, attestations, resolved tier, and warnings (revoked / expired).

CLI verifier tool

dssl verify https://example.com - fetch /.well-known/cosmos.toml - sha256 bytes → "sha256:..." - query chain: GetRecord(subject) - compare hash - query Verify(subject) - print tier + evidence

Explorer & wallet badges

Treat dSSL as a “security metadata oracle”: explorers show verified issuer + audits; wallets show warning banners on revoked subjects.

Roadmap (pragmatic)

v1: schema + verifier + badges v1.1: standard policy packs per namespace v1.2: attestor registry + reputation v2: cross-chain proofs & federation claims

What we build next on dssl.one

Once you want this site to become “the platform”, the next step is a read-only chain indexer to display:

Search bar (subject → record + verification status)
Namespace pages (policies, attestors, leaderboards)
Attestor profiles (history, signed reports, boosts)
Revocation registry (alerts feed)

FAQ

Does dSSL require domains?

No. The contract is built to support general “subjects” (domain, repo, contract, address, etc). Domains are just one namespace consumer.

How do we prevent fake claims?

You prevent claims via ownership proofs: adapter-based ownership, signature proofs over the chain-stored hash, or attestor-backed ownership with approved attestors.

What’s the best default file path?

/.well-known/cosmos.toml first, then /cosmos.toml. Verifiers should follow a fixed resolution order.