The full normative NORA-1 specification text lives in a public Git repository on GitLab. This page is an evergreen overview; the canonical source of truth is the Markdown document in the repo.
Read the spec on GitLab View the repoNORA-1 is an open specification for anchoring real world asset records to a public blockchain. A record is an encrypted bundle of documents whose existence, byte exact contents, and moment of anchoring can be cryptographically proven later, by anyone, using off the shelf standard tools.
The format is built on long lived open standards (OpenPGP, ZIP, IPFS or Arweave content addressing, JSON, BIP-39) so that records minted under it remain recoverable indefinitely, independent of NFTObscura's continued existence.
Tokenizing real world assets on a blockchain is increasingly common, but most existing approaches either expose sensitive document contents to the entire world (because IPFS metadata is public) or lock the documents inside vendor specific systems that disappear when the vendor does. Neither is acceptable for records that may need to outlive a single platform by decades: deeds, contracts, certificates, wills, identity documents, intellectual property assignments, and similar.
NORA-1 separates three concerns that have historically been tangled together:
NORA is intentionally narrow in scope. It is not a token standard, not an oracle or valuation system, not a legal certification mechanism, and not a registry of ownership or rights. Transferring a NORA token does not transfer any real world right; the token references an anchored record, nothing more.
NORA records have no inherent legal effect. They are technical artifacts that may or may not be useful as evidence in any specific legal context. NORA is not a substitute for any service performed by a notary, lawyer, registrar, or competent authority.
The full list of non goals is in section 1.2 of the specification.
A NORA-1 record can always be recovered using only:
No NORA specific software is required for recovery. The format is deliberately built so that if NFTObscura disappears, every record minted under NORA-1 remains decryptable indefinitely with the off the shelf tooling that already exists today and is expected to keep existing for the foreseeable future.
NORA-1 uses only widely deployed, well analyzed primitives. There are no novel constructions and no custom cryptography.
| Component | Algorithm |
|---|---|
| Symmetric encryption | AES-256 inside an OpenPGP SEIPD packet (RFC 4880 / RFC 9580) |
| Key derivation | OpenPGP S2K type 3 with SHA-512, iteration count octet 0xE0 |
| Bundle key encoding | BIP-39 24 word English mnemonic |
| Plaintext document hashing | SHA-256 and SHA-512 (both required) |
| On chain anchor hash | SHA-256 |
| JSON canonicalization | RFC 8785 (JCS) |
| Bundle archive format | Standard ZIP (PKZIP, ISO/IEC 21320-1) with deflate compression |
NORA-1 records require a content addressed durable storage backend. The spec defines the required properties (content addressing, public retrievability, deterministic byte retrieval, long term durability) rather than naming specific providers, so new compliant backends can emerge without amending the spec.
As of NORA-1.0.0-rc4, known compliant backends are:
Pinata's free tier and any service requiring authentication for read access are explicitly non compliant for NORA-1 records.
NORA-1 is currently at release candidate 1.0.0-rc4. The spec text is functionally complete; the only blocker for promotion to 1.0.0 is the production of concrete test vectors in Appendix C, which require running a reference implementation. Independent implementers are welcome to begin building against rc4 now.
The spec defines two conformance roles:
A single implementation may satisfy both. Implementations are encouraged to publish a conformance statement listing which checklist items they implement and any deviations.
The NORA-1 specification text is dedicated to the public domain under CC0 1.0 Universal. Anyone may copy, modify, publish, use, compile, sell, or distribute the spec, in source or compiled form, for any purpose, commercial or non commercial, and by any means.
Feedback, corrections, security findings, and implementation reports are welcome via the GitLab project's issue tracker. Critical security findings should be reported privately to the maintainers first.
The full normative text, including all required fields, the cryptographic profile, the recovery procedure, security considerations, and the implementation checklist, is in the GitLab repository.
Read NORA-1.md View the repo