Skip to main content

DePIN Messaging

DePIN Messaging is Neurai's private, token-gated messaging layer for devices and people. Membership is decided on-chain by holding a DePIN token. Messages travel off-chain through a service node, encrypted end to end, and expire after a configurable time. Nothing about a message is ever written to the blockchain: no fees, no permanence.

Status

DePIN Messaging is experimental and currently available on testnet and regtest only. This documentation describes protocol 2, which is a breaking change from protocol 1. Clients should check that depingetmsginfo reports protocol: 2.

How it works​

Blockchaindecides who takes part&TOKEN holdings and sectionsfreezes and self-revocationsrevealed public keysService nodeneuraid with the pool keykeeps the in-memory poolchecks access on the chainauthenticates every readsigns every replyHolder / clientwallet or deviceholds its own private keyencrypts and decrypts locallysigns requests and messagesreadsJSON-RPCneurai-rpc-proxy · whitelisted DePIN RPCs onlysingle-use signed challenges · replies signed by the pool key · content encrypted end to end
  1. A token owner issues a DePIN asset such as &NEWS and hands holdings to the addresses that may take part. Sections such as &NEWS/GENERAL create channels inside it.
  2. A service node runs a message pool for that token. It verifies on-chain holdings, enforces limits and stores ciphertext for a few days.
  3. A holder encrypts a message for the other holders' public keys, signs it and submits it. Other holders authenticate with a single-use challenge, fetch the ciphertext and decrypt it locally.

Trust model​

PartyHoldsCan doCannot do
Holder / clientIts own secp256k1 keyRead and publish in the pools it holds tokens forAct for another address
Service nodeThe pool keyEnforce access, authenticate readers, sign repliesRead message content, forge a message
RPC proxyNode RPC credentialsWhitelist DePIN RPCs, rate-limit by IPRead, forge or silently alter a reply once the pool key is pinned
Token ownerThe owner token &NAME!Issue holdings and sections, freeze holders, purge the poolRead messages it was not a recipient of

In one sentence: the chain decides who may participate, the holder's key proves identity and decrypts, the pool key authenticates the service, and nothing in between can read, forge or silently alter anything.

Key properties​

PropertyDetail
AccessActive holdings of &TOKEN or any of its ancestors. Frozen or self-revoked holdings do not grant access.
ConfidentialityContent is encrypted per recipient with ECIES (secp256k1 ECDH) and AES-256-GCM. The node stores ciphertext only.
IntegrityEvery message carries a DER ECDSA signature from the sender. Every reply from the node is signed with the pool key.
AuthenticationSingle-use signed challenges. No sessions, cookies or bearer tokens.
PersistenceIn-memory pool, 7-day expiry by default. Nothing is written on-chain.
TransportStandard JSON-RPC on the node's RPC port, usually behind an RPC proxy. There is no separate DePIN port.

What is public and what is not​

  • Confidential: message content, challenge nonces and every reply bound to an address.
  • Public: token names, the section hierarchy, who holds what and which addresses have revealed a public key. All of this is chain data.
  • Visible to the node: the sender, token, timestamp and recipient hashes of a submission. The protocol does not promise anonymity.

Documentation map​

PageRead it when you want to
Tokens and accessUnderstand DePIN assets, sections, freezing, transfer states and how access is computed
Client guideBuild a client or library: pin the pool key, authenticate, read, decrypt and publish
Protocol referenceImplement the byte-exact formats: serialization, ECIES envelope, signatures, limits and error codes
Running a service nodeOperate a pool: indexes, configuration flags, persistence and the optional AI responder

Resources​