PeerMark is a digital registration and rights management platform built on the BSV blockchain. It allows creators, businesses, and individuals to register digital assets on-chain, creating timestamped, cryptographically verifiable evidence of their registration.

Think of it as a digital notary — recording what was registered, by whom, and when, in a way that cannot be altered after the fact.

PeerMark registers digital assets on the BSV blockchain. The flow, from upload to verification:

1. Canonicalise and hash (client-side) — your file is normalised to a canonical form and hashed with SHA-256 to produce the contentHash. It is then encrypted with a per-asset AES-GCM-256 key. Plaintext and keys never leave your device.
2. Broadcast the manifest (on-chain) — a manifest (content hash, cipher hash, storage mode, chunk info, encryption parameters, issuer signature) is written to the chain as OP_RETURN data. This is the proof.
3. Wrap the content key — the AES key is wrapped to your public key (ownerEnvelope, ECIES) and stored encrypted server-side. PeerMark cannot decrypt your content.
4. Download the .pmrk package — you receive a portable ZIP containing manifest.json, content.enc, the canonicalised bytes, and packageIndex.json checksums. It is your offline evidence.
5. Verify independently — verification re-derives hashes from the package and cross-checks the on-chain manifest. It does not require trusting PeerMark; the chain is the source of truth.

PeerMark is designed for anyone who creates or manages digital content and wants verifiable, timestamped evidence of their registrations. This includes:

• Photographers and visual artists — register original works
• Musicians and producers — register compositions, recordings, and beats
• Writers and journalists — timestamp articles, manuscripts, and research
• Software developers — register codebases, algorithms, and designs
• Businesses — register brand assets, contracts, and internal documents
• Anyone — who wants provable, timestamped digital records

No. PeerMark is designed to be accessible to everyone, regardless of technical background. The platform handles all blockchain interactions behind the scenes — you upload your files, set your preferences, and PeerMark takes care of the rest.

After creating your account, a short wallet setup process guides you through securing your keys. You do not need to understand how blockchains work to register and manage your assets.

Click Get Started on the home page. Account creation is a two-stage process:

Stage 1 — Account sign-up:

1. Enter your name and email address
2. Create a secure password
3. Verify your email address

Stage 2 — Wallet setup (required before registering assets):

1. Set up device authentication (WebAuthn / passkey) — binds your wallet to your device's secure hardware
2. Receive and securely store your backup recovery phrase

Once wallet setup is complete, you are ready to start registering assets.

BSV (Bitcoin Satoshi Vision) is a blockchain that restores and follows the original Bitcoin protocol as designed by Satoshi Nakamoto in 2008. It is optimised for data transactions, offering extremely low fees (fractions of a penny per transaction) and high throughput, making it ideal for registering digital assets on-chain.

PeerMark uses BSV for several key reasons:

• Low fees — registrations cost fractions of a penny, not pounds
• On-chain data storage — BSV allows data to be stored directly on the blockchain, not just a reference to it
• Full scripting language — BSV Script enables complex conditions like royalty enforcement and verifiable on-chain payment commitments
• Scalability — BSV handles high transaction volumes without congestion
• Immutability — once recorded, data cannot be altered or deleted

“On-chain” means that data is stored directly on the blockchain — a distributed, immutable ledger maintained by a network of miners. Once data is written on-chain, it cannot be altered, deleted, or tampered with by anyone, including PeerMark.

This is what gives your registrations their evidentiary strength: the timestamp and content hash are secured by the same proof-of-work mechanism that secures Bitcoin transactions.

Creating an account is free. There is no monthly subscription. You pay only when you register, buy, or licence an asset.

Registration has two parts: the BSV network (miner) fee, and a small PeerMark platform fee based on the declared asset value you set at registration (currently £0.49–£99.99). Marketplace sales and licences use the seller's price plus the platform commission disclosed in the checkout breakdown.

A wallet is your secure digital account on the BSV blockchain. It holds your funds (in satoshis) and manages the cryptographic keys used to sign transactions. Every registration, purchase, and licence transaction requires your wallet to authorise it.

Your wallet is set up during the Wallet Setup stage after account creation. No additional software is required — the entire process happens within the PeerMark platform.

Your wallet address is a legacy-compatible receiving identifier for exchanges and older BSV wallets. PeerMark-native payments prefer a direct transaction handoff using your wallet identity key, so the recipient receives the transaction details directly rather than relying on a global address scan.

You can top up your wallet from an external exchange or legacy wallet by sending BSV to your PeerMark receiving address. This compatibility path remains available because most exchanges still only support address-based withdrawals.

Where both sides support wallet-aware BSV payments, PeerMark will prefer direct transaction handoff with per-payment derived keys. That scales better and avoids expecting the recipient to discover payments by scanning every network transaction.

1. Go to your Dashboard
2. Copy your receiving address if the sender is an exchange or legacy wallet
3. Send BSV from your preferred exchange or wallet to that address
4. Funds typically appear within a few seconds to a few minutes

A satoshi (sat) is the smallest unit of Bitcoin (and BSV). One BSV equals 100,000,000 satoshis. Because BSV transaction fees are so low, amounts on PeerMark are often expressed in satoshis rather than whole BSV.

