The following is an attempt to propose a method for loading standardized, readable data onto blockchain networks.

Introduction

A certain demand exists for the permanence, traceability, and publicity of data records; one that spans across a great number of domains, including those of the enterprise, the government, all the way to the individual. As it has been demonstrated by putting raw data on a blockchain, as well as the use of Non-Fungible Tokens (NFTs), the applications of blockchains do not end at simple token transfers and can extend to unique, “anchored” records. This has led entrepreneurs and enthusiasts alike to explore the viability of ideas such as decentralized social networks, marketplaces and games, and their users to refer to this on-chain data as historical truth. Permanence here corresponds more to immutability (impossible to alter) than it does to time, as blockchains too can perish. Such benefits, however, do not exist if a user cannot retrieve the actual data that has been recorded, or is only said to have been recorded, on the blockchain. Placing only hashes of records on-chain to reference the material at hand presents this very problem, whereas a receiptlike format that visibly states detail would not. Having standardized on-chain records readable both to the human and to the machine can offer not just immutability, but also the means of processing and organization. The structure of records can easily be made to fit everything from a train’s schedule, a purchase receipt, to a poem or personal manifesto. If necessary, binary files may be included alongside their detail. The aim should be to be able to anchor data on as many blockchains as is feasible, precisely because they are perishable. Given that loading data onto a blockchain can be a practical stress test, this might empirically offer an idea which chains excel at which metrics. Many blockchains fundamentally cannot handle raw data, as they either have built in-limits or unmanageable transaction fees. Fees, however small, can still act as a filter against at-scale dishonesty. However, this should not be a focus—the required trust in a record issuer can be obtained with historical on-chain precedence, public key announcement from the official source, or observations made by other network users.

Record Format

We define the format suited for structuring most types of records as JSON-LD, as the support and use of it has been well-established on the internet by now. Schema.org and its contributors provide a number of examples for schemas that we can use to structure a variety of records. Taking the instance of a generic purchase transaction acknowledgement:

{
  "@context": "https://schema.org/",
  "@type": "SellAction",
  "description": "October 15th 2025 fix of a leak",
  "seller": {
    "@type": "Person",
    "name": "Jack Plumber",
    "identifier": "ABC123"
  },
  "buyer": {
    "@type": "Person",
    "name": "Jane Doe",
    "identifier": "DEF456"
  },
  "object": {
    "@type": "Service",
    "name": "Broken pipe fix",
    "description": "Standard visit"
  },
  "price": "200",
  "priceCurrency": "USD",
  "validFrom": "2025-10-15",
  "location": {
    "@type": "Doe House",
    "address": "31 Spooner St, RI"
  }
}

Being a highly flexible format, JSON can be extended to fit any type of record, with the level of depth and detail only limited by the preferences of the user or interface designer. Prior to anchoring, JSON should be canonicalized by sorting keys alphabetically to preserve order across different systems. The files should follow the UTF-8 encoding and have no whitespace. Some common record types (@type) can include but mustn’t be constrained only to:

Transactions: BuyAction, SellAction, Invoice
Credentials: EducationalOccupationalCredential
Statements: Article, Message, CreativeWork
Creative works: CreativeWork, MediaObject
Legal: use appropriate Schema.org types or extend

Protocol Identifier

Our LARP transactions will include a 5-byte protocol identifier prefix 0x4c41525031 (LARP1 in hexadecimal), which is to appear at the start of the transaction data field:

0x4c41525031 + [JSON data as hex]

The purpose of this identifier is to distinguish LARP messages from other on-chain data, enable potential indexers to find protocol messages, and support numbered protocol versioning.

The full transaction data field would amount to:

0x[HEX_PROTOCOL_ID][HEX_JSON_DATA]

Or:

0x4c415250317b2240636f6e74657874223a…

Which, decoded to UTF-8, will be

