How transparency chains work

Self-attested is a tamper-evident log endpoint. Companies (or their AI agents) POST events they choose to log; we hash each one into a per-workspace Merkle chain, anchor the head every 30 minutes to GitHub (signed commits) and OpenTimestamps (Bitcoin), and serve a public verifier the relying party runs in their own browser. The honest property: every event the customer logged is cryptographically provably unchanged and publicly verifiable; we make no claim about events they chose not to log. No traditional log service ships that — Datadog, Logtail, CloudWatch, and Loki all let the operator (or any admin with retention permissions) mutate the backend without leaving evidence. Self-attested chains live at /v/[wsSlug].

Structuralis a transparency proxy in front of the customer's database. Every access — human, agent, script, migration — flows through it before reaching storage. Logging is architectural; the only way to skip it is to skip the database. Different threat model (the admin is the adversary), different audience (regulated-vertical CTOs), different sales motion. Same chain format and verifier. Structural chains live at /v/[wsSlug]/[depId] and /v/[wsSlug]/[depId]/u/[userId].

The agent is a separate actor from the company shipping it, and the company wantsthe agent's actions cryptographically proven so customers and regulators can verify them. Self-attested is exactly the right shape — the agent doesn't need a transparency proxy in front of itself, it just needs an append-only verifiable log endpoint. The MCP server (@uninc/mcp) wires this. The “what if the agent doesn't log?” concern is weaker for this audience because the agent isn't trying to be adversarial — it's an honest cooperator the company wants visibly accountable. If the threat model is instead “the admin is the adversary,” structural is the right answer.

Every page has a Verify my chain button. Clicking it loads a WebAssembly verifier into your browser, fetches the full entry list, and recomputes every hash locally. If a single byte has been changed, the recomputed head hash won't match the declared one and verification fails with a specific reason.

This means the server can't fake a passing result. The browser is the source of truth; we're just shipping the data and the code to check it.

Each chain's head hash is periodically committed to public external systems — a signed GitHub commit in un-incorporated/transparency-anchors, a tweet from @uninc_app, and an OpenTimestamps proof anchored to the Bitcoin blockchain. The anchors are what prevent retroactive chain rewrites: to fake a past state, a company would have to forge the anchor in the external system, and those systems don't accept forgeries.

A single admin login typically runs 5-50 queries back-to-back. Rendering each as a separate row would bury the signal. Under /v/ we collapse consecutive entries that share a session_id and actor into one expandable card: “admin@co ran 7 queries over 4 minutes.” Click the card to expand.

The deployment chain surfaces more than database access. Events are tagged with a category that determines how they render:

• admin_access — aggregated summary of an admin session
• deploy — new proxy or app container image rollout
• schema — DDL (ALTER / CREATE / DROP) with migration name
• egress — outbound connection attempt (allowed / denied)
• admin_lifecycle — admin role grants, revokes, permission changes
• nightly_verification — BFT cross-replica chain check (randomly sampled via drand)
• verification_failure — divergence detected; alert-styled
• replica_reshuffle — drand-seeded replica role reassignment

All four levels are currently public. Privacy toggles at the deployment level are on the roadmap — see V-PRIVACY-OPTIONS.md in the source tree.