Open specifications for blockchain-anchored verification on Bitcoin SV.
These protocols share a common cryptographic foundation: salted HKDF-SHA256 key derivation from identity to Bitcoin address. The algorithm is published and deterministic, so anyone holding the inputs can independently re-derive an address and verify proofs and contracts against the blockchain — no proprietary server logic, no trust in a database. Only math.
Important: key derivation mixes a per-user 256-bit random salt (the user's presentation key) with the identity input. Identity alone is not enough to derive the key — see BEVISET §4. Without the salt, derived keys would be reproducible by anyone who knows the (low-entropy) identity inputs; the salt is what makes derivation forgery-resistant. The snippet below is illustrative; the normative algorithm (including the salt) lives in the spec.
BEVISET.md — Digital Ownership Certificates
Register, verify, and transfer ownership proofs anchored as 1SatOrdinal inscriptions.
- HMAC-peppered identity hashing (rainbow table resistant)
- 1SatOrdinals: the proof IS a satoshi, transferable via UTXO chain
- Independent verification without any server
The proof is a satoshi. The owner holds the satoshi. The UTXO chain IS the ownership history.
HELTENIG-V2.md — Sealed Agreements (draft)
Multi-party agreement signing where the signing service issues a seal over the document, each party's signing act, a certificate per party (BRC-52) and its audit log, and anchors the seal's hash as a BRC-220 NotaryHash. Parties get the signed PDF and a proof bundle that verifies without the service.
- Parties are keys, not e-mail addresses: no key or identifier is ever derived from personal data
- Three signature suites, and the verifier must say which one was used: the party's own BRC-100 wallet key, a passkey (WebAuthn), or an attestation by the service
- Identity strength is a certificate type (e-mail control, BankID, ...), not a change to the seal
- Nothing personal on chain; keys are derived per agreement so public data does not link a person across agreements
The seal proves what was signed and how. The certificate proves who. The block header proves when.
HELTENIG.md v0.5 is withdrawn. It derived the signing key from e-mail + phone number under published constants, so anyone knowing those two facts could forge a signature. The file is kept for the record and must not be implemented.
BUDRUNDE.md — Verifiable Sealed-Bid Auctions (draft)
Commit–reveal sealed bids: no party sees any bid before the deadline, and anyone can verify afterward that the bid set was not altered.
- SHA256 commitments hide bids until reveal, bind them against change
- Commitment set anchored before deadline → auctioneer cannot peek, shill, or drop bids
- Identity-verified bidders (shared foundation) as the defense against Sybil/shill
The commitment proves what was bid. The anchor proves the set could not be altered. The identity proves each bid is a distinct person.
Beviset and Helt Enig v1 use the same key derivation algorithm (HKDF-SHA256, RFC 5869) with independent domain separators per service. The same identity produces different Bitcoin addresses for Beviset and Helt Enig — by design.
Helt Enig v2 does not use this foundation. It derives keys per agreement with BRC-42/43 from keys the parties or the service hold, and puts identity attributes in BRC-52 certificates instead of in key derivation (see HELTENIG-V2.md §9.1 for why).
Identity (BankID PID or email+phone) + per-user 256-bit salt
│
├─ domain: "wab-keygen-beviset-v1" → Beviset address (BankID)
├─ domain: "beviset-v1-keygen-emailphone" → Beviset address (email+phone)
├─ domain: "wab-keygen-heltenig-v1" → Helt Enig address (BankID)
└─ domain: "heltenig-v1-keygen-emailphone" → Helt Enig address (email+phone)
The full list of domain separators is in BEVISET §4.3. The algorithm is published; anyone holding the identity claim and the user's salt can re-derive the address and verify it against the blockchain. Services also expose a public /api/verify-address endpoint that confirms an address belongs to an identity without revealing the salt.
import hashlib, hmac
# Identity hashing (shared pepper for BankID)
PID_PEPPER = "beviset-protocol-pid-pepper-v1-datamynt"
identity_hash = hmac.new(PID_PEPPER.encode(), pid.encode(), hashlib.sha256).hexdigest()
# Key derivation (salted HKDF-SHA256). `salt` is a per-user 256-bit random
# hex string (the presentation key). Without it, derivation is forgeable —
# see BEVISET §4.5. The IKM is identity_input || salt.
def derive_key(identity_input: str, domain: str, salt: str) -> bytes:
ikm = identity_input + salt
prk = hmac.new(domain.encode(), ikm.encode(), hashlib.sha256).digest()
return hmac.new(prk, b"bitcoin-key-derivation\x01", hashlib.sha256).digest()- Specifications (BEVISET.md, HELTENIG-V2.md, HELTENIG.md, BUDRUNDE.md): MIT License
- Code (implementations): Open BSV License
datamynt.no · beviset.no · heltenig.no
Verification requires only math, not trust.