ERC-1643 Explained: On-Chain Document Management for Security Tokens

ERC-1643 is a small interface, part of the ERC-1400 family, that lets a token publish named documents — each with a URI, a content hash and a last-modified timestamp. Investors, auditors and venues can read the current prospectus, term sheet or notice straight from the token contract and verify that the file they downloaded is exactly the one the issuer published. For real-world assets, where the token’s value depends entirely on off-chain legal documents, that link is essential.

The interface

function getDocument(bytes32 name) external view returns (string memory uri, bytes32 documentHash, uint256 lastModified);
function setDocument(bytes32 name, string calldata uri, bytes32 documentHash) external;
function removeDocument(bytes32 name) external;
function getAllDocuments() external view returns (bytes32[] memory);

event DocumentUpdated(bytes32 indexed name, string uri, bytes32 documentHash);
event DocumentRemoved(bytes32 indexed name, string uri, bytes32 documentHash);

Only authorised roles (issuer, transfer agent) should be able to call setDocument and removeDocument.

Why document integrity matters for RWAs

A real estate token is only as good as the title deed, valuation and lease schedule behind it. A bond token is only as good as its indenture. If investors cannot prove which version of a document applied at the time they invested, disputes become expensive. ERC-1643 creates a public, timestamped trail: every update emits an event, so the full history of disclosures is reconstructable.

How we implement it

On our real estate tokenization platform, property documents are uploaded during onboarding, stored on IPFS, and their hashes are recorded on the ledger. Reconciliation jobs cross-check IPFS, the off-chain database and the chain so the three never drift apart. A typical setup:

1. Upload the document to IPFS (public) or to encrypted storage (confidential), obtaining a content identifier.
2. Hash the file with SHA-256 or keccak256.
3. Call setDocument with a name such as "PROSPECTUS_V2", the URI and the hash.
4. Display documents in the investor portal, recomputing the hash client-side to show a “verified” badge.
5. Version by name (TERMSHEET_2026_Q4) or keep a stable name and rely on events for history.

Confidential documents

Many RWA documents contain personal or commercially sensitive data. Do not put them on public IPFS. Instead store them encrypted or in an access-controlled data room and publish only the hash and a gated URI on-chain. Investors with access can still verify integrity; the public sees only that a document exists and when it changed.

Typical documents to register

Beyond ERC-1643

ERC-1643 is deliberately simple. For richer needs, combine it with: verifiable credentials for document issuers, proof-of-reserve and oracle feeds for live data, and Hedera Consensus Service or similar anchoring for high-frequency records such as meter readings.

Example: adding ERC-1643 to an existing token

// Illustrative mixin — not audited.
abstract contract DocumentRegistry is AccessControl {
    bytes32 public constant DOCS_ROLE = keccak256("DOCS_ROLE");
    struct Doc { string uri; bytes32 docHash; uint256 lastModified; }
    mapping(bytes32 => Doc) private _docs;
    bytes32[] private _names;

    event DocumentUpdated(bytes32 indexed name, string uri, bytes32 documentHash);
    event DocumentRemoved(bytes32 indexed name, string uri, bytes32 documentHash);

    function setDocument(bytes32 name, string calldata uri, bytes32 docHash) external onlyRole(DOCS_ROLE) {
        if (_docs[name].lastModified == 0) _names.push(name);
        _docs[name] = Doc(uri, docHash, block.timestamp);
        emit DocumentUpdated(name, uri, docHash);
    }

    function getDocument(bytes32 name) external view returns (string memory, bytes32, uint256) {
        Doc memory d = _docs[name];
        return (d.uri, d.docHash, d.lastModified);
    }

    function getAllDocuments() external view returns (bytes32[] memory) { return _names; }
}

A document governance policy

Technology is the easy part. Agree a written policy covering:

• Who may publish each document type (issuer, administrator, legal counsel).
• Approval workflow before a hash is written on-chain.
• Naming and versioning conventions so integrators can find the latest version.
• Retention of superseded documents (keep them accessible for investors who relied on them).
• Confidentiality classification: public, investor-only, regulator-only.

Verifying documents in the investor portal

A good investor experience makes verification invisible:

1. Portal fetches getAllDocuments() and displays names and dates.
2. When an investor opens a document, the portal downloads it and computes its hash in the browser.
3. If the hash matches the on-chain record, a “Verified on-chain” badge appears with a link to the transaction.
4. If not, the portal warns the investor and alerts the operator.

Beyond issuance: ongoing disclosures

Use the same mechanism for quarterly reports, valuation updates, audited accounts, rent rolls, ESG reports and corporate-action notices. Over time, the token becomes a verifiable disclosure archive — valuable in disputes and audits.

Frequently asked questions

Written by the NUVZ Tokenization Team

NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies

This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.