Skip to content

verifyChain

const chain = await fidemark.verifyChain(uid);
// [root, ..., leaf], oldest-first

Each attestation has a refUID field: the UID of a parent attestation it references. verifyChain follows that chain:

  1. Fetches the attestation at uid.
  2. If refUID is not the zero hash, fetches the parent.
  3. Repeats up to depth 32 (cycle-safe).
  4. Returns the chain root -> … -> leaf.

The walker exits early (keeping whatever it’s gathered) when:

  • The next link’s UID isn’t found.
  • The next link’s schema isn’t a Fidemark schema (the chain has “exited” Fidemark and references a foreign EAS attestation; refUID is still readable but not decoded).
  • A cycle is detected.

A common composition:

  1. Human authors an article -> attest Human Proof for original -> UID H1.
  2. AI translates it -> attest AI Proof for translated with refUID = H1 -> UID A1.
  3. A reviewer signs off -> attest Human Proof for review with refUID = A1 -> UID H2.

Then walking the chain from H2 returns [H1, A1, H2]: the full provenance trail in one query.

For more chain shapes (AI output endorsed by a verified human, multi-party endorsement, off-chain promotion, …) see Guides -> Workflow examples.

Complete, copy-pasteable runnable. Pass refUID to the human or AI attest call. See Configuration for every constructor option.

import { Fidemark, getNetwork } from "@fidemark/sdk";
const fidemark = new Fidemark({
network: getNetwork("base-sepolia"),
privateKey: process.env.PRIVATE_KEY,
});
const child = await fidemark.attestHuman({
content: review,
contentType: "text/review",
refUID: parentUID,
});

The SDK passes refUID through to EAS’s native refUID field. EAS doesn’t enforce that the parent exists: verification consumers should call the chain walker to confirm the chain is well-formed.