When you purchase or licence an asset on the Marketplace, the payment is processed as a BSV transaction. PeerMark's direction is to use wallet-aware direct transaction handoff for PeerMark-to-PeerMark payments, with per-payment derived recipient keys and explicit receipt of the transaction by the recipient.

For legacy destinations, the address-based path remains available as a compatibility fallback.

This means payments settle on the blockchain rather than inside a PeerMark ledger. For Marketplace purchases, the buyer's payment is locked in an on-chain escrow covenant (a Rúnar-compiled OP_PUSH_TX contract), and settlement is a single atomic transaction that pays the seller, pays any royalty output, and moves the access title together — neither half can confirm without the other. The access title itself is an output controlled by the owner's key; royalty terms are validated against the registered terms before PeerMark marks a settlement complete.

Transaction fees are small amounts paid to the BSV network miners who process and confirm your transactions. These fees are not charged by PeerMark — they go directly to the miners who secure the blockchain.

BSV fees are extremely low (typically less than £0.01), making frequent registrations and transactions practical and affordable.

Yes. Any BSV you receive from Marketplace sales or licence fees is held in your PeerMark wallet. You can send it to any external BSV wallet or exchange at any time. PeerMark does not lock or restrict your funds.

Blockchain transactions are irreversible. If you send funds to the wrong address, PeerMark cannot reverse, cancel, or recover the transaction. Always double-check the recipient address before confirming any transaction.

On the Withdrawal page, Max Withdrawable Now is the amount you can send in the current withdrawal process after reserving the estimated network fee.

Your wallet can still hold more total BSV than that if some satoshis sit inside protected asset-linked outputs, such as registrations, access titles, or licence records.

Yes. During the withdrawal process, protected outputs still belong to your wallet and remain part of your overall holdings.

They are excluded from standard withdrawals because they anchor registrations, access titles, or licence data. Sending them generically could damage the asset state they secure.

No. PeerMark's withdrawal process is designed to avoid protected outputs.

Before a standard withdrawal is built, PeerMark filters out asset-linked UTXOs and only passes vetted spendable inputs into the transaction. The wallet layer also performs an extra protection check before signing.

On the Withdrawal page, the Max button uses the same spend calculation as the Transfer Preview.

It excludes protected asset-linked outputs and leaves room for the estimated mining fee, so the figure shown should match what your device can actually sign and broadcast during the withdrawal process.

Your backup recovery phrase is one of three encrypted shares that together control your wallet (see 2-of-3 threshold custody). Anyone who obtains your phrase has one of the three shares — which alone is not enough to access your account, but combined with either your device or your account credentials, grants full access.

Guard it accordingly: your phrase is your disaster-recovery share. Keep it secure, offline, and never share it.

A private key is a secret cryptographic value that proves you own your wallet. It is used to sign transactions — authorising registrations, purchases, and transfers. Without the correct private key, nobody can spend your funds or move your assets.

PeerMark never stores your private key in plaintext. It exists only in encrypted shares, protected by your device's secure enclave and your recovery credentials.

Public and private keys are a matched pair at the heart of how PeerMark works:

• Private key — a secret number known only to you. It is used to:
  • Sign transactions (proving you authorised a registration, transfer, or licence)
  • Decrypt your owner envelope (unwrapping the content key to your asset)
  Your private key must never be shared. Anyone who holds it has complete control over your wallet and assets.
• Public key — mathematically derived from your private key, safe to share openly. It is used to:
  • Verify your signatures (anyone can confirm you authorised a transaction)
  • Encrypt data specifically to you — only your private key can decrypt it (used for owner envelopes and session key delivery)
  A receiving address is derived from wallet key material and is safe to share when a legacy sender requires one. PeerMark-native wallet flows prefer per-payment derived keys and direct transaction handoff instead of address reuse.

Device authentication (WebAuthn / passkeys) ties your account to your physical device using its secure hardware — such as a fingerprint sensor, face recognition, or a hardware security key. This ensures that even if someone obtains your password, they cannot sign transactions without physical access to your device.

In most cases, this is re-initialisation, not full disaster recovery.

If your WebAuthn/passkey credential still exists on the same device and PeerMark has a PRF-encrypted backup of your device share, PeerMark can usually restore local wallet access using your biometric or PIN plus your account password. Your backup phrase is not normally needed for that path.

If the PRF/WebAuthn path is unavailable — for example, the passkey is gone, the credential changed, or no compatible device-share backup exists — then you must use your backup phrase plus your account password to recover the wallet.

Generating a new backup phrase is a critical security operation. Currently this requires your existing backup phrase together with your account credentials — it cannot be performed with device authentication alone. This is intentional: it ensures the outgoing phrase is authenticated before a new one is issued.

If you lose your backup phrase entirely, you still have two remaining shares (device + account credentials) and can continue signing transactions normally. However, you will not be able to issue a new backup phrase until this is addressed through account recovery support.

If you lose your backup phrase and one other share (device or account credentials), recovery is impossible — only one share remains, below the 2-of-3 threshold.

Your account password protects the server-side recovery share (Share 2). When you reset your password, PeerMark tries to re-encrypt that recovery share under the new password on the same device if local wallet material is still available.

