Skip to main content

Using the public network RPC

The dig RPC is the public read interface for the whole DIG Network. The reference node is:

https://rpc.dig.net

It is open, credential-free, and CORS-enabled (*) — any client, from a browser page to a CLI to another node, can call it directly. There is no API key and no account. Visiting it in a browser (GET https://rpc.dig.net/) returns a short intro page linking back to these docs; the interface itself is JSON-RPC 2.0 over POST (see Methods).

Point a client at it​

Any read is one POST:

# liveness + advertised methods
curl -s https://rpc.dig.net -X POST -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"dig.health"}'

# read a resource by retrieval key (sha256 of the URN), pinned to a generation root
curl -s https://rpc.dig.net -X POST -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"dig.getContent",
       "params":{"store_id":"5b1f…e9","root":"latest","retrieval_key":"9f23…c1"}}'

In JavaScript, the DIG read-crypto client derives the retrieval + decryption keys from a URN and talks to the RPC for you — set the endpoint with VITE_RPC (defaults to https://rpc.dig.net) and call readByUrn(...). Every read is verified against the on-chain root and decrypted in your process; the node only ever sees a hash.

What it serves​

Endpoint roleMethod(s)
Resource ciphertext + inclusion/execution proofsdig.getContent, dig.getProof, dig.getProofStatus
Whole capsule (.dig)dig.getCapsule
Public discovery manifest / store metadatadig.getManifest, dig.getMetadata
Generation listdig.listCapsules
Service discoverydig.health, dig.methods

Portability: any node, same answer​

Content is addressed by chain-anchored identifiers (store_id, root, retrieval_key), not by host. A URN resolves to the same bytes at any node that hosts the capsule, and every byte is verified against the on-chain root client-side — so the node is never trusted and you can switch nodes freely. Use dig.methods to confirm a third-party node implements what you need before relying on it.

tip

To clone, pull, or push a whole store (not just read resources), use the git-style dig:// remote — the same nodes, addressed as dig://[<user>@]<host>/<storeId>, with per-request identity-key auth. You can also self-host an origin with digstore serve.

Operating your own node​

Because reads are blind and verified client-side, anyone can run a conformant node and join the network's read path. A node:

  • speaks JSON-RPC 2.0 over POST at a single HTTPS origin and answers CORS preflight;
  • implements the method set above with the documented semantics;
  • serves sealed ciphertext + a root-anchored inclusion proof, and only real execution receipts;
  • answers every miss with an indistinguishable decoy (never an existence oracle).

See Conformance & Security for the full contract.

Rate limits and fair use​

Reads are cheap and uncached at the RPC layer; a node operator may throttle abusive callers by IP or volume (a throttle is an HTTP-level rejection, never a JSON-RPC error tied to a store or key). Generating a ZK execution proof is expensive and is gated on the control plane (hub.dig.net/v1), not triggered from the public RPC — the RPC serves the resulting receipts read-only.

note

rpc.dig.net is operated by DIG Network as the reference node. The protocol is open: the same client works against any conformant node.