PROTOCOL DOCS

01 / Protocol overview

BLYND PROTOCOL combines a privacy-token application on Robinhood Chain with an AI conversation workspace. The token ticker is BLYND.

Privacy Wallet

The wallet application connects an existing Ethereum-compatible wallet to Robinhood Chain. It derives stealth keys in the browser, registers public payment keys, and deposits BLYND into a shared privacy pool. A payment can credit pool shares to a fresh, one-time address rather than repeatedly paying the recipient’s main wallet.

Privacy Prompts

The chat workspace provides real, streamed AI responses without a chat-account signup. Conversation history is saved in the current browser. An answer receipt lets you check whether its included answer matches its SHA-256 digest.

02 / Contract architecture

Stealth Registry

The registry maps a wallet address to a public stealth meta-address: a 66-byte combination of compressed spending and viewing public keys. Registration writes public keys on-chain; it never needs the private keys. The supplied registry contract has no owner-only administration. A wallet can register its keys again to update its public entry.

Privacy Pool

The privacy contract holds the underlying BLYND tokens and records shares for each address. Deposits increase backing and issue shares; withdrawals burn shares and return underlying tokens. Stealth deposits credit these shares to a one-time address and publish an announcement. Internal share movement does not require a direct ERC-20 transfer between the two share-holding addresses.

Router

The router combines buying BLYND with depositing it into the privacy pool. Its contract also contains selling and stealth-routing paths. The current app’s buy action deposits shares to the connected wallet, not to a newly derived stealth address.

Token wiring: the app reads the token address from the privacy contract’s zero() getter. It does not use a fixed token address in the interface. Until a token is linked, token-dependent operations cannot be used. Linking requires the token to satisfy the contracts’ Pons launch requirements.

03 / Stealth addresses & keys

The browser implements secp256k1 stealth derivation using an ERC-5564 scheme-1-style construction with a view tag.

1. Spending key: a private key used to derive control of the recipient’s one-time addresses.
2. Viewing key: a separate private key used to recognise payments from their ephemeral public keys.
3. Public meta-address: the two public keys combined and shared with senders. This is not a normal wallet address.
4. Ephemeral key: the sender creates a fresh random secret for a payment and publishes only its public key.
5. One-time address: a shared-secret-derived point is added to the recipient’s spending public key. The recipient can reproduce the secret using the viewing private key and derive the corresponding spending private key.

The wallet signature

“Sign once” asks your wallet to sign the BLYND key-derivation message. Two differently tagged hashes of that signature produce the spending and viewing private keys in the browser. Signing the message itself is not a transaction and does not charge network gas.

Private keys are not registered on-chain. The current page keeps derived keys in browser memory and clears them when the connected account changes. The recovered one-time private key can be revealed in the Receive tab; do not share it or include it in screenshots.

04 / Send & receive

Prepare a receiving identity

1. Open Privacy Wallet, connect your wallet and select Robinhood Chain.
2. Sign the key-derivation message to create your stealth identity locally.
3. Register your public meta-address. This on-chain registration requires ETH for gas.
4. Share your public meta-address with a sender. Never share the signature or private keys.

Send a stealth payment

1. Enter the recipient’s public meta-address in Pay Stealth.
2. Derive a fresh one-time address and select a supported denomination: 1,000; 10,000; 100,000; or 1,000,000 BLYND.
3. Approve the privacy contract to spend the required tokens using your wallet.
4. Submit the stealth deposit. The privacy contract takes BLYND into the pool and credits shares to the derived address.
5. The contract emits an announcement containing the one-time address, caller, ephemeral public key and metadata.

Recover a received payment

The current Receive tab accepts the payment’s ephemeral public key manually. With your locally derived stealth keys, it recovers the one-time address and its private key. Obtain the ephemeral public key from the payment announcement on the explorer.

The contracts include signed share-transfer and withdrawal methods, allowing a third party to submit a valid signed operation and receive a share-denominated fee. That contract capability is distinct from the direct transactions exposed by the current app.

05 / Privacy shares

A privacy share is an accounting unit inside the pool—not BLYND held directly in the one-time address. Your claim on underlying BLYND depends on how many shares you hold relative to all pool shares.

Underlying claim ≈ your shares × total backing ÷ total shares

Deposits mint shares according to the pool’s accounting; withdrawals burn them. The contracts handle integer rounding.

