← Home Solana · SPL Memo · devnet

How Solana Attestation Works

Tamper-proof compliance records: we hash every scan and write it to the Solana ledger so anyone can verify the result without trusting VERA.

Why use a blockchain?

When VERA reports “this project has 2 high-severity flags,” a lender needs to trust that the result wasn’t changed after the fact and that it matches the actual document. A hash stored only in our database is only as trustworthy as we are.

By writing the hash to a public blockchain (Solana), we create a record that is permanent, timestamped, and verifiable by anyone—without trusting our backend. A counterparty, regulator, or auditor can confirm that the on-chain hash matches the current scan output by recomputing the hash themselves from our API.

What gets written on-chain?

We don’t store the full scan (every flag and excerpt) on-chain. We store a cryptographic hash of it plus a short human-readable summary. The SPL Memo program has a 566-byte limit per transaction, so we keep the memo compact.

On-chain memo looks like this:

{"v":1,"pid":"project-id","ts":"2026-02-22T12:00:00Z","flags":{"high":2,"medium":1,"info":3},"hash":"sha256:a3f7c2e1..."}

The hash is SHA-256 of the full attestation payload: project ID, timestamp, flag counts, and the SHA-256 of each scanned document’s text. That full payload never goes on-chain—only its hash does. If anyone changes the flags in our database later, the recomputed hash won’t match, and verification fails.

Attest flow (when you click “Attest on Solana”)

1 We load the project’s current flags and document text hashes from the database.

2 We build the payload (project ID, timestamp, flag summary, doc hashes), JSON-serialize it with sorted keys, and compute SHA-256.

3 We build the memo (hash + short summary). If it’s over 566 bytes we trim to summary + hash only.

4 We create a single SPL Memo instruction with the memo as data and send it in a transaction to Solana devnet.

5 We store the transaction signature, slot, and timestamp on the project record and show you the Solana Explorer link.

We use the SPL Memo program (MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr)—a standard program on all Solana clusters. No custom smart contract, no deployment. One instruction, and the data is on the ledger forever.

Verify flow (when you click “Verify”)

Verification proves that the on-chain record matches the current scan:

We fetch the transaction from Solana using the stored signature.
We decode the memo from the transaction’s instruction data (base58 or UTF-8).
We recompute the expected hash from the current flags and doc hashes (same algorithm as attest).
We compare: if on_chain_hash === recomputed_hash, verification succeeds.

Trustless verification: A third party can do this without calling our API for “verify.” They can fetch the transaction from any Solana Explorer, decode the memo, call our flags API to get the current flag detail, recompute the hash themselves, and confirm it matches the on-chain value. No trust in VERA required.

Why devnet (and not mainnet)?

For the hackathon we use Solana devnet: SOL is free from the faucet, confirmation is fast, and the same code works on mainnet. To go to production we’d switch the RPC URL and keypair to mainnet; the attestation logic doesn’t change.

Key files to look at

backend/solana/attest.py — Payload build, SPL Memo tx, verify_attestation
backend/config.py — SOLANA_RPC_URL, SOLANA_KEYPAIR_PATH
backend/api/routes.py — POST /attest, GET /verify (and flag/doc hash loading)

In one sentence

We hash the full compliance scan (flags + document hashes), write that hash and a short summary to the SPL Memo program on Solana, and anyone can verify the result by recomputing the hash from our API and comparing it to the on-chain memo—no trust in our backend required.