Site Integrity Heartbeat

Every day, a non‑human agent checks the current content address (CID) of amykellam.com via its DNSLink and publishes a signed, timestamped attestation of that CID. The log is stored as a JSON file in a public GitHub repository and served via GitHub's raw CDN. Anyone can verify the cryptographic signatures using the agent’s public Ethereum address.


How It Works

  1. 1. Resolve the site’s DNSLink – The agent fetches the current CID of amykellam.com via DNS TXT record.
  2. 2. Create a signed statement – “Agent loading… witnessed CID at a specific time.”
  3. 3. Append to log – The attestation is added to the log array, keeping the last 365 entries.
  4. 4. Commit to GitHub – The workflow commits the updated `log.json` to the repository's main branch.
  5. 5. This page fetches the raw file – The log is displayed below.

Why This Matters Beyond This Site

The heartbeat agent is a minimal, working prototype of a larger idea: a non‑human, unowned steward that can vouch for any content‑addressed resource. Because the agent can have its own on‑chain identity and reputation, its attestations carry weight (because the agent has a public, verifiable track record of honest behaviour). The same simple architecture can be applied across a wide range of use cases, such as those outlined below.

Scholarly publishing & institutional repositories

Pre‑prints and published articles are stored on university servers or commercial platforms. The link between a specific version and its publication date relies on platform metadata, which can change without notice. An institutional heartbeat agent resolves the IPFS CID (or DOI‑to‑CID mapping) of every deposited paper daily, publishes signed attestations of each version’s integrity, and maintains a per‑paper attestation log. Multiple agents — one run by the journal, one by the library, one by an independent consortium — can watch each other, creating a web of mutual verification without any central platform.

Open source & supply chain integrity

A binary release should correspond to a specific source commit, but verifying this often requires manual hashing and trust in the release platform. A build‑witness agent watches a repository’s release page (or an IPNS‑published directory). For each release it downloads the binary and the source snapshot, reproduces the build in a deterministic environment (where possible), computes the content hash of both, and publishes a signed attestation: “Commit X produces binary Y when built with compiler Z”. Even a simpler variant — attesting only that a specific binary has a specific hash at a specific time — provides a tamper‑evident release history that developers and users can check independently.

Legal evidence & public notarisation

A person needs to prove that a document existed at a particular time and has not been altered. Centralised notary services involve fees, intermediaries, and jurisdictional lock‑in. A public‑notary agent accepts only the hash of a document (never the document itself) and signs an attestation: “Document with hash X was witnessed at time Y”. The document remains entirely private; the proof is public. Anyone can query whether a specific hash was attested by the agent at a specific moment — a decentralised, permissionless alternative to traditional notarisation.

Cultural heritage & community archives

Community‑maintained archives – for Indigenous knowledge, activist documentation, or oral histories – face two structural challenges: volunteer‑dependent infrastructure (servers, backups, metadata) and unsuitable legal frameworks (copyright assumes individual ownership and commercial exploitation, which misaligns with collective care). A stewardship agent monitors the IPNS record of the archive, checks whether the content is still available via a public gateway, and records any changes to the CID. Each day it publishes a signed attestation: “As of date T, the archive’s root CID is X; it has [not] changed since the last check.” These attestations are public, verifiable, and require no copyright claim, no access fee, and no platform account. The community retains full control.

DAO governance records

A DAO passes proposals through a combination of on-chain smart contracts (which handle voting logic, quorum, and execution) and off-chain platforms (such as Snapshot or Discourse) where proposal text, discussion, and signaling occur. While the core voting mechanism is sometimes recorded on-chain, the full context of the proposal – its text, attachments, and community feedback – often lives solely on these external platforms, which can fail, censor, or lose data. To mitigate this, a governance-witness agent captures this off-chain content as a content-addressed record, signs an attestation linking it to the on-chain proposal ID, and publishes the result to IPFS. The attestation is independently verifiable, permanently archived, and maintained by a neutral, non-human steward – preserving the governance record even if the original platform disappears. This transforms DAO governance into a cryptographically auditable archive that does not require trusting any single platform or entity.

The four-part architecture is identical in these examples: a content‑addressed resource, a non‑human attester with an on‑chain identity, a signed attestation published to IPFS, and a public, reputation‑building log.

Daily Heartbeat Log last 30 days

Date (UTC)Witnessed CIDAgent AddressSignature (prefix)
Loading log from GitHub…

The complete log is available at https://raw.githubusercontent.com/hotscotchbonnet/heartbeat-log/main/log.json.

Verify an Attestation Yourself

The agent’s public address is loading…. Click “Verify” next to any entry to check its signature in your browser.

← Back to the main Content Attestation page for a conceptual overview and off‑chain demo.


In this prototype, the agent has only an on‑chain identity (Ethereum address). A full reputation system — where agents post bonds, are challenged by peers, and lose stake for signing false claims — is achievable using this architecture. Without it, trust is still social/off‑chain, but the cryptographic log provides a tamper‑evident foundation upon which on‑chain reputation can later be built.