No fixed yield: backing growth depends on market execution and configuration. Holding BLYND outside the privacy pool does not by itself give you a pool-share claim. A higher BLYND claim per share also does not guarantee a higher ETH or fiat value.

The Privacy page reads pool backing, total shares, token supply and an average token-per-ETH price from the configured chain. These numbers are not an audit or a guarantee of future returns.

06 / Privacy Prompts

1. Create a conversation and submit a prompt.
2. The browser sends the prompt and the supplied conversation history to the app’s chat endpoint.
3. The endpoint forwards the messages to the AI Gateway and streams answer text back to the browser.
4. The browser saves the thread locally and creates an unsigned answer receipt when it receives a nonempty answer.

You can stop a response, revisit browser-saved conversations and delete individual threads or all local chat history. Deleting a thread removes the local copy; it cannot retract messages already processed by the endpoint or AI provider.

Private, Enclave and Sealed labels on the homepage are not connected processing modes. The implemented chat uses the AI endpoint, not a selectable enclave or sealed inference service. Network availability, rate limits and available AI credits can affect responses.

07 / Answer receipts

An answer receipt contains a version identifier, timestamp, model label, prompt digest, answer digest, the answer text and a null signature. The browser hashes the trimmed answer using SHA-256.

1. Copy the receipt from the assistant response.
2. Open the receipt verification page and paste or upload the JSON receipt.
3. The browser checks the supported schema and hashes the included answer.
4. A matching digest confirms consistency between that answer and that digest.

The legacy identifier veilium.receipt.v1 is retained so older receipts remain compatible after rebranding.

08 / Network & contracts

Network

Robinhood Chain (Mainnet)

Chain ID

4663

Gas currency

ETH

RPC

https://rpc.mainnet.chain.robinhood.com

Explorer

robinhoodchain.blockscout.com

Configured protocol contracts

These addresses reflect the application configuration. They are not an independent verification of deployed bytecode, token linkage, current balances or ownership. The token address is resolved from the Privacy Pool on-chain rather than listed as a fixed CA here.

09 / Security & limitations

What stays public

Robinhood Chain is a public blockchain. Transactions, calls, addresses, amounts, approvals, timing and announcement data remain observable. Stealth addresses reduce reuse of a recipient’s familiar wallet address; they do not hide the entire transaction graph. Fixed denominations alone do not guarantee anonymity.

Protect access and keys

• Verify the site, network and contract address before approving or signing. Approvals authorize token spending.
• Keep the key-derivation signature, spending key, viewing key and recovered private keys secret.
• A viewing-key leak can compromise payment recognition privacy. A spending-key or recovered-key leak can compromise control of funds.
• Do not put seed phrases, private keys or sensitive wallet signatures into AI prompts.
• Do not rely on browser memory as a durable recovery backup. Understand how your wallet reproduces its signing identity before using it for funds.

Operational and contract risks

Network failures, gas requirements, token setup, liquidity, price movement and privileged actions can affect operations. The current router buy action passes a minimum token output of zero, so that UI action does not provide a user-selected minimum-output safeguard.

Ownership controls are intentional authorized functions, not absent powers. The system should not be described as immune to administrator actions. Reviewing the application source is not a smart-contract audit; this documentation does not establish that an audit has taken place.

10 / Glossary & FAQ

Is a meta-address my normal wallet address?

No. A normal address identifies one account. The public stealth meta-address contains two public keys used to derive many one-time receiving addresses.

Why do I need ETH?

Registering keys, approving BLYND, depositing and other direct transactions need ETH for network gas. A free key-derivation signature does not remove gas requirements for subsequent transactions.

Does receiving mean tokens appear in my main wallet?

No. A stealth deposit credits privacy-pool shares to the derived address. Discovering and controlling that address is distinct from withdrawing its underlying tokens.

What is an announcement?

A public event carrying payment discovery data, including the ephemeral public key. It enables the recipient to derive the corresponding address using their private viewing key.

What is a relayer?

A transaction submitter that sends someone else’s signed operation and may receive a fee. Signed-operation methods exist in the contracts, but the current app does not operate a relayer service.

Does a valid receipt prove the AI answer is correct?

No. A matching hash is not evidence of factual accuracy, trusted authorship or model identity. Check important information independently.

Are my conversations synced across devices?

No. Threads are stored in the current browser’s local storage. Another device or browser has separate history, and clearing site storage can remove your local conversations.