If that automatic re-encryption succeeds, no further action is required on that device. If it cannot be completed, your wallet may still continue working on the current device, but disaster recovery may still depend on your previous password until the recovery share is re-secured.

In that case, sign in on a trusted device, open Wallet Management, and run Re-secure Recovery Share. This re-encrypts Share 2 to your current password without changing your backup phrase.

If automatic re-encryption did not complete after a password reset, sign in on a trusted device that still has local wallet access, open Wallet Management, then choose Re-secure Recovery Share.

You will verify with your device and enter your current account password. PeerMark then re-encrypts the server-side recovery share (Share 2) to that password.

This action does not rotate your backup phrase, does not create a new wallet, and does not change your wallet address. It only updates the encryption on the server-side recovery share.

PeerMark splits your master key into three encrypted shares. Any two of the three are needed to reconstruct the key and sign transactions:

1. Device share — bound to your device's secure enclave (WebAuthn/passkey)
2. Account recovery share — an encrypted blob sealed to your account credentials, stored server-side (the server alone cannot use it)
3. User-held recovery share — your backup phrase, for disaster recovery

In day-to-day use, PeerMark tries to keep you on the least disruptive path. If the same device still holds your passkey and a PRF-backed device share exists, browser-data loss can usually be handled as device re-initialisation using your device plus account password. The backup phrase is the disaster-recovery path when the device-based route is unavailable.

Asset Protection Mode is a planned optional feature. It is not currently offered. If introduced, it would let you opt in to extra monitoring so that PeerMark can temporarily restrict Platform access — owner-envelope release, marketplace activity, and escrow co-signature — if compromise is reasonably suspected.

It would not give PeerMark the ability to transfer, licence, dispose of, or freeze your on-chain title. Title outputs remain spendable only by your wallet key.

PeerMark cannot unilaterally move, transfer, or dispose of your title. Your signing key is split across a 2-of-3 threshold; the server holds only an encrypted share and cannot spend on its own.

PeerMark does operate the access layer: it stores the owner envelope and releases it only to the current on-chain holder, co-signs cooperative escrow settlement, and — if you opt in — can derive licence session keys under delegation. A suspended account loses that Platform access, but the on-chain title remains with your key.

PeerMark is designed so that no single party — not PeerMark, not a government, not your ISP — has unilateral control over your asset registrations. This is achieved through several layered principles:

• Self-custodial keys — your private key is never stored by PeerMark in plaintext. It exists only across your 2-of-3 encrypted shares (device, account credentials, backup phrase). No single party holds enough to act.
• On-chain records are permanent and immutable — once a registration is mined, neither PeerMark nor anyone else can alter or remove it. Your registration survives even if PeerMark closes its doors.
• Encrypted content, private by default — your file content is encrypted before it leaves your device. The blockchain stores ciphertext, not plaintext. PeerMark's servers cannot read your files.
• Your records are unique to your key — on-chain registrations are signed by your wallet key. No party can claim or prove the registration without demonstrating control of that key. There is no central register of “who owns what” beyond the blockchain itself.
• Verification without trust — anyone can independently verify a registration by checking the blockchain directly. No trust in PeerMark is required to confirm the timestamp, content hash, or issuer signature.

In practice, strengthening a PeerMark registration claim means demonstrating wallet key control, possession of the .pmrk package, and (optionally) a verification attestation. This combination gives stronger evidence that the claimant controls the registered access bundle.

PeerMark supports a wide range of digital file types, including:

• Images — JPEG, PNG, WebP, SVG, TIFF, GIF
• Audio — MP3, WAV, FLAC, AAC, OGG
• Video — MP4, WebM, MOV
• Documents — PDF, TXT, DOCX, XLSX
• Code — any text-based source code file
• 3D & Design — GLTF, OBJ, STL, FBX

Only supported file types are accepted. Attempting to upload an unsupported format will be rejected at the point of selection. If your specific format is not listed, bundle it inside a .zip archive — zip files are supported and will produce a valid content hash for the bundled contents.

PeerMark has three distinct registration modes:

• Standard (on-chain) — for files up to 100 MB. The encrypted file is split into chunks and stored permanently on the blockchain. Buyers retrieve the full asset directly from the chain — no manual handoff. Best when you want the file itself permanently and immutably on-chain.
• Confidential — a privacy choice, not a size workaround. Only the manifest (content hash, cipher hash, encryption parameters) goes on-chain; the encrypted file stays on your device. Confidential assets cannot be listed on the Marketplace or licensed. Use this for private legal evidence, sensitive documents, or registrations you wish to keep entirely private.
• Large File — automatically applied when your file exceeds 100 MB. There is no upper size limit — since only the manifest goes on-chain, file size is irrelevant to the blockchain. Unlike Confidential, Large File assets can be listed, licensed, and sold — via a guided encrypted handoff with a BSV escrow contract protecting both parties.

File processing happens entirely in your browser, client-side. PeerMark's servers never receive your plaintext file. The steps are:

1. Format and size validation — the file type is checked against supported formats, and files over 100 MB are automatically routed to Large File mode (there is no upper size limit)
2. Malware hash check — the SHA-256 hash of your raw file is checked against a global threat intelligence database (VirusTotal). Only the hash is sent — your file never leaves your browser. If the hash matches known malware (flagged by 3 or more security engines), registration is blocked
3. Canonicalisation — the file is normalised to a consistent form to ensure a stable, reproducible content hash
4. Hashing — SHA-256 content hash and cipher hash are computed in your browser
5. Encryption — the file is encrypted with AES-GCM-256 in your browser before anything is broadcast

