Tokens and Access

Everything that decides who may take part in DePIN Messaging lives on the Neurai blockchain. This page describes DePIN assets, sections, the owner's controls and how a service node computes access from them.

DePIN assets

A DePIN asset is a Neurai asset whose name starts with &:

Kind	Name	Rule
Root asset	&NAME	NAME matches [A-Z0-9._]{3,}
Section	&NAME/SUB, &NAME/SUB/SUB	Each component matches [A-Z0-9._]+
Owner token	&NAME!, &NAME/SUB!	Issued together with the asset, one per asset

Holdings are whole units (0 decimals). Other asset kinds (qualifier #, restricted $, unique, message channels) cannot be used as DePIN tokens.

Soulbound by default

DePIN assets are soulbound: a holder cannot transfer them. Only the owner token can move them. The single exception is that a holder may burn its own holding with selfrevokedepin.

Creating a section &NAME/SUB requires the root owner token &NAME!. Issuing a section hands &NAME/SUB! to the receiving address, so a root owner can delegate a branch to someone else.

Sections

Sections are hierarchical channels inside one token:

&NEWS
&NEWS/GENERAL
&NEWS/GENERAL/SPORT
&NEWS/ALERTS

A request for &NEWS covers the whole subtree. A request for &NEWS/GENERAL covers that section and its descendants, but not its parent or its siblings. Section names are public chain data: sections protect content, not membership.

Active holders

An address is active for an asset when all of the following hold:

1. It has a positive balance of the asset.
2. It has not been frozen by the owner for that asset (freezedepin).
3. It has not self-revoked for that asset (selfrevokedepin).

Restrictions are per (asset, address) pair.

Access is inherited downward

An address has access to a token when it is active for that token or for any ancestor:

An address frozen in &A/B but active in &A keeps access to &A/B, because the root grants the branch. A holder of only &A/B has no access to &A or to &A/OTHER.

Owner access works the same way over owner tokens: an address has owner access to a token when it holds that token's owner token or the owner token of an ancestor. Owner access is what allows purging a pool.

The pool root

A service node serves one pool root (its -depinmsgtoken) and the subtree below it. Ancestors above the root are outside the pool: holders of &A are not recipients of a pool rooted at &A/B, and recipient discovery stops at the root.

Owner controls

Action	RPC	Effect
Issue holdings	issue, transfer from the owner	Grants membership
Freeze an address	freezedepin "&NAME" "address"	The address becomes inactive for that asset
Unfreeze an address	unfreezedepin "&NAME" "address"	Restores the address. Also undoes a self-revocation
Purge messages	depinclearmsg with an admin challenge	Removes messages from a section or the whole pool

A holder can leave on its own with selfrevokedepin "&NAME". The holding stays at the address but is marked invalid. Only the owner can undo it.

Transfer states

The owner decides whether holders may pass their tokens on. Each DePIN asset is in one of three states, reported as transfer_state by getassetdata:

State	Holders can transfer	Who can change it	Notes
Closed	No	Owner, with opendepin	Default. Soulbound: only the owner token moves the asset
Open	Yes	Owner, with closedepin	Holders move the asset like a regular asset. Frozen and self-revoked addresses still cannot transfer
Sealed	No	Nobody	Reached from closed with sealdepin. Irreversible: no further open, close or seal is ever accepted

State changes take effect from the block after the one that confirms them. When a close confirms, pending holder transfers are dropped from the mempool.

warning

sealdepin cannot be undone. An open asset must be closed first, and once sealed it stays owner-only forever.

Revealed public keys

Every cryptographic operation that targets an address needs its public key, and the chain only exposes a hash of it until the address spends at least once. The node keeps an index of keys recovered from spends (-pubkeyindex).

An address that has never spent:

• cannot be a recipient, because there is no key to encrypt for;
• cannot authenticate, because the node encrypts the challenge for its key;
• cannot publish, because the node verifies the message signature against its key.

Clients should treat "address has not revealed its public key" as an expected condition and tell the user to spend once from the address.

Only P2PKH addresses backed by compressed secp256k1 keys can authenticate or receive messages.

Query RPCs

All of these are public, cacheable and need no authentication:

RPC	Returns
checkdepinvalidity "&NAME" "address"	has_asset, amount, valid (1 when active), blocked
listdepinholders "&NAME"	Every holder with its valid flag
listdepinaddresses "&NAME" (count) (start)	Holders that have revealed a public key: address, pubkey, valid
getpubkey "address"	pubkey, revealed, height, txid
depingetancestorrecipients "&NAME/SUB" (max) ("stop_at")	Active holders with revealed keys across the ancestor chain, used to build the recipient list
getassetdata "&NAME"	Asset details including transfer_state

Example: setting up a token

# Issue the root asset. The owner token &SENSORS! is created with it.
neurai-cli issue "&SENSORS" 100 "Nowner..."

# Open a section and hand its owner token to a team address.
neurai-cli issue "&SENSORS/FLEET_A" 50 "Nteam..."

# Give one unit to each device address.
neurai-cli transfer "&SENSORS/FLEET_A" 1 "Ndevice1..."

# A misbehaving device loses access without touching its balance.
neurai-cli freezedepin "&SENSORS/FLEET_A" "Ndevice1..."

# Check what the service node will see.
neurai-cli checkdepinvalidity "&SENSORS/FLEET_A" "Ndevice1..."

Each device address must spend once so that its public key is revealed before it can receive or send messages.