Dual-track cryptographic verification for the Proper SCF + STRM Data Model. Every claim is hashed, anchored on Base, and timestamped on Bitcoin.
The Secure Framework Verification Token (SFVT) is an ERC-20 token on Base that anchors and proves the integrity of the Proper SCF + STRM Data Model through two completely independent cryptographic verification tracks. Token amounts sent to named wallets represent verified counts — the blockchain IS the audit trail.
When both roots match the claims in the Verification Package, and those roots are permanently anchored on-chain, the data becomes extremely difficult to dispute.
These are the ideals we built this tool on. Every number is computed, verified, and permanently anchored to a public blockchain. The pipeline checks the data. An independent audit checks the pipeline. The blockchain checks the audit. Three layers deep, each one watching the one before it. There are no estimates, no approximations, no assumptions carried forward on good faith. If it cannot be proven, it is not claimed. If it cannot be reproduced, it is not published. Every hash, every count, every verification checkpoint exists because the alternative was trusting someone's word — and we chose math instead.
Everything below is read from the receipt JSON. Nothing is hardcoded. If a hash is wrong, it says so.
Loading receipt data...
In addition to the SFVT token on Base, every critical artifact is independently timestamped on the Bitcoin blockchain via OpenTimestamps. This creates a second, completely independent proof that these files existed in this exact state at the time of stamping. Bitcoin is the most secure, longest-running blockchain in existence — these timestamps will be verifiable for as long as Bitcoin exists.
12 artifacts stamped via OpenTimestamps (4 calendar servers each). Pending Bitcoin block confirmation. Verify locally: ots verify <file>.ots
Every verified number is a leaf in a binary Merkle tree. Each leaf is hashed (SHA-256). Pairs of hashes are combined and hashed again, building up to a single root hash that represents ALL the data. Changing any single number changes the root — and the root is what's anchored on-chain. Click any node to see details.
Every number below is a named Merkle leaf. Changing any single value changes the root hash, which is permanently anchored on-chain. Click any shield to verify on BaseScan.
leaf #3 — framework_relationships/*.csv count
leaf #24 — strm_extracted/*.csv count
leaf #23 — sum of rows across all STRM CSVs
leaf #22 — total unique Focal Document Elements| What | Count | Description | Leaf | |
|---|---|---|---|---|
| SCF Controls | -- | Security controls in the SCF catalog | core_table.SCF |
| Assessment Objectives | -- | Control assessment objectives | core_table.Assessment_Objectives |
| Compensating Controls | -- | Compensating control entries | core_table.Compensating_Controls |
| Evidence Requests | -- | Evidence items for compliance | core_table.Evidence_Request_List |
| Privacy Principles | -- | Data privacy management principles | core_table.Data_Privacy_Mgmt_Principles |
| Authoritative Sources | -- | Regulatory/standard source references | core_table.Authoritative_Sources |
| Threat Categories | -- | Distinct threat categories | core_table.Threat_Catalog |
| Risk Categories | -- | Distinct risk categories | core_table.Risk_Catalog |
| Security Domains | -- | SCF security domains and principles | core_table.SCF_Domains_Principles |
| Type | Count | Leaf ID | |
|---|---|---|---|
| Intersects With | -- | strm_relationship_type.Intersects With |
| Subset Of | -- | strm_relationship_type.Subset Of |
| Equal | -- | strm_relationship_type.Equal |
| Superset Of | -- | strm_relationship_type.Superset Of |
| What | Count | Leaf | |
|---|---|---|---|
| Main Verification Chain Leaves | -- | main_leaves |
| Audit Chain Leaves | -- | audit_leaves |
b0f2bc4b1683171ab51ba0b3ec3c4f5823ea8eda6f6494b0389eff1e1c646d86
4adcf0b14caf559ced816a3f4f504d83d55b7c59681bfaa7d5dfd6fbdd723e1a
Each wallet below represents a verified category. The balance IS the count — 249 SFVT in the Frameworks wallet means 249 frameworks verified. Every number links directly to BaseScan.
The pipeline recomputes every metric from scratch and compares against expected_totals.json (which is itself SHA-256 hashed into the verification chain). If any single number differs, the pipeline refuses to produce output.
| Status | Check | Value | What it verifies |
|---|---|---|---|
| expected_totals.json integrity | cc3ca07e... | SHA-256 of the totals file matches what's sealed in the verification chain |
| source.source_mirror_file_count | 194 | Files in the SCF repository mirror |
| source.strm_pdfs_on_disk | 185 | STRM PDF source files present |
| pipeline.raw_csv_count | 10 | CSVs extracted from SCF workbook |
| pipeline.clean_csv_count | 10 | Cleaned/normalized CSVs produced |
| relationships.framework_relationship_count | 249 | Framework-to-control mapping files |
| relationships.scf_relationship_count | 4 | SCF entity junction table files |
| relationships.framework_relationship_total_rows | 67,119 | Total rows across all 249 framework CSVs |
| strm.extracted_csv_count | 185 | STRM CSVs extracted from PDFs |
| strm.total_mapping_rows | 58,779 | Total data rows across all STRM CSVs |
| provenance.artifact_count | 194 | Provenance JSON artifacts generated |
| core_tables (all 10 tables) | 10/10 | Record count of every table matches (1,468 controls, 5,776 objectives, 303 evidence, 258 privacy, 253 sources, 41 threats, 39 risks, 33 domains) |
| strm.relationship_types (6 values) | 6/6 | Every STRM Relationship type count matches (5 canonical + unclassified) |
| strm.rationale_types (226 values) | 226/226 | Every STRM Rationale value count matches |
| strm.strength_values (14 values) | 14/14 | Every Strength of Relationship value matches |
| strm.per_pdf (185 PDFs) | 185/185 | Row count of every individual STRM CSV matches |
python3 -c "from verify_chain import validate_results; validate_results(...)" to re-verify independentlyEach verified number has its own Base ENS wallet. The wallet's SFVT balance IS the verified count. Green shield = balance matches or exceeds expected. Red shield = balance is zero or missing. All data read live from the blockchain.
| Wallet (base.eth) | Verifies | Expected | On-Chain |
|---|