ChatNode is a peer-to-peer communication network — messaging, voice, video and file transfer — running entirely on participants' own devices. No company server holds messages, there is no account system, and identity is a cryptographic keypair generated on the device.
CHAT is the token used to register .chat names, to pay trading fees on the network's peer-to-peer exchange, and to compensate the independent operators who run the infrastructure that makes discovery and settlement possible.
The ChatNode network is built and running on Windows, macOS, Linux, Raspberry Pi and Android, with an iOS client in development. What follows describes how it works, what CHAT does within it, and what remains to be done.
Mainstream messaging requires you to register with a provider. That provider holds your account, routes your messages, and can be compelled to disclose what it knows or blocked outright. Even where content is encrypted, the provider still knows who talks to whom, and remains a single point at which service can be revoked.
ChatNode removes the provider. There is no account to suspend, no company holding your messages, and no server that can be subpoenaed for their contents — messages are encrypted end to end before they leave your device.
The very first message to someone you have never contacted is carried by a community-run bootnode, because no connection between the two devices exists yet. It is encrypted end to end before it leaves your device, so the bootnode forwards ciphertext it cannot read. From then on the two nodes hold a direct connection and messages travel straight between them, with no third party in the path at all.
That design creates one problem it must solve: if there is no central service, how do peers find each other, and who pays for the infrastructure that helps them? CHAT is the answer to that question.
Every user runs a node. It holds their identity key, stores their messages locally, and connects directly to other nodes — as a desktop application, an Android app, or headless on a server or Raspberry Pi.
On first launch a node generates an Ed25519 keypair. The public half is the peer ID; the private half never leaves the device. There is no registration, no phone number and no email address. Nobody — including the project — can recover, suspend or reissue an identity.
Direct messages are end-to-end encrypted. The conversation key is derived from a static-static X25519 ECDH between the two participants' identity keys, expanded with HKDF-SHA256, and sealed with XChaCha20-Poly1305 using a random 192-bit nonce. Unencrypted messages are rejected rather than displayed, so the protocol cannot be silently downgraded by a hostile relay.
A peer-to-peer network still needs a starting point. Bootnodes are ordinary ChatNode instances on always-on machines with reachable addresses. They help new nodes discover peers, relay traffic between peers that cannot connect directly, carry WebRTC media when no direct call path exists, and write domain registrations to the blockchain.
Bootnodes cannot read the traffic they relay — it is encrypted end to end. They are infrastructure, not intermediaries. Anyone can run one, which is the point: a network whose infrastructure is operated by many independent parties across jurisdictions cannot be shut down by pressuring any one of them.
A purely synchronous network has an obvious gap: a message to an offline peer has nowhere to go. ChatNode closes it without reintroducing a mailbox by making retention a per-message decision by the sender. When a recipient is unreachable, the sender may opt in — for a single message, or for one conversation until revoked — and the ciphertext is queued on the relaying bootnode and pushed when the recipient next registers.
The design constraint is that the storing node must never be able to read what it stores. Enqueuing requires the E2EE envelope prefix and refuses anything else, so a bootnode holds only ciphertext addressed to someone else; since receivers reject plaintext messages anyway, this costs nothing. Entries are deleted on confirmed delivery and swept after a 24-hour TTL regardless, with per-recipient count and per-item size caps to bound the disk a hostile sender can consume.
The known limitation is that a message queues on the one bootnode the sender relayed through. Nodes normally register with all of them, so the recipient usually reaches the holder — but one that only ever reaches a different bootnode will not collect the message before it expires. This is a deliberate trade: replicating queued messages across bootnodes would widen the set of operators holding your ciphertext.
Once you have exchanged messages with someone, they become a contact. Your node keeps a direct connection open to your contacts and re-establishes it whenever both of you are online — so conversations between people who actually talk do not pass through anyone else's infrastructure.
This is deliberately scoped to contacts rather than to everyone on the network. Connecting to every peer you can see would not scale, and would disclose your address to people you have never spoken to. Contacts scale with conversations instead: thirty contacts is thirty connections.
Presence follows from the same connection. If a contact is connected, they are online — observed directly rather than reported by a third party.
Where a direct connection genuinely cannot be established — some mobile carrier networks make it impossible — traffic falls back to a bootnode relay, still encrypted end to end.
Nodes can be configured to accept connections only from an approved list. With at least one peer listed, the node stops relaying through bootnodes and connects directly to the addresses its operator specified — a closed group whose traffic no third party carries or observes. A DNS lookup for bootnodes still occurs at startup before the node determines it does not need them.
Feeds are the network's public broadcast side: a shared directory of live streams, sourced either from an RTSP camera on a node's network or from a webcam in the browser. As with private cameras, the source address and credential stay on the node that publishes the feed.
Today a feed is served directly from the broadcaster to each viewer — every viewer receives their own full-quality copy from that machine. This is genuinely peer-to-peer, and it does not scale. Upstream bandwidth on a domestic connection bounds a feed to a handful of simultaneous viewers, and a broadcaster behind a restrictive NAT may be unreachable regardless of capacity. Both limits are properties of the topology, not of the implementation.
A streamnode resolves them by moving the fan-out to a node provisioned for it. It is the same software in a different role — analogous to a bootnode, but hosting specific feeds rather than aiding discovery. The broadcaster sends one copy upstream; the streamnode, on datacentre bandwidth with a publicly reachable address, distributes it to every viewer. Viewer capacity rises by an order of magnitude, and broadcasters on home or mobile networks become reachable because viewers connect to the streamnode rather than to them.
The broadcaster chooses per feed how it is carried: on their own streamnode at no fee, on rented capacity from another operator, or direct with the limits above. The choice is deliberate rather than automatic — routing a feed through a streamnode means an operator handles that traffic, which is a different trust position from serving viewers directly.
A node can register a .chat name — a short, human-readable identifier resolving to its peer ID, so users can be reached by name instead of a 52-character key. The user pays in CHAT from the wallet built into their node, and the registration is recorded on-chain. This is implemented and working today.
Names are registered for one year and renewed annually at the same $5 equivalent in CHAT. This matters more than the headline price: it makes demand recurring and proportional to the network's active users, rather than a single purchase capped by the total number of nodes ever created.
A lapsed name enters a grace period before being released for re-registration — the model used by conventional domain registrars.
Names are labels, not addresses. Conversations are keyed by peer ID, not by name. If a name lapses and someone else registers it, existing conversations are unaffected — messages continue to reach the same identity they always did, and cannot be redirected by a change in the registry.
ChatNode additionally warns when a name changes hands: if the name a contact was saved under now resolves to a different peer, the conversation displays a notice rather than letting the label quietly disappear. A name that simply lapsed produces no warning; one now owned by somebody else does. This is implemented.
When a node registers or renews a name, a bootnode handles it — submitting and paying for the on-chain transaction from its own wallet. 20% of each registration or renewal, $1 equivalent in CHAT, goes to the bootnode that performed the write.
This reimburses a real cost, creates a reason to run infrastructure the network needs, and distributes tokens to participants rather than speculators. Bootnodes must hold enough ETH to perform registrations; one that runs dry becomes ineligible for selection until funded again, so maintaining a working node is the operator's own interest.
Thin liquidity is a real problem for holders of small or new tokens: selling through an automated market maker means accepting heavy slippage, and for NFTs there is often no pool at all. The usual answer is an over-the-counter trade, which requires finding a counterparty and trusting them to settle.
ChatNode already solves the first half — it is a network of identified peers who can negotiate privately. The second half is an escrow contract:
Orders are gossiped across the network rather than posted on-chain, so listing costs nothing; only settlement touches the blockchain.
Trading fees are paid in CHAT. This is the token's second use, and unlike name registration it scales with trading volume rather than user count. Because requiring a third asset would otherwise add friction, the node's wallet can swap ETH or USDC for CHAT directly, so a buyer never has to leave to source it.
Contract risk scanning. Over-the-counter trading of illiquid tokens is where buyers get defrauded — honeypot contracts that permit buying but not selling, transfer fees that break settlement, and tokens impersonating well-known names. Before a listing is shown, the node examines the contract and surfaces what it finds: whether the source is verified, whether a sell simulation succeeds, whether transfers levy a fee, and how recently it was deployed. Suspicious listings are flagged for manual review.
These checks inform the buyer; they do not certify the asset. A contract can behave differently for different callers, and a token can pass every check and still be worthless. We would rather show a buyer what we found and let them decide than imply a guarantee we cannot make.
To join the bootnode pool, an operator must hold a stake of $500 equivalent in CHAT, locked for as long as they operate. Withdrawing begins a 3-day unbonding period. A bootnode whose stake falls below the threshold becomes ineligible for selection until it is restored.
The stake is a spam and commitment filter, not a security mechanism. It is set low enough that any serious operator — including a hobbyist running a Raspberry Pi — can participate, and is not intended to price out a determined adversary.
The network's security rests on cryptography and on-chain verification: messages cannot be forged without the sender's private key, domain ownership is verified against the blockchain rather than taken on a peer's word, and administrative data is signed.
What the stake achieves is filtering out casual abuse and abandonment. An operator who runs a node for a week and disappears, or who spins up many throwaway nodes, now has capital committed and an exit delay.
Slashing is planned but not implemented at launch. Deducting from an operator's deposit for misbehaviour is the natural extension, and the mechanism is designed to allow it. It is not shipping immediately because it requires clearly defined, detectable offences and a fair adjudication process — an unfair or buggy slash early on would do more damage to operator recruitment than the deterrent is currently worth. Stake size, unbonding period and slashing conditions are all expected to change as the network grows.
Users do not stake, and staking pays no yield.
Sybil resistance is already structural: one domain per node, and domains cost money. A refundable deposit would add nothing to that.
Nor does CHAT pay a return for simply holding it. Any such yield would have to be funded either from the ecosystem allocation — which is inflation, paying holders by diluting everyone — or from registration revenue, which will not support meaningful returns for years. More importantly, it changes who buys the token: from people who want to use the network to people chasing a rate, who leave when a better one appears.
Returns in this system come from providing a service. Operators earn by running infrastructure the network needs — a return on work, not on holding. Mechanisms such as governance, and benefits for long-term holders like discounted renewals or priority on premium names, may be introduced later, funded by revenue rather than issuance.
Domain registration pays operators for a discrete piece of work — one on-chain write. Hosting a feed is different in kind: an ongoing consumption of bandwidth, proportional to how long a feed runs and how many people watch it. It is therefore priced that way, per viewer-minute, settled in CHAT. The arrangement is between the broadcaster and the operator; the protocol does not take a cut of it.
This makes running a streamnode worthwhile on two counts at once: it carries your own feeds for free, and it earns from carrying other people's. That is the same principle as bootnode rewards — CHAT flowing to the people supplying a resource the network needs — applied to a resource that is metered rather than transactional. Feed state is explicit (LIVE / BRB / ENDED) so billing stops when broadcasting does, rather than accruing against a stream nobody is watching.
Demand comes from three sources: users registering and renewing names, recurring annually rather than once per node; trading fees, which scale with volume rather than user count; and — once feeds are live — broadcasters paying for hosting, which scales with bandwidth consumed rather than with either. Distribution goes to operators providing infrastructure. The token settles between them.
The two operator rewards are deliberately different shapes. Domain registration pays a fixed amount for a discrete transaction; hosting pays a metered rate for a continuous resource. Both direct CHAT to participants who supply something the network needs, rather than to holders who do not.
| Allocation | Share | Tokens | Terms |
|---|---|---|---|
| Ecosystem & operator rewards | 30% | 300,000,000 | Released over ~5 years to fund registration rewards |
| Treasury | 25% | 250,000,000 | Development, grants, operational runway |
| Team | 20% | 200,000,000 | 1-year cliff, 3-year linear vest |
| Liquidity | 15% | 150,000,000 | DEX liquidity at launch |
| Strategic partners | 10% | 100,000,000 | Terms subject to agreement |
The ecosystem allocation is the largest deliberately: it funds operator rewards for years rather than months, so the incentive sustaining the network's infrastructure does not depend on registration volume in any single period.
The operator reward model only works where transaction costs are far below the reward. On Ethereum L1, gas for a registration would frequently exceed $1, making operation loss-making. On an L2, costs are cents — leaving the reward as genuine margin.
Adoption: ChatNode is pre-launch. The software is complete and functional but has not yet been deployed to a user community.
The node's attack surface is treated as critical, because every node is exposed to the network by design.
A full review of every remotely reachable code path was recently completed, and everything it surfaced has been fixed and covered by regression tests:
Release binaries are signed with the project's Ed25519 key and verified by every node before installation, so a compromised distribution server cannot push code to the network.
Reviews of this kind are part of the normal development cycle. An independent external audit is planned before public launch — internal review is not a substitute for outside scrutiny.
In progress: forward secrecy. Conversation keys are currently derived from long-term identities and do not rotate. We are implementing a ratchet so that keys evolve per message, which limits what a future key compromise could expose. This is the largest piece of active cryptographic work.
In progress: identity key storage. Work is underway to protect the on-device identity key at rest — optional passphrase encryption, and hardware-backed storage via the Android Keystore where available.
Deploy CHAT and the domain registry to the selected L2. Establish DEX liquidity.
Activate USD-denominated domain pricing, operator reward distribution, and the bootnode staking contract.
Recruit and support independent bootnode operators across multiple regions and jurisdictions, so infrastructure is not concentrated in one place or under one legal authority.
Escrow contract for tokens and NFTs, order gossip, contract risk scanning, and the in-wallet swap. Audited before it touches mainnet — a contract holding user funds is a different risk class from the rest of the network.
Deploy to user communities. Independent security audit. Usability and localisation work.
Stated plainly, because they are real:
This document describes a project in development. It is not an offer to sell securities or an investment solicitation, and nothing in it should be read as financial advice. Token structure and any offering are subject to legal review in relevant jurisdictions.