Skip to main content

Registering a Resource

A signed .nota file is self-contained, but it is not discoverable. To make a resource resolvable by anyone, register it on-chain with the NotaRegistry contract. This guide walks through the full flow: derive the resource ID, compute the proof hash, claim an alias, and send the transaction.

What on-chain registration gives you

  • Ownership. The transaction sender becomes the owner of the resource ID and is the only party able to revoke or elevate it.
  • Discoverability. Aliases like alice.eth resolve directly to a resource ID without needing the original .nota file in hand.
  • Verifiability. The proof hash anchors the canonical .nota file content on-chain; any tampering produces a different hash.
  • Revocation. A single transaction flips is_revoked = true, a signal wallets and explorers can treat as terminal.

Prerequisites

  • A deployed Notareum instance with configured contract addresses (see Contract Addresses).
  • An Ethereum account with enough native gas (ETH on mainnet, testnet ETH on Sepolia) to send one transaction.
  • Optional: enough NOTA to pay the alias fee if you want a human-readable alias.
  • A signed .nota file (see Your First .nota File).

The flow

Step 1: Derive the resource ID locally

The SDK can preview the resource ID before you pay any gas:
Resource ID is deterministic: keccak256(abi.encode(resourceType, chainId, keccak256(identifier))). Same inputs always produce the same ID.

Step 2: Compute the proof hash

Hash the canonical .nota serialization:
Store wire somewhere durable, ideally IPFS, so anyone can retrieve and re-hash it to check.

Step 3: Claim an alias (optional)

Aliases must be globally unique. The contract charges a small NOTA fee per alias (see Fee Model). Approve the fee first:
Skip this step entirely if you pass an empty alias string to registerResource.

Step 4: Send the transaction

Once the transaction is mined, the resource is live.

Step 5: Verify from any wallet

Any party, including ones without the original .nota file, can resolve and inspect the record:
If they also have the .nota file, they can keccak256 its serialization and match it against info.proofHash to prove the file has not been tampered with.

Common pitfalls

  • Reverts with AliasAlreadyTaken. Someone else already owns that alias. Choose another or bid on a release in the future (governance-configurable).
  • Reverts with InvalidResourceType. Governance has not added this type ID yet. Use one of the six initial types or sponsor a proposal.
  • Wrong proof hash. Always hash the canonical serialization (serialize()), not the file as you pretty-printed it.

Next step

To attach a trust level to the registration, continue to Requesting Verification.