A content hash is a unique digital fingerprint of your file, generated using the SHA-256 algorithm. Even the tiniest change to the file — a single pixel, a single character — produces a completely different hash.

This hash is stored on-chain as part of your registration. Anyone can independently verify that a given file matches the registered hash, proving that the file has not been altered since registration.

A .pmrk package is a self-contained verification bundle that PeerMark generates after registration. It contains your encrypted file, the manifest, and all the metadata needed to independently verify the registration — without needing PeerMark's servers.

A .pmrk file is a standard ZIP archive with a fixed internal layout. You can open it with any archive tool (7-Zip, WinRAR, macOS Archive Utility). It contains:

• README.txt — human-readable instructions: what the package is, how to verify it, and backup guidance
• manifest.json — the registration manifest: asset ID, version, content hash, cipher hash, storage mode, encryption parameters, and (when present) the issuer signature fields and manifest/chunk transaction IDs
• content.enc — the encrypted content (AES-GCM-256 ciphertext)
• canonicalized/ — the canonicalised bytes whose SHA-256 is the on-chain contentHash (present for evidence packages; omitted for possession packages)
• raw/ — the original file, only if you opted in at registration (optional backup copy)
• packageIndex.json — SHA-256 checksums of every file in the package, used to detect tampering or accidental renames

The package is generated entirely client-side. PeerMark's servers never receive your plaintext file or your content key.

Packages for possession-gated assets deliberately contain no plaintext — no canonicalised folder and no raw copy. Only the encrypted content.enc is included.

This is by design: the package is your registration evidence and delivery medium, not a readable copy of the file. The content can only be read after authorised decryption by the current on-chain title holder. If the package leaked, nobody could read the file from it.

Verification still works: the cipherHash (SHA-256 of content.enc) and the on-chain manifest binding are fully verifiable without decryption. The contentHash is re-verified only after authorised decryption, when the plaintext legitimately exists.

BSV has no fixed OP_RETURN data size limit — a single transaction could theoretically carry an arbitrarily large payload. PeerMark still splits large files into chunks for several practical reasons:

• Merkle integrity — chunks form a Merkle tree, giving each piece of data a cryptographic position that can be independently verified without downloading the entire file
• Resumable broadcast — if one chunk fails to propagate or confirm, only that chunk needs to be retransmitted rather than the whole file
• Progressive streaming — recipients can begin verifying and reading chunks as they arrive rather than waiting for the complete dataset
• Network propagation — smaller discrete transactions propagate more efficiently across the BSV network than a single enormous payload

A manifest is the on-chain record that ties everything together. It contains the content hash, cipher hash, storage mode, chunk information, encryption parameters, and other metadata needed to verify and retrieve your registered asset.

Think of it as the “table of contents” for your registration — it tells anyone exactly what was registered, how it was encrypted, and where to find the data.

Canonicalisation is the process of normalising a file to a consistent form before hashing. Different devices and software can save files with slightly different metadata (e.g. EXIF data in photos, PDF creation dates), which would produce different hashes even if the actual content is identical.

PeerMark applies canonicalisation profiles (e.g. stripping EXIF from JPEGs, normalising UTF-8 text to NFC) to ensure that the same content always produces the same hash, regardless of which device created it.

PeerMark supports a wide range of common digital file formats (see What types of assets can I register? for the full list). Only supported file types are accepted. Size handling depends on the registration mode:

• Standard (on-chain) — up to 100 MB; fees scale proportionally with file size as more chunk transactions are required
• Public Asset (optional, digital assets only) — up to 100 MB, the same ceiling as Standard on-chain storage. The file is stored unencrypted on-chain so anyone can retrieve it via the manifest. Files above 100 MB cannot use Public Asset; they are registered as Large File assets (encrypted manifest only, with a guided handoff for buyers)
• Large File (auto-detected) — above 100 MB with no upper limit; only the manifest is broadcast on-chain, so fees are minimal regardless of file size
• Confidential — any size; only the manifest goes on-chain, but the file is private and cannot be listed or sold

BSV has no hard protocol cap on OP_RETURN data, but 100 MB is the practical architectural boundary for what makes sense to store directly on-chain. Here is why:

• Transaction count — a 100 MB file creates roughly 100 chunks (at 1 MB each) across around 11 transactions (1 manifest + 10 chunk batches). Beyond this, the broadcast and confirmation burden grows considerably
• Fee economics — at BSV's 100 sats/KB fee rate, storing 100 MB on-chain costs approximately 10,000,000 sats (~0.1 BSV). Storing the manifest only costs roughly 100 sats — the same evidentiary strength at a fraction of the cost, because the manifest hash is what proves the registration, not the presence of the raw bytes
• The chain as a trust anchor, not a warehouse — the blockchain's value is its immutable, timestamped record. That record is captured entirely by the manifest (content hash, cipher hash, issuer signature). The encrypted file bytes on-chain are a convenience for buyers, not the source of proof
• Retrieval practicality — pulling and reassembling hundreds of chunk transactions from the chain is increasingly slow and unwieldy as file size grows

