Wallets & privacy
What connecting exposes, what stays in your wallet, and how watch-only access differs from account authority.
In this chapter
Account access, not permission to spend
Connecting asks your wallet to share a public account address and its current network. The present workspace does not request message signatures, token approvals or blockchain transactions.
Browser extensions are discovered through EIP-6963 where supported, with a legacy injected-provider fallback. A wallet’s self-reported name is not proof of its publisher. Wallet icons are treated as images, not executable markup.
WalletConnect is prepared for QR and mobile connections and requires a valid public Reown project ID. The present release requests account access and network add/switch methods. An enabled, verified financial deployment can additionally request optional transaction permission. The application checks the wallet’s actual grant for the selected account, chain and session expiry before sending.
Account and network changes
Switching to Robinhood Chain is a separate, explicit request. If a wallet does not know the chain, Serevin can offer the verified chain configuration and then check the actual selected chain. A successful add-chain reply alone is not treated as a completed network switch.
Account changes, revoked access, disconnections and chain changes update the session. Late replies from a cancelled request cannot silently restore an old account. A permission request remains single-flight while the wallet is still processing it.
The market data client always reads the configured Robinhood Chain endpoint, independent of which network is currently selected inside an extension. The interface distinguishes the wallet’s network from the data source.
The gated financial transaction flow
The capital-services page remains disabled until an explicitly enabled and verified deployment manifest is supplied. Its transaction code prepares named operations against reviewed module and token identities. It shows human-readable amounts, the wallet account, target, spender, current terms and exact approvals before asking a browser wallet to continue.
The transaction engine checks the account, chain, implementation identity and current terms again before sending. It resets a different nonzero allowance before approving the required amount, simulates the final action and verifies its receipt. Receipt inclusion is not a guarantee of finality. Upgradeable code can still change between checking and inclusion.
Pending operations are retained across navigation, and transaction intentions and hashes are checkpointed in IndexedDB before and after wallet sends. A full reload restores the interruption and tabs share the same account/network guard. Recovery checks the original nonce, receipt, account and canonical block; it does not replay saved calldata. A successful, reverted or replaced transaction must be acknowledged before a new review. An unknown send can require its transaction or replacement hash from the wallet.
WalletConnect remains unconfigured in this release. When enabled, financial requests require an actual account and chain permission grant. Local provider, browser-storage and simulated-EVM tests do not establish a real extension or mobile-wallet transaction. Browser storage can be cleared or evicted and does not coordinate another device.
Watch any public address
Watch-only mode lets you inspect a public address without connecting its wallet. It does not prove ownership or authorize actions on that account. A connected user can watch a different address and later return to their connected account.
Responses are checked against the requested account before being displayed. Failed token reads are unavailable, not zero. Position shares remain accounting units and are not shown as guaranteed withdrawable cash.
Data used by this application
The browser stores an appearance preference and, where applicable, the selected wallet connector so it can attempt a silent restoration. It does not store a private key or seed phrase. Restoration uses an account read instead of opening a new permission prompt.
A public address entered or connected for account reads is sent to Serevin’s data endpoint and used in requests to the configured blockchain RPC provider. Hosting and network providers may process request metadata. WalletConnect, when enabled, also involves its provider infrastructure and the selected wallet.
Selecting Compare quotes sends the token addresses and input quantity to Serevin’s server, which requests a Route quote for chain 4663. The Route request carries the server’s network address, not a forwarded browser IP address or wallet address. Route and hosting providers can still process timestamps, quote inputs and other request metadata under their own practices.
The external Route link opens a separate website without prefilled trade or wallet data. If you follow it, Route can receive browser information directly. Connecting or trading there is governed by that service’s wallet flow, privacy practices and terms.
The current code does not maintain an application account database or persistent wallet-history database. That is a description of this implementation, not a promise about retention by an eventual hosting provider, wallet or RPC service.
The dedicated Privacy policy, Terms of use and Risk disclosure are available from the footer and wallet dialog. They are drafts pending operator details and release review. Wallet connection is separate from acceptance of financial terms.
Optional WalletConnect core telemetry is disabled. Its SDK can still retain session and pairing data in browser storage, and provider connection or QR-modal diagnostics may still be processed.
Disconnecting clears the Serevin session and, for WalletConnect, its SDK session. An extension may retain a previously granted site permission until you revoke it in the extension’s own settings.