ClavigerOpen the app

Roadmap

First, make control visible. Then make changes visible. Each stage has a concrete outcome and a release condition. Research stays separate from available tools.

  1. Phase 0

    See the keys

    Live

    Understand the control paths we can read today, without connecting a wallet.

    • The Scanner

      Identify an address and inspect its public balances and control information.

      Live
    • Control pages

      Follow decoded program and token authorities to their keys. Unresolved paths stay visible.

      Live
    • Team readiness report

      Combine up to 25 addresses into a key inventory, checklist and downloadable report.

      Live
    • Protocol table

      Browse a curated list of programs, their upgrade controls and the time of each read.

      Live
    • Quantum Birth Certificates

      Optional, numbered public pledges on devnet. A record does not change a wallet’s signing rules.

      Live
    • The Story

      A visual explanation of control keys and the questions Claviger helps you ask.

      Building

    Release condition: These tools run in this build. Public launch still needs an operator, contact details, reviewed policies and an independent review. The Register is on devnet.

  2. Phase 1

    Make it verifiable

    Building

    Let a team trace every conclusion back to the accounts and decoder that produced it.

    • Report evidence

      Expand a report address to inspect source accounts, observation times, data hashes, decoder version and unresolved paths.

      Live
    • More control paths

      Prioritise governance and multisig formats encountered in unresolved reports, followed by token extensions.

      Planned
    • Portable snapshots

      Download the exact report as JSON or Markdown. JSON snapshots carry a schema and checksum and can be restored in the browser.

      Live
    • Coverage you can inspect

      Publish supported account types and a reproducible fixture corpus alongside the tools.

      Planned

    Release condition: Each new decoder needs captured account fixtures, malformed-input checks and a documented coverage boundary. Exports must identify their cluster, read times and decoder version.

  3. Phase 2

    Follow the changes

    Building

    Turn a useful one-off report into a repeatable control review for a team.

    • Local baselines

      Name and keep up to 20 report snapshots in this browser. Export a backup, restore it or remove a saved copy.

      Live
    • Manual comparisons

      Compare supported controls against a saved baseline. Missing evidence, older reads and incompatible decoders stay separate from changes.

      Live
    • Project workspaces

      Keep named projects, labelled addresses and local review history together. Back up or restore a complete project without overwriting another.

      Live
    • Continuous change history

      Explore scheduled observations and a shared review history after testing the manual workflow with teams.

      Planned
    • Opt-in notifications

      Notify a team when a supported control path changes, and separately when monitoring cannot read it.

      Planned
    • Read-only API

      Expose versioned facts, coverage and freshness so other tools can show the same evidence.

      Planned

    Release condition: A failed or stale read must never trigger a control-change alert. Validate before-and-after evidence and duplicate suppression in a small opt-in pilot before wider release.

  4. Phase 3

    Migration research

    Research

    Explore how a verified key inventory could support future signing-system changes.

    • Organisation records

      Study how a multisig or DAO could make a verifiable public pledge as itself.

      Early idea. Would need independent security review, and legal review where relevant, before any build.

      Research
    • Guided rotation

      Explore a reviewable migration plan if the chain and wallets support the required signing schemes.

      Early idea. Would need independent security review, and legal review where relevant, before any build.

      Research
    • Cross-chain inventories

      Assess whether the same evidence model can explain control on other chains without hiding their differences.

      Early idea. Would need independent security review, and legal review where relevant, before any build.

      Research

    Release condition: Any transaction-building tool depends on supported chain capabilities, a defined threat model and independent review. No migration, custody or automated rotation product is committed.

This is where we are aiming, not a promise. Items move, merge or get cut as we learn.