Choose a method
Pick a supported Neurai RPC method from the explorer below, such as getblockcount.
OPEN BLOCKCHAIN ACCESS
One endpoint.
Neurai at your command.
A safe HTTP gateway to the configured Neurai node. Send a whitelisted JSON-RPC request, and the proxy queues, forwards and caches it for the current block.
QUICK START
How the RPC works
The proxy accepts an RPC method and its parameters, checks its allowlist, then calls the configured node. Reads that are safe to cache are retained only until the next block.
Send JSON
POST an object containing method and a params array to the configured endpoint.
Use the result
The response is JSON in the form { "result": … }. Unsupported methods are rejected before they reach the node.
REQUEST EXAMPLES
Call the node from anywhere
Replace nothing: both examples use the endpoint configured for this deployment.
cURL
JavaScript / fetch
DEPIN ON TESTNET
DePIN messaging, explained
An off-chain, encrypted message pool whose membership is decided on chain. Every call is a regular whitelisted RPC through the endpoint above; nothing here needs a special URL.
Access flows down the tree
A DePIN token is the pool root; its sub-assets are sections. Holding a token opens that section and everything below it — never a parent, never a sibling.
- holder of
&NEWS· whole pool - holder of
&NEWS/GENERAL· its branch - holder of
&NEWS/GENERAL/SPORT· one section
Sections are sub-assets
The node serves one pool root, such as &NEWS. Each sub-asset under it is a section; the hierarchy, who holds what and which addresses have revealed a public key are all public chain data.
Membership is soulbound
A holder cannot transfer a DePIN token; only the owner token issues, freezes or revokes. Losing the token means losing access, instantly, without anyone having to revoke a key.
Content is encrypted per recipient
A message is encrypted once and its key wrapped for every active holder of the section and of its ancestors. The node stores ciphertext it cannot open; the recipient set is fixed when the message is sent.
Every reply is signed by the node
The node signs each reply with its pool key (poolsig). A client pins that key on first use and verifies replies locally — it never has to trust the proxy in between.
Discover
Read the pool identity and its section names. Public, unauthenticated, signed by the node.
depingetmsginfo · depinlistsectionsProve the address
Sign a timestamped request with your own key and receive a single-use nonce, encrypted so only you can read it. Sign the nonce.
depinchallengeRead your branch
Nonce + signature unlock the messages of a section and its children. Each reply chains the next nonce, so one proof serves a whole session.
depinreceivemsgPublish
Resolve the recipients up to the pool root, encrypt and sign locally, wrap the result for the pool key and hand it in. The node checks, stores, and never reads it.
depingetancestorrecipients · depinsubmitmsgSame POST, same endpoint
Who holds what
- The holder keeps its private key. It signs requests, decrypts replies and encrypts messages locally; the node never sees it.
- The node holds the pool key: it opens submission envelopes, enforces access from chain state and signs every reply.
- This proxy whitelists the
depin*methods and rate-limits them per origin IP. It sees neither keys nor plaintext.
Client-side cryptography (signmessage-compatible signatures, ECIES) is implemented in DePIN-Messaging; the byte-exact contract lives in the node repository (doc/depin-messaging-protocol.md).
METHOD EXPLORER
Explore the allowlist
Method help is supplied by the configured node, so its arguments stay aligned with the running node version.
Select a method to view its node help.