Above 100 MB, Large File mode is triggered automatically with no upper size limit. The manifest (your proof) still goes on-chain as normal. The encrypted file stays in your custody and is delivered to buyers via a secure, escrow-protected handoff — giving the same evidentiary strength at a fraction of the cost.

Public Asset (unencrypted on-chain, optional on digital registrations) uses the same 100 MB limit as Standard encrypted on-chain storage — the full file must fit within that cap to be published publicly on the chain.

Registration typically completes within seconds to a few minutes. The process involves:

1. Client-side file hashing and encryption (near-instant for small files)
2. Transaction broadcast to the BSV network (near-instant)
3. Mining confirmation (typically within 1–10 minutes, depending on network conditions)

Your registration is considered pending until the first mining confirmation, after which it is permanently recorded.

When you register a public asset (files up to 100 MB — the same limit as standard on-chain storage), PeerMark generates a shareable media link visible on your registration confirmation page and in your dashboard. Simply copy that link and paste it anywhere — the platform handles the rest.

Social platforms that support rich previews — including X (Twitter), Facebook, LinkedIn, Discord, Slack, and Telegram — will automatically display an embeddable preview. Videos and audio play directly within the post without the viewer needing to leave the platform. Images are shown inline as a large card preview.

Yes. If the same content hash has already been registered — whether by you or by another user — PeerMark flags the duplicate as collision metadata rather than deciding which claim is correct.

If the earlier registration belongs to you, you will be directed to your existing certificate. If it belongs to another user, you will see a collision notice and the option to raise a dispute if you believe you have the stronger evidentiary claim.

PeerMark's verification system allows anyone to independently confirm that a registration matches the on-chain record. The Verify & Lookup page offers four methods:

• Certificate Lookup — enter the unique registration certificate ID to view the on-chain record
• Package Verification — upload a .pmrk file to verify its contents against the on-chain record
• Manifest TXID Lookup — paste a manifest transaction ID to retrieve the registration from the chain
• Wallet Address Scan — scan a BSV address to discover every registration broadcast from that wallet

Each method checks the on-chain record. Package verification runs in your browser; TXID lookup and address scan read the blockchain directly via public network APIs.

PeerMark offers escalating tiers of evidentiary strength:

• Tier 1 — Registered: Data registered by key at time. Timestamp evidence only. No identity verification required.
• Tier 2 — Identity Linked: Data registered by a verified person or entity. A verification partner attests to who you are — your identity is cryptographically linked to the registration via an on-chain certificate. The partner vouches for your identity, not your claim to the content.
• Tier 3 — Attested: Builds on Tier 2. A trusted third party (e.g. a law firm, notary, or industry body) additionally attests that, in their professional judgement, you have a legitimate claim to the content itself. This is the strongest evidentiary tier and provides the most robust dispute defence.

Verification Partners are trusted entities who provide independent attestation for PeerMark registrations. They are not gatekeepers — basic registration requires no partner involvement. Partners include:

• Law firms — attest to legal or contractual claims
• Notaries — provide timestamped witnessing of registration acts
• Industry bodies — attest to membership or domain-specific claims
• Institutional partners — universities, publishers, studios

Partner attestations are recorded on-chain as certificate UTXOs, independently verifiable by anyone.

PeerMark is an evidence layer, not an adjudication authority. A registration provides evidence that:

• That specific data existed at a specific time (timestamped by miner consensus)
• That a specific key authorised the registration (ECDSA signature)
• That the data has not been altered since registration (content hash integrity)

It does not prove that the registrant created the data, had authority to register it, or that no earlier version exists elsewhere.

Navigate to the Verify page and enter the certificate ID in the search field. PeerMark will retrieve the on-chain registration record and display the full details — including content hash, registration timestamp, issuer key, verification tier, and provenance chain.

On the Verify page, select the option to upload a .pmrk file. All cryptographic checks run locally in your browser — the package itself is not uploaded to PeerMark's servers. The verifier:

1. Extracts the ZIP and parses manifest.json and packageIndex.json
2. Recomputes SHA-256 of content.enc and compares it to the manifest's cipherHash
3. Recomputes SHA-256 of the canonicalised bytes and compares it to the on-chain contentHash (for possession packages this step is deferred until authorised decryption)
4. Verifies the issuer's ECDSA signature over the rights tuple when the signature fields are present
5. Checks every file against packageIndex.json to detect tampering or renames
6. Cross-checks the manifest against the on-chain record (manifest TXID, content hash, cipher hash)

If the hashes match and the signature is valid, the package is cryptographically consistent with the on-chain record and has not been tampered with since registration. A server call only confirms the manifest transaction exists in the index and reports its confirmation count — it never sees your file.

Every check PeerMark performs can be reproduced independently with standard tools:

1. Open the .pmrk with any archive tool and read manifest.json
2. Compute SHA-256 of content.enc and compare it to the cipherHash in the manifest
3. If the package contains canonicalized/, compute SHA-256 of that file and compare it to the contentHash
4. Look up the manifest transaction ID on a BSV explorer (e.g. whatsonchain.com) and confirm the OP_RETURN data carries the same hashes
5. If chunk transaction IDs are listed, the on-chain ciphertext can be recovered directly from the blockchain even if PeerMark is offline

