The goal is not to hide Bitcoin wallet mechanics behind a hosted account. The interface keeps the wallet structure visible while keeping common actions close at hand.
Accounts first
The left rail is the primary orientation point. Accounts are presented as wallet subdivisions rather than as separate products or asset portfolios. Selecting an account changes the balance and working context in the main panel.
The hierarchy is intentionally compact: account name, Bitcoin balance, local-currency reference value, and the available wallet actions remain visible without a trading-style dashboard.
What an account represents
In the ArcBit model, an account is a practical grouping for wallet activity. It can help separate uses, identities, or workflows while remaining within a Bitcoin-only wallet experience.
Sending Bitcoin
The send view follows the old ArcBit pattern: a destination field, Bitcoin amount, local-currency reference amount, and a separate review step before a payment is finalized.
- Enter or paste a Bitcoin destination.
- Set the amount in Bitcoin.
- Use the fiat field as a reference display where supported.
- Review the payment before any final signing or broadcast step.
Receiving Bitcoin
The receive area is intended to surface wallet-controlled receiving information without turning the experience into an account-registration flow. Privacy-minded address handling was part of ArcBit's historical design language, so receiving is treated as a wallet operation rather than a hosted service feature.
History and activity
History gives the user a transaction-oriented view of wallet activity. The purpose is verification and review: what moved, in which account context, and when, not portfolio analytics or market performance.
Watch-only workflows
Watch-only support separates visibility from spend authority. A wallet can monitor relevant Bitcoin addresses or account information without keeping the corresponding spend keys in the active wallet environment.