Wallets & privacy

Account access, not permission to spend

Connecting asks your wallet to share a public account address and its current network. Connection alone does not spend funds. A separate reviewed lending or rewards operation can ask for an exact token approval and a blockchain transaction.

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. Browser extension wallets are the active connection option. QR and mobile setup is deferred. When configured, WalletConnect requests account access, network methods and optional transaction permission for independently released lending or rewards features. 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

Direct Morpho actions are enabled by a separate external-lending manifest. Serevin credit, treasury and membership remain gated by their own deployment release. The transaction code prepares named operations against reviewed contract 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.

Public wallet and market reads do not create a saved portfolio or account history. Explicitly signed project proposals use a separate Cloudflare D1 metadata store. Proposal owners can read their submissions and the two reviewers can read the review queue. Provider logs and the separately configured portfolio service have their own retention.

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.