That is the point of the package: verification does not depend on trusting PeerMark. The chain is the source of truth; the package is the portable evidence bundle that binds your file to it.

The Verify & Lookup page offers four methods. Anyone can use them — no account is required.

• Certificate Lookup — enter the certificate ID from a registration certificate or your asset details. PeerMark retrieves the registration record and shows its status, metadata, integrity hashes, verification tier and a blockchain explorer link.
• Package Verification — drop a .pmrk package. Every cryptographic check runs locally in your browser (hashes, structure, issuer signature). Only the manifest transaction ID is sent to confirm the on-chain record exists — the package itself is never uploaded. A modified file cannot match its registration.
• Manifest TXID Lookup — paste a 64-character manifest transaction ID. PeerMark fetches the transaction from the BSV network, parses the OP_RETURN manifest, and shows the registration details (content hash, cipher hash, storage mode, encryption parameters, chunk structure). For public assets, the file can be reassembled from its on-chain chunks and downloaded. For encrypted assets, only the manifest metadata is shown — the content stays protected.
• Wallet Address Scan — enter a BSV address to discover every PeerMark registration broadcast from that wallet, by scanning its transaction history for PeerMark manifest records.

Certificate lookup uses the PeerMark index as a cache and points you at the on-chain record. Package verification is client-side, then cross-checked against the chain. TXID lookup and address scan read the blockchain directly via public network APIs — the database is only ever a cache. Those two chain-direct tools are rate-limited because each request costs real network calls.

Key fields displayed on the verification results page:

• Content Hash — the SHA-256 fingerprint of the original file
• Cipher Hash — the hash of the encrypted version
• Issuer Key — the public key hash (PKH) of the registrant
• Registration Time — the block timestamp when the registration was mined
• Verification Tier — the level of evidentiary assurance (Registered, Identity Linked, or Attested)
• Manifest TX — the blockchain transaction ID of the manifest
• Signature Status — whether the issuer's ECDSA signature is valid

A content hash collision is detected when a file being registered already has an identical content hash on-chain. PeerMark flags the collision as metadata and provides a dispute path; it does not decide which registration is correct.

When a collision is detected at upload time:

1. The collision is flagged so both records can be reviewed as evidence
2. The user sees the existing certificate ID and registrant (partially anonymised)
3. If they believe they have the stronger evidentiary claim, they can raise a formal dispute
4. Automatic notification to the earlier registrant does not occur unless a dispute is filed

When you buy an asset on the Marketplace, an access-title transfer occurs on-chain. The title UTXO is spent from the seller's wallet to yours, with the expected creator royalty outputs included and validated before settlement.

How you receive the content depends on the registration mode:

• Standard assets (≤ 100 MB) — the content key is re-wrapped to your public key after the on-chain confirmation. You can retrieve the full encrypted file directly from the blockchain and decrypt it with your key.
• Large File assets (> 100 MB) — the file is not stored on-chain. After purchase, the seller uploads their .pmrk package via PeerMark's relay. The file is re-encrypted specifically to your public key, funds are held in a BSV escrow script, and released to the seller only after you download and the delivery is verified on-chain.

Licensing grants you temporary or limited authorised access to an asset without transferring the access title. Your payment is sent directly to the licensor's wallet on-chain — PeerMark never takes custody of licence revenue. After SPV confirmation, PeerMark releases the wrapped access material for that licence event.

Each licence payment is cryptographically bound to you, the specific licence, the asset, and the price by a single-use commitment the payment carries on-chain. This means only a transaction you created for that exact licence can unlock access — a coincidental or reused payment cannot.

The title holder retains the access title. Licence access is checked against the licence's active/revoked status and time window; expired or revoked licences are denied by the access route.

Buying (title transfer) gives you control of the transferable access title. While you remain the current on-chain holder, PeerMark can release the owner envelope to you after a fresh ownership check, and you can resell or transfer the title.

Licensing gives you limited access — either per-use or time-bounded — without transferring the access title. You receive licence-specific access material and cannot resell the title.

Asset owners set their own licence terms, but common types include:

• Personal — for individual, non-commercial use
• Commercial — for use in commercial projects, products, or services
• Extended — broader commercial rights, potentially including redistribution or derivative works

The specific terms for each licence are hashed and stored on-chain, so they are immutable and verifiable.

After your transaction is confirmed on-chain:

• Title purchase — the buyer envelope is activated for your wallet, the previous holder's active delegations are revoked, and the asset appears in your portfolio. Future owner access is gated by a fresh on-chain title check.
• Licence — licence-specific access material is released after SPV confirmation. You can access the content while the licence is active and within its time window.

On sales settled through PeerMark, the royalty output is a required output of the atomic settlement transaction itself: the buyer's payment sits in an escrow covenant whose settlement branch pays the seller and the royalty in the same transaction that moves the access title. A PeerMark settlement cannot be produced without the registered royalty output, and the terms are validated against the registration before settlement is marked complete.

In the interest of honesty: the access title is an output controlled by the owner's key. If a holder spends it outside PeerMark's settlement flow, no script forces a royalty on that external spend — the on-chain custody chain records the move, and the authorised-version provenance is what distinguishes platform-settled transfers. Covenant-enforced titles that pin royalties at script level remain on the roadmap.

PeerMark charges fees in three contexts:

• Registration — a tiered flat fee in GBP, based on the declared asset value you set at registration:
  • Up to £9.99 — £0.49
  • £10.00–£24.99 — £0.69
  • £25.00–£99.99 — £0.99
  • £100.00–£999.99 — £1.99
  • £1,000.00–£24,999.99 — £3.99
  • £25,000.00–£99,999.99 — £6.99
  • £100,000.00–£499,999.99 — £11.99
  • £500,000.00–£999,999.99 — £24.99
  • £1,000,000.00–£9,999,999.99 — £59.99
  • Above £10,000,000 — £99.99
  You also pay the BSV network (miner) fee on top: ~100 sats/KB for Standard mode, or a fixed ~100 sats for Confidential and Large File mode.
• Marketplace sales (title transfers) — PeerMark takes a 1.5% platform commission on the sale price. The remaining 98.5% goes to the seller, minus any creator royalties enforced by the on-chain script.
• Licensing transactions — your payment is sent directly to the licensor's wallet; PeerMark does not take custody of licence revenue. PeerMark's 3.5% platform fee is added as a separate, transparent output on top of the licensor's payment — never deducted from it. The licensor always receives the full quoted price, and the exact fee is shown in the breakdown before you confirm.

All fees are disclosed in the breakdown before you confirm any transaction. BSV network fees are paid to miners — not to PeerMark.

A provenance (custody) chain is the complete on-chain history of an asset — from its initial registration through every transfer, licence grant, and key rotation event. It is an auditable timeline that proves the unbroken chain of custody.

This is the primary differentiator between an authorised version and a copy: the authorised version has a complete, SPV-verifiable provenance chain. A copy has none.

Yes. PeerMark title tokens are transferable by design. You can resell your asset on the Marketplace, gift it to another user, or transfer it to a compatible BSV wallet destination. PeerMark-native transfers prefer wallet identity and direct transaction handoff; address-based transfer remains a legacy compatibility path. Royalty outputs are included and validated as part of transfer settlement.

This restores transferability for digital access titles — resale, gifting, and bequest — that traditional digital licensing models have historically removed.

Every asset has an access class. Public assets are openly viewable by anyone via their custom URL — there is no access gate. Everything else defaults to a possession asset: owner key release is allowed only after PeerMark verifies that the requester is the current on-chain title holder and that the title outpoint is still unspent.

When you transfer or sell a possession asset, the buyer's owner envelope becomes current, the seller's active delegations are revoked, and the old holder can no longer obtain new authorised owner access through PeerMark.

Not yet. PeerMark currently implements gated-access possession: the platform releases the owner envelope only to the current on-chain title holder after a fresh spentness check, and transfer revokes future authorised access through PeerMark.

The planned hardened model is a future TEE/threshold-oracle boundary. In that model, the content key is never reconstructed as a single raw key on the holder's normal device; authorised decryption happens through a boundary that checks current title state before each fresh access session.

Encryption ensures that only authorised parties (those with the correct key) can access your content. Without encryption, any data stored on-chain would be publicly readable by anyone. Encryption turns your file into unintelligible ciphertext that is useless without the decryption key.

This is what makes the “authorised version” genuinely superior to any copy — the copy is encrypted data without the key, or at best a degraded screen capture.

AES-GCM-256 (Advanced Encryption Standard — Galois/Counter Mode, 256-bit key) is an industry-standard authenticated encryption algorithm. It provides both confidentiality (nobody can read the data) and integrity (any tampering is detected).

PeerMark uses AES-GCM-256 for all content encryption. Each asset gets a unique 256-bit key and a deterministic nonce derived from the asset ID.

An owner envelope is the per-asset content key encrypted (wrapped) to the current holder's wallet public key using ECIES. It is stored server-side as an encrypted blob — useless to anyone without the matching private key.

For possession assets, PeerMark releases the current owner envelope only after a fresh on-chain title check. When the access title transfers, the buyer's envelope becomes current, the previous holder's envelope is superseded, active delegations are revoked, and the content-key epoch is advanced for future hardened derivation flows.

The content key (also called the master content key) is the AES-GCM-256 key that encrypts and decrypts the actual file. For the owner path today, that key is wrapped in the current owner envelope and unwrapped client-side by the authorised holder's wallet.

A session key is licence-specific access material derived for a spend event using HKDF. It is scoped to the licence transaction and is released only after the payment/spend is confirmed.

No, for the owner path: encryption and decryption occur client-side — in your browser, on your device. PeerMark's servers handle encrypted ciphertext and encrypted owner envelopes, not plaintext files.

Current possession assets are still a gated-access model: an authorised holder can unwrap the content key on their device while they hold the title. Transfer revokes future authorised access through PeerMark, but it cannot erase plaintext or keys already observed on a previous holder's device. The future hardened TEE/threshold boundary is intended to reduce that raw-key exposure.

Public listings make the asset's metadata (title, description, preview) visible on the Marketplace. The encrypted content is still protected — only the metadata and previews are public.

Confidential registrations are private to the registrant's account — they do not appear in the Marketplace and cannot be listed, licensed, or sold. Like all registrations, a Confidential asset does receive a Certificate ID, and its on-chain manifest (content hash, cipher hash, encryption parameters, timestamp) is publicly verifiable via the certificate view. However, the file itself never leaves the registrant's device; only the cryptographic proof is on-chain. Third parties can verify that data existed at a point in time — they cannot view, access, or download the content.

PeerMark provides a structured path for contested registrations, but it does not adjudicate. The framework is designed around voluntary, market-supplied arbitration:

1. Filing — either party files a dispute referencing both registrations
2. Evidence submission — both parties submit on-chain and off-chain evidence
3. Mediation (optional) — an approved mediator reviews evidence and proposes resolution
4. Arbitration (optional) — an approved arbitrator issues a ruling (binding only if both parties opted in)
5. On-chain recording — the outcome is recorded as an attestation UTXO

If someone registers your content before you, their registration will have an earlier timestamp. However, an earlier timestamp is evidence, not proof. The genuine creator's advantage lies in the totality of evidence they can bring:

• Original draft history, EXIF metadata, email records
• Witness testimony or collaboration records
• Earlier timestamps on other platforms
• Higher verification tier (identity linked or attested)

PeerMark's collision detection system will flag the duplicate and display the earlier registration. Both registrations can remain evidence records, and you can raise a formal dispute if you believe your claim is stronger.

No. PeerMark does not remove registrations from the blockchain — this is technically impossible, as on-chain data is immutable. Disputed registrations are flagged with a dispute marker, not deleted.

This aligns with PeerMark's role as an evidence layer: both the original registration and the dispute flag are part of the evidentiary record.

You can reach PeerMark support at support@peermark.online. We aim to respond within 24 hours on business days.

For urgent security concerns (suspected account compromise, unauthorised transactions), please email security@peermark.online with the subject line “URGENT”.

PeerMark is designed primarily for digital-native assets where the on-chain record is the title. Real-world assets (property, vehicles, collectibles) involve legal systems, registries, and regulators that exist outside the blockchain.

While you can register a digital representation of a physical item (e.g. a photograph of a painting, a 3D scan of a sculpture), the on-chain registration alone does not establish legal ownership of the physical object.

For a real-world asset registration to carry legal weight, all four of these conditions must be met:

1. Legal right defined in a binding contract — the ownership claim must exist in law before it exists on-chain
2. On-chain record designated as authoritative — the contract must specify that the blockchain entry is determinative of title
3. Compliance with relevant jurisdiction — the arrangement must survive legal scrutiny in the applicable jurisdiction
4. Dispute mechanism courts will respect — structured arbitration with enforceable outcomes

Without all four, you have evidence — not legal ownership.

No. On-chain registration proves that specific data was registered by a specific key at a specific time. It does not prove that the registrant owns the physical item, that the item exists, or that it corresponds to its digital representation.

PeerMark is honest about this limitation. A hash proves data integrity — it does not prove physical authenticity. We provide a robust evidentiary layer; your rights are as solid as the law that recognises them.

A blockchain transaction is a signed message that transfers value or records data on the blockchain. Each transaction has inputs (where the funds or data come from) and outputs (where they go). Once confirmed by miners, transactions are permanent and irreversible.

On PeerMark, transactions are used to register manifests, store encrypted chunks, record rights metadata, and process payments.

SPV is a method for verifying that a transaction is included in a block without downloading the entire blockchain. It uses Merkle proofs — a compact mathematical proof that a specific transaction exists within a block's Merkle tree.

PeerMark uses SPV to verify transactions efficiently, enabling key release (for licences) and verification (for registrations) without requiring users to run a full node.

UTXO stands for Unspent Transaction Output. It is the fundamental unit of value on the Bitcoin/BSV blockchain. Think of UTXOs as individual “coins” — each with a specific value and conditions for spending.

On PeerMark, title UTXOs represent transferable access titles. A title transfer spends the title UTXO to create a new one under the new holder's conditions. Licensing is settled by a committed on-chain payment sent directly to the licensor and bound to your specific licence — the title itself is not spent, and access material is released after the payment confirms.

A Merkle tree is a data structure where each leaf node is a hash of a data block, and each internal node is a hash of its two children. The top of the tree — the Merkle root — is a single hash that represents the integrity of all the data below it.

PeerMark uses Merkle trees to link transaction chunks together. If any chunk is altered, the Merkle root changes, instantly revealing the tampering.

ECIES (Elliptic Curve Integrated Encryption Scheme) is an asymmetric encryption method that uses elliptic curve cryptography. It allows you to encrypt data to someone's public key so that only their private key can decrypt it.

PeerMark uses ECIES for owner envelopes — wrapping content keys to the asset owner's public key so that only the owner can unwrap them.

HKDF (HMAC-based Key Derivation Function) is a cryptographic function that derives new keys from existing key material. It takes a master key and some additional data (like a transaction ID and use index) and produces a new, unique key.

PeerMark uses HKDF-SHA256 to derive session keys from the master content key. The formula is: HKDF-SHA256(masterContentKey, spendTxid + useIndex). This ensures each session key is unique, deterministic, and cannot be used to recover the master key.