Trust is personal, cryptographic,
and contextual.

Why you would bother

Most systems pretend trust is a number. It is not.

Universal reputation scores, centralized certificate authorities, and "just email us to reset your key" are the compromises you live with when a system refuses to model trust honestly. Every one of them becomes the failure that puts the platform on the front page.

How trust works

Every trust statement has a subject, an object, a level, and a scope.

Instead of "Bob has a reputation", Quidnug captures "Alice trusts Bob at 0.9 for home contracting, signed on 2026-03-14". That statement is a cryptographic edge. Many such edges form a trust graph, and the protocol answers questions by walking it from the observer's perspective only.

How domains scope trust

Trust always carries its context on the label.

A trust edge is not valid "in general". It is valid in a specific domain, named with DNS-like dot-notation. A doctor attested by a state medical board is not automatically trusted to sign smart-contract oracle readings. An oracle trusted for ETH/USD is not automatically trusted to issue college diplomas. Cross-domain capture attacks simply do not compose.

How consensus works

Different nodes can see different chains. This is a feature.

Quidnug does not produce one globally-agreed chain. It produces per-observer chains tied to each node's trust graph. Proof-of-Trust tiers every incoming block into one of four buckets based on how much the observer trusts the validator who signed it. If you trust a validator, you build on their blocks. If you don't, you don't. Nobody votes about it.

How keys live and die

Losing a key shouldn't lose the business.

Real systems deal with lost laptops, stolen phones, forgotten passphrases, departing employees, and compromised signing services. Central escrow (the "email us to reset" approach) turns every recovery into a phishing vector and every customer support agent into a potential single point of failure. Quidnug replaces that with a cryptographic protocol: M guardians you chose in advance, a time-lock, and a veto window.

Transaction lifecycle

Every state change is signed, nonced, gossiped, tiered, anchored.

Applications don't mutate state by PUT-ing JSON at a REST endpoint. They build a typed transaction, sign it with their current epoch key, submit it, and watch it land. The node verifies the signature, checks the nonce ledger for replay, anchors it into a block, and gossips the block to peers. Each peer then tiers the block on its own terms.

qrp-0001 · first app-level protocol

A real system on top: trust-weighted reviews.

QRP-0001 is the first Quidnug Review Proposal: a domain-level protocol for reviews, comments, helpfulness voting, flagging, and verified purchases, built entirely from the primitives above. Drop-in widgets for React, Vue, Astro, plain HTML, Shopify, and WordPress ship today.

30-second demo

Stand up a node. Create two identities. Declare trust. Query it.

One binary, one HTTP API, one canonical-bytes signing format shared across every SDK. A signature produced in Python verifies byte-for-byte in Go, Rust, JavaScript, or on the reference node.

# 1. Create Alice's identity
curl -X POST http://localhost:8080/api/identities \
  -d '{"quidId":"alice","name":"Alice","creator":"alice"}'

# 2. Alice trusts Bob at 0.9 for "contractors.home"
curl -X POST http://localhost:8080/api/trust \
  -d '{"truster":"alice","trustee":"bob","trustLevel":0.9,
       "domain":"contractors.home"}'

# 3. Query trust from Alice's perspective
curl "http://localhost:8080/api/trust/alice/bob?domain=contractors.home"
# {"trustLevel":0.9,"trustPath":["alice","bob"],...}

from quidnug import Client, Quid

client = Client("http://localhost:8080")
alice  = Quid.generate("alice")
bob    = Quid.generate("bob")

client.register_identity(alice)
client.register_identity(bob)

client.grant_trust(alice, trustee=bob,
                   trust_level=0.9,
                   domain="contractors.home")

r = client.query_trust(observer="alice",
                       target="bob",
                       domain="contractors.home")
print(r.trust_level)      # 0.9
print(r.trust_path)       # ["alice", "bob"]

package main

import (
  "context"
  "github.com/quidnug/quidnug/pkg/client"
)

