​

Integrating Notareum

​

What you get from a basic integration

• A protocol-level “is this address legitimate and at what level” signal that does not require per-partner allowlists.
• Resolution of human-readable aliases (alice.eth-style) to addresses, cross-chain.
• Trusted metadata (issuer name, resource description) for display in recipient-preview flows.
• Revocation awareness: you can instantly stop treating an address as verified the moment the owner revokes.

​

Integration patterns

​

Wallet integration

1. At “paste address” time, resolve the user input against resolveAlias(). If it matches an alias, swap the alias for the canonical address before letting the user sign.
2. Before showing the confirm screen, read getResource(resourceId) for the recipient.
3. Render a verification badge based on verificationLevel:
   • 0 (unregistered): no badge, optionally “not on Notareum”.
   • 0 registered only: neutral badge (“Registered on Notareum”).
   • BASIC: green “Verified (Basic)”.
   • ENHANCED: blue “Verified (Enhanced)”.
   • INSTITUTIONAL: gold “Institutional”.
4. If is_revoked, show a hard red warning and require an extra confirmation.

​

Exchange deposit address display

​

Block explorer integration

• Address page: show verification badge, issuer name, alias.
• Contract page: link to the registering developer, show verification level, flag revoked contracts.
• NFT page: show proof chain back to the creator, NFT-level verification if present.

​

Payment requests

​

Performance tips

• Cache resource info. Registry reads are inexpensive but still RPC round-trips. Cache (resourceId -> ResourceInfo) with a short TTL (for example 60 seconds) and invalidate on revocation events.
• Subscribe to events. Listening to ResourceRegistered, ResourceRevoked, and VerificationApproved events keeps local caches current without polling.
• Batch resolutions. If your UI renders a list, multicall the registry reads. The SDK does not ship a multicall helper out of the box; use alloy-multicall, web3-multicall.js, or Multicall3 directly.

​

Security notes

• Always match proofHash when given a .nota file. If a user sends you a .nota file, serialize it canonically, keccak256 it, and compare to the on-chain proofHash before trusting metadata from the file.
• Treat level 0 as untrusted. Registered-but-unverified resources prove only that someone claimed the identifier, not that it is legitimate.
• Watch the revocation flag on every read. A stale cache that misses a revocation is a live security risk.
• Respect the tier in display. Do not present BASIC as ENHANCED; your users are relying on the signal to be the truth of what on-chain says.

​

Minimum viable integration

async function lookupRecipient(input: string) {
  // Input could be an alias or a raw address
  let resourceId: string;
  try {
    resourceId = await ntm.registry.resolveAlias(input);
  } catch {
    // Treat as a raw address; we still want to try the registry
    resourceId = ntm.registry.computeResourceId(
      /* ResourceType.ADDRESS */ 0,
      1n,
      input
    );
  }

  const info = await ntm.registry.getResource(resourceId);
  return {
    address: input,
    level: info.verificationLevel,
    revoked: info.isRevoked,
    alias: info.alias,
    owner: info.owner,
  };
}

​

Going further

• Use cases for UX-oriented flows.
• Smart Contracts overview for the full ABI surface.
• Security for threat model and operational recommendations.