Blockchain anchoring would be beneficial for documents such as ownership titles, educational certificates, regulatory compliance reports, contracts, physically signed or notarized documents, purchase orders, invoices with tax implications, bills of lading and other shipping materials, and trade agreements.

Storing document records, including the cryptographic hash, location, and other metadata, on a blockchain network would complement typical document storage/content management features, such as versioning, searching, tracing documents, and document-level access control.

Such a Blockchain-anchored-Document-as-a-Service (BaDaaS) would manage two types of artifacts—an actual document or image file stored off-chain, and document attributes, such as a unique document ID, content hash, document version, and other metadata, recorded and posted to a blockchain network as an immutable record. Any activity that involves these off-chain documents will be stored on-chain as a blockchain transaction, while related document attributes will be stored as its payload on-chain.

Essentially, BaDaaS offers the following types of API:

1. An API to upload a document by invoking a POST call, or replace a document with a new version by means of a PUT call. Each folder or container could be mapped to a separate blockchain channel for sharding purposes.
2. An API to retrieve documents using GET APIs, which allow authenticated users to download or view the document, but only after its hash has been verified against the one stored in the blockchain record.
3. An API to retrieve the document history based on the blockchain transaction history, with all the relevant versions and other metadata changes, timestamps, user identities, and so on.
4. An API to retrieve metadata for the latest version and verify that the document content matches the hash stored on the blockchain without downloading the document itself.
5. APIs for managing access permissions and granting new ones. These changes should also be stored on-chain to ensure their immutability as a series of access control list (ACL) records linked to the document records via a document ID.

This is an example of an approach that would solve the on-chain/off-chain storage requirements for certain classes of use cases. It would not burden the blockchain with large-size payloads, but would, at the same time, ensure that document integrity and transaction history is maintained on-chain in an immutable manner. 

So far, we've discussed large unstructured objects, such as binary image data, and PDF files. Could this be applied to large-size structured documents? For example, in supply chain collaboration demand forecast and planning, documents can contain hundreds of MBs of structured data, which is impractical to share as a payload of blockchain transactions. The good news is that an approach similar to the one described previously with unstructured documents can be used. Only selected data is extracted for blockchain records, and the entire document is hashed to ensure that its integrity can be verified on the other end. The documents can be transferred using traditional means (for example, EDI, and B2B file transfer) but, on both ends of the transfer, the blockchain is used to store (when sending) and retrieve and verify (when receiving) the relevant metadata fields, including using the hash to verify the integrity of the transferred document.