RPC Security

The JSON-RPC interface grants full wallet and node control. Default tidecoind binds RPC to 127.0.0.1 and authenticates via a cookie file readable only by the node user. Only change those defaults deliberately, and never publish the RPC port to the open internet without a strong second authentication layer.

Scope: This page is the operational/deployment guide. For command semantics and parameters, see the RPC Reference. For contributor-facing implementation details, see Developers.

Default model

The safest default is local-only RPC with cookie authentication:


server=1
rpcbind=127.0.0.1

Then call RPC locally as the same user:


tidecoin-cli getblockchaininfo

Cookie auth avoids storing a static RPC password in the config file. The cookie file is created inside the network-specific data directory.

Authentication choices

Method	Best for	Notes
Cookie auth	Local `tidecoin-cli`, local automation under the node user	Default and preferred for single-machine operation.
`rpcauth`	Service users, scripted access, remote clients behind a private network	Stores salted HMAC password hash in config instead of plaintext password.
`rpcuser` / `rpcpassword`	Legacy compatibility	Avoid for new deployments because it stores plaintext credentials.

Generate an rpcauth line from the node repository helper:


python3 share/rpcauth/rpcauth.py tidecoinrpc

Add the generated rpcauth=<user>:<salt>$<hash> line to tidecoin.conf, then give the generated password only to the client that needs it.

Bind and allow rules

rpcbind chooses the local address the server listens on. rpcallowip chooses which source IP ranges may connect. A non-local rpcbind is ignored unless rpcallowip is also set.

Local-only:


rpcbind=127.0.0.1

Private subnet example:


rpcbind=10.0.0.10
rpcallowip=10.0.0.0/24
rpcauth=<generated-user-salt-hash>

Do not use rpcallowip=0.0.0.0/0 for wallet-capable nodes. If a deployment requires remote access, put RPC on a private network or VPN and enforce host-level firewall rules.

Command whitelisting

Use RPC whitelists when a service needs only a narrow set of commands:


rpcauth=<generated-user-salt-hash>
rpcwhitelist=monitor:getblockchaininfo,getnetworkinfo,getmempoolinfo
rpcwhitelistdefault=1

When any whitelist is set, be explicit about rpcwhitelistdefault so service behavior is clear during review.

Reverse proxy pattern

If RPC must cross a network boundary, terminate TLS and authentication before traffic reaches tidecoind, and still bind tidecoind to a private interface. A reverse proxy is not a replacement for RPC authentication or firewalling.

Minimum production controls:

TLS at the proxy or VPN layer.
rpcauth, not plaintext rpcpassword.
Source IP allowlist.
RPC command whitelist for service accounts.
No wallet loaded unless the service truly needs wallet RPC.
Audit logs for proxy access and node debug.log RPC errors.

Wallet-risk warning

If a wallet is loaded, RPC can spend funds, export sensitive wallet state, change wallet settings, and create transactions. Treat RPC credentials like private infrastructure secrets. For explorer, indexer, and monitoring nodes, set disablewallet=1.

Quick review checklist

RPC port is not reachable from the public internet.
The node uses cookie auth locally or rpcauth for service users.
Firewall rules match the rpcallowip range.
Service users have whitelisted commands where possible.
Wallet RPC is disabled unless required.
Backups exist before exposing any wallet-capable automation.