func main() {
  c := client.New("http://localhost:8080")
  ctx := context.Background()

  alice, _ := client.NewQuid("alice")
  bob,   _ := client.NewQuid("bob")
  c.RegisterIdentity(ctx, alice)
  c.RegisterIdentity(ctx, bob)

  c.GrantTrust(ctx, alice, bob, 0.9, "contractors.home")
  r, _ := c.QueryTrust(ctx, "alice", "bob", "contractors.home")
  _ = r
}

import { Client, Quid } from '@quidnug/client';

const client = new Client('http://localhost:8080');
const alice  = await Quid.generate('alice');
const bob    = await Quid.generate('bob');

await client.registerIdentity(alice);
await client.registerIdentity(bob);

await client.grantTrust(alice, {
  trustee: bob,
  trustLevel: 0.9,
  domain: 'contractors.home',
});

const r = await client.queryTrust({
  observer: 'alice', target: 'bob',
  domain: 'contractors.home',
});
console.log(r.trustLevel, r.trustPath);

use quidnug::{Client, Quid};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
  let client = Client::new("http://localhost:8080");
  let alice  = Quid::generate("alice")?;
  let bob    = Quid::generate("bob")?;

  client.register_identity(&alice).await?;
  client.register_identity(&bob).await?;

  client.grant_trust(&alice, &bob, 0.9,
                     "contractors.home").await?;

  let r = client.query_trust("alice", "bob",
                             "contractors.home").await?;
  println!("{} {:?}", r.trust_level, r.trust_path);
  Ok(())
}

the service

Validation-as-a-service, built on the protocol above.

Running your own Quidnug node is free and fully supported. But if you want a third-party-signed attestation that your domain really belongs to you, continuously re-verified, visible to any Quidnug-speaking system, that is what we sell. Same shape as Let's Encrypt, for Quidnug domain identities.

pricing

Priced by validation depth, not seats.

Start free on one domain with email verification. Upgrade to Pro when you need DNS ownership and a predictable recheck cadence. Upgrade to Business when your customers want a legal-entity-attested badge. Upgrade to Governance Partner when you want to co-operate the public network.

DNS providers

Works with every DNS provider. Cloudflare, Route 53, and Google Cloud DNS ship day one.

One-click TXT record creation for the three big cloud DNS providers, scoped tokens that cannot touch your other records, and a manual-paste fallback that works with any registrar. Consumer registrars (Namecheap, GoDaddy, Porkbun) roll in over the first quarter.

Where it fits

17 detailed use cases across five industries.

Each use case is a full implementation plan: problem statement, architecture with sequence diagrams, concrete SDK code, and a threat model. Pick your domain, read the design, clone the examples.

Client libraries

Three layers. One byte-identical wire format.

Protocol SDKs at the base bind the full wire format in every major language. Reviews widgets sit on top, wrapping QRP-0001 as drop-in UI. Platform plugins wrap the widgets for Shopify and WordPress so non-engineers install from an app store. Signatures verify interchangeably across the whole stack.

where this sits

Honest comparisons to every adjacent protocol.

Quidnug isn't positioned against public chains, DID + VC, Sigstore, PGP web-of-trust, or OAuth/OIDC. Each solves a different problem well. The comparisons below spell out exactly where each neighbor wins and where the "who trusts whom from my perspective" question makes Quidnug the right answer.

The public network

A small cooperative network you can peer with, or ignore.

We operate three seed nodes under quidnug.com. Any operator can bring up their own node and propose bilateral trust with the seeds: we'll tier your blocks, if you tier ours. The protocol enforces the rest.

Under the hood

One Go node, six subsystems, twenty-five design proposals.

The reference node is a single static Go binary. Six cooperating subsystems handle trust path discovery, nonce enforcement, guardian state, block tiering, gossip, and bootstrapping. Every protocol feature ships as a numbered Quidnug Design Proposal with rationale, compatibility analysis, and migration plan.

Honest sizing

Quidnug is a sharp tool. Reach for it carefully.