LARP1{"@context":…

Anchoring Process

For interoperability reasons, JSON is to be canonicalized by sorting its keys alphabetically. The full JSON is then converted to hexadicimal and placed in the transaction data field—this will provide for fast decoding. Then, a transaction is broadcast to the chosen blockchain, from a wallet to itself or any address. A proof file can be generated, which would contain the name of the blockchain, the txid, and the block number. We don’t see it as a necessity to have the original anchored record inside the proof file, as the data is already on-chain. If successful, transactions can be fetched by anyone, using a block explorer or similar tools, and their data—decoded.

{
  "proof": {
    "chain": "polygon",
    "chainId": 137,
    "txid": "0xabc...",
    "block": 12345678,
    "timestamp": "2025-10-17T10:30:00Z"
  }
}

To experiment and explore practicality, we have created a software utility consisting of three parts for each of the initial blockchains. The first is a wrapper for creating transactions that uses common remote procedure call (RPC) endpoints to communicate with the chain and anchor data. This can be used as a programming library. Another is a way to interact with the wrapper using a command line, and the third—a verifier of proofs.

Record anchoring using the command line can be initiated with the following:

larp anchor receipt.json --chain polygon --key 0xYOUR_PRIVATE_KEY

If desired, the transaction’s proof file can be verified:

larp verify receipt-proof.json
...

Programmers can use the anchor as a library, where:

import { anchorToEVM } from 'permanent-record-protocol';
const proof = await anchorToEVM(
  // JSON data
);
console.log('Anchored:', proof.txid);

Binary Files

Although the capacities of most blockchains at this time allow only for small chunks, kilobytes of data to be loaded onto them, and the protocol is designed primarily with “receipts” in mind, there exist cases where binary files may be viable and could either supplement such receipts or remain standalone, provided they are loaded in a workable format. In order to maximize compatibility and ease of transformation, binary files should be encoded into Base64 and then wrapped inside the JSON schema. It should be noted, however, that Base64 encoding will increase file sizes by about 33%, applying even more pressure to the blockchains and getting transaction sizes closer to their limits (if applicable), as well as making for higher transaction fees. To create a JSON record that includes an image encoded in Base64:

cat > contract-record.json << EOF
{
  "@context": "https://schema.org",
  "@type": "DigitalDocument",
  "name": "Signed Contract",
  "encodingFormat": "application/pdf",
  "contentData": "$(base64 -w 0 contract.pdf)"
}
EOF

The encodingFormat key follows MIME types (e.g., “image/jpeg”, “application/pdf”) and contentData is the Base64-encoded binary data itself. For retrieval of the anchored file, the transaction is fetched and its (1) hex input data is decoded back to JSON, (2) Base64 from contentData is decoded back to binary, with the encodingFormat used to determine the filetype. The following schema fields can be used to indicate the nature of the data:

DigitalDocument for PDF, Word, and other document processing. ImageObject for photos, scans of documents. VideoObject and AudioObject for video and audio. MediaObject for general or non-specified binary data.

Linking Records

Having one additional field, records can reference each other by transaction hash. With this, updates or corrections to a record can be made by way of versioning, and related transactions can be linked. Even token transfers can be connected to anchored records. In a sense, certain chains of proof generate, as the order of transactions is not as relevant when references exist. Agreements and acknowledgements between multiple parties then have a way of obtaining structure and searchability if every party involved references records issued by the others. This can also act as a filter against counterfeit records and on-chain noise.

We define a plain URI scheme that in-JSON references can use as their format with larp:[chain]:[txid], where:

larp is the protocol identifier
[chain] is the blockchain name (polygon, ethereum, bsv, etc.)
[txid] is the transaction hash

An amendment or correction of a record might look like this:

{
  "@type": "Article",
  "name": "Updated Essay v2",
  "isBasedOn": "larp:bsv:0xdef456...",
  "textContent": "..."
}

An invoice record referencing an order:

{
  "@context": "https://schema.org",
  "@type": "Invoice",
  "referencesOrder": "larp:bsv:0xabc123...",
  "totalPaymentDue": {
    "@type": "PriceSpecification",
    "price": 500,
    "priceCurrency": "USD"
  }
}

The protocol does not inherently validate references; therefore, a theoretical reference verifier would be needed to check if a referenced transaction exists and contains valid records when decoded, and to map record relationships. Beyond the individual record, for instance, a low trust entity may be one that references others or itself but is not referenced by other entities (tree-like), whereas a high trust entity may be one that both references and is referenced (graph-like). A record of significance may not reference transactions at all but be heavily referenced by other records (reverse tree-like).

Identity

The public key, or wallet, itself translates to identity, where its owner decides how much to reveal outside and inside the blockchain. While it could be advised not to reuse wallet addresses in token transfers if privacy is of interest, as a record issuer, using the same address for data-only transactions provides for reliable historical precedence. Without additional infrastructure, entities have their track record from anchored records public and queryable by transaction hashes. That is, unless the record happens to be authentic enough for the previous activity of the source to become irrelevant. Block explorers should provide enough information to make decisions based on the activity of entities and the contents of their records.

Extensibility

JSON schemas offered by Schema.org should not be set in stone but extended based on the user’s needs, as attempting to create templates for every possible type of record would be an impossible task. However, additional vocabularies unique to their domain can be created, and themselves extended based on need.

Security and Privacy

The protocol will inherit the security and privacy mechanisms from the blockchain on which it is used. As with most blockchain systems, transactions and their data are immutable, public, and permanent. Changes to a record, to be anchored, require a new transaction with or without the full data, preferably having a reference to the transaction with the preceding version of the record. Data inside the JSON schema can be encrypted by the user if he chooses to utilize the blockchain for its immutability but seeks protection of sensitive data. Where records are not referencing each other, there can be benefits in only the parties involved knowing the addresses used. If available, it is advised to use testnets of the underlying blockchains initially or for experimentation, as mainnet transaction fees can be significant in many cases and costly mistakes should be prevented.

Limitations

Some blockchains, for instance, Bitcoin Core, have limits on how much data can be loaded onto them inside a transaction. Others do not have such a limit, but on several, the smallest chunks of data may incur significant fees. For the time being, even some of the most popular blockchains would not be viable for on-chain recordkeeping, as popularity does not always equate to utility. Blockchains which are said to be layers of another tend to have their own handicaps both in operation and philosophy despite the perceived effectiveness. Yet still, there exist options which would not present anchoring data efficiently as a big challenge in spite of a mounting number of transactions. A more detailed comparison between the different blockchains’ limits, costs, and speeds is outlined in the manual stored alongside the source files.

Summary

Introduced is a set of simple procedures for anchoring readable data records on multiple blockchains in a standard format. The anchored schemas may include files, as well as references to other transactions or anchored records. Loading full data directly on a blockchain means the need to consider the costs and the true efficiency of the chosen blockchain network. The incentive for anchoring is the immutability of records, where there can be undeniable evidence that a certain entity had stated something at a certain time, regardless of whether their identity can be surely known. Neither truths nor untruths can be taken back. With structure, records can have more universality and be interpretable by computers. The proposed protocol does not have off-chain dependencies, and the permanence of each record is based solely on the blockchain that holds it. While existing block explorers offer a great deal of transaction tracing tools for the individual record, given an increase in the number and complexity of “record networks,” additional infrastructure may be required that would handle the discovery and indexing of records.

Source files for the proof-of-concept software and the full specification can be found in this GitHub repository: https://github.com/randinst/anchor

You May Also Enjoy

In abandoned waterpark

A bald man heftly built throws you in the water off the ramp, along with a man-sized iron arrow you must catch in fall.

The Correct Kind of Work

The most profitable and timetested money-making system in the world is Communism. Compared to Communism, alternative systems crumble under pressure and invit...