A crypto business faces an immediate operational problem: how do team members access shared assets, approve transactions, and manage accounts without anyone holding the master recovery phrase? Traditional business models rely on employee accounts within centralized systems, but self-custody requires a different structure. Sharing a seed phrase is not a solution—it defeats the entire purpose of non-custodial ownership and creates liability if any employee misuses or loses access. Yet a wallet that supports only one account per installation becomes unwieldy when a business needs multiple signers, different permission levels, or segregated operational accounts.
Rabby Wallet, available as a browser extension, mobile, and desktop application, includes native support for multiple blockchain accounts within a single installation. This feature, combined with hardware wallet integration and thoughtful account separation, creates a practical framework for small teams to maintain self-custody while enabling collaborative transaction approval and asset management. The structure does not eliminate trust requirements or operational risk, but it does allow a business to avoid concentrating all assets under one person’s recovery phrase or resorting to custodial solutions that reintroduce counterparty risk.
Why multi-account structure replaces shared seed phrases
A seed phrase is a cryptographic master key. Sharing it between two people means that either of them can drain every account, approve any transaction, and recover the wallet on another device without the other’s knowledge. In a business context, this creates a false sense of security: one departing employee or compromised device invalidates all subsequent protections. Insurance, contracts, and post-incident analysis cannot undo cryptocurrency transfers that were signed with the legitimate master key.
Rabby Wallet’s multiple account feature solves this at the architectural level. Within a single installation, a user can create or import multiple accounts, each with its own private key and corresponding public address. These are not subaccounts or aliases. Each account is a complete wallet with its own balance, transaction history, and signing authority. When an employee has their own account within a shared Rabby installation, they do not hold or know the business account’s recovery phrase, nor does the business hold theirs.
The practical consequence is that employee onboarding does not require distributing the master seed. Instead, an employee creates or imports their own account, and the business grants them address-level permissions: for example, authorization to sign transactions from a specific operational account or to receive transfers to designated addresses. If the employee leaves, their account can be removed from the device without affecting any other accounts, and their access to business assets ceases immediately. The business’s own seed phrase remains under whatever custody model the organization has chosen—whether that is a co-founder’s secure storage, a multi-signature setup, or integration with a hardware device.
This separation also clarifies accountability. When a transaction is signed from an account in Rabby, the signature is cryptographically associated with that account’s private key. If employee A signs a transaction and employee B signs a different one, the blockchain ledger records both, and the business can audit which account authorized each action. Shared custody through a seed phrase obscures this distinction; it becomes impossible to prove who initiated a particular transaction.
Setting up separate accounts for operational roles
A business typically needs more than one account even without multiple team members. At minimum, there is often a distinction between a vault account—holding long-term reserves and accessed infrequently—and an operational account used for daily transactions, employee disbursements, and interaction with dApps. Rabby’s multiple account support makes this separation straightforward. The vault account can be accessed less frequently, potentially using a hardware wallet for signing, while the operational account can use a more convenient method.
Consider a team structure with three roles: a founder managing vault reserves, an operations manager handling daily transactions, and a treasurer responsible for gas fee management and multi-chain liquidity. Each person creates their own account within Rabby, and each is assigned to a separate business account—Vault, Operations, and Treasury. The Vault account holds the majority of assets and is configured so that any withdrawal requires two signatures (achieved through multi-sig smart contracts deployed on-chain, not through Rabby itself). The Operations account receives regular transfers from Vault, holds enough liquidity for weekly payments, and is accessible to the operations manager. The Treasury account is responsible for maintaining stablecoins and ETH across multiple EVM-compatible chains to fund gas and optimize trading routes.
When the founder wants to audit the Vault, they open Rabby, switch to the Vault account view, review the assets and recent transaction history, and confirm that all changes are authorized. The operations manager cannot access this account because they do not have the Vault account’s private key—it exists only within the founder’s Rabby installation or, preferably, on a hardware wallet connected to a dedicated device. Similarly, the operations manager can review their own transaction history in the Operations account without being able to see the Vault’s full balance or history.
Gas fee management deserves explicit attention in this structure. Ethereum and EVM-compatible chains require ETH or the native token to pay for transaction execution. Running out of gas in an operational account can halt team activities, while maintaining excessive reserves risks idle capital. The Treasury account becomes the gas management hub: it maintains small reserves of native tokens across all used chains and periodically sweeps operational accounts’ excess assets toward long-term storage in Vault. This reduces the number of separate transfers and consolidates liquidity decisions in one place.
Hardware wallet integration for high-value accounts
A self-custody wallet guide emphasizes that private keys held only in software present a larger attack surface than keys stored on a dedicated hardware device. For a business, the operational impact scales with the account’s balance. If a $50,000 Vault account is compromised through malware, the loss is immediate and irreversible. Rabby supports hardware wallet integration—particularly Ledger and Trezor devices—allowing the Vault account’s private key to remain on an isolated device that signs transactions but does not expose the key to the computer.
The workflow is straightforward: when the vault manager needs to approve a transaction, they connect their hardware wallet to the computer running Rabby, and the wallet displays the transaction for review. The private key remains on the hardware device. Once approved and signed on the device itself, the signed transaction is transmitted back to Rabby and broadcast to the network. If the computer is compromised, the attacker cannot steal the private key because it never left the hardware device. If the hardware device is stolen, the attacker cannot use it without the PIN or passphrase protecting the device.
For a business, this means Vault can be configured to require hardware wallet signature, Operations can use a standard Rabby account on a more accessible device, and Treasury can use either depending on its activity level. An employee who has an Operations account in Rabby but whose private key is also on a hardware wallet they control cannot be forced to surrender assets even if their device is taken. The business’s Vault account remains protected at a different layer. This architecture respects both security (keys are encrypted and isolated) and operational reality (different accounts have different risk profiles and usage patterns).
Transaction analysis and approval workflows
Rabby Wallet emphasizes transaction transparency by analyzing transactions before signing and displaying expected balance changes. For a business, this feature becomes part of the approval process itself. When an employee initiates a transaction—whether it is a payment to a vendor, a swap for gas optimization, or an interaction with a yield protocol—Rabby decodes the transaction and shows what will happen: “Send 5 USDC to address 0x1234…, approve spending of 10 USDC to contract 0x5678…” rather than displaying only a cryptic hex string. An operations manager can review this information and confirm that the transaction matches what was intended.
For higher-value transactions or interactions with unfamiliar smart contracts, the business should establish a two-person approval workflow. This is not enforced by Rabby itself but by business process: an employee drafts the transaction, takes a screenshot showing the decoded preview, shares it with a second team member, and only after receiving explicit approval does the employee sign. The blockchain then records the signed transaction, which can be audited against the approval log. This is lighter than on-chain multi-signature but heavier than single-account management.
Permission review is another layer of transaction safety. Smart contracts often request approval to spend tokens on behalf of a wallet. Rabby identifies these approvals and displays the contract address, the token, and (where analyzable) the expected scope. An employee should never blindly approve unlimited spending to an unknown contract. Instead, review the proposal, confirm the contract address matches the official dApp, and when possible, limit the approval to the amount actually needed. If an employee approves a malicious contract, only the approved token amount is at risk, not the entire account.
Structuring employee access without exposing sensitive accounts
A practical question is: should every employee have Rabby installed on their personal device, or only on shared business computers? The answer depends on the role and the business’s risk tolerance. A founder or treasurer likely benefits from having Rabby on a dedicated, isolated device with strong physical security and minimal other software. An operations manager who makes frequent transactions might use a business-managed laptop with Rabby installed. A contractor who occasionally receives payments might receive funds to an address the business manages separately, with no direct access to Rabby.
When you download Rabby Wallet from official channels and install it on a business device, the device itself becomes a security perimeter. This device should have a strong password, up-to-date operating system, no unauthorized software, and regular backups (though the seed phrase should be backed up separately and securely, not in cloud storage). For high-security scenarios, a dedicated hardware wallet paired with Rabby on a device with internet disabled (except during transaction signing) provides significantly stronger isolation, though it reduces operational convenience.
Another approach is to use a blockchain wallet like Rabby as a signing tool paired with cold-storage hardware or a separate key management system. In this model, day-to-day operations occur in Rabby, but the master account that owns all assets is controlled through a separate, more restricted process. An employee with access to an operational Rabby account can only move funds that have been explicitly transferred to that account’s address. They cannot reach the Vault. This mirrors how a traditional business bank account works: the operations team has spending authority up to a limit, but not the ability to access the corporate reserves.
Onboarding and offboarding procedures
Employee onboarding in a crypto business using Rabby should follow a specific sequence. First, the business defines the new employee’s role and which accounts they should be able to access—Operations only, or Operations and Treasury, for example. Second, the employee creates their own Rabby account, either fresh or imported from a personal wallet they have already secured. Third, the business does not share seed phrases; instead, it assigns the employee’s address or account to the business accounts they should be able to interact with. Fourth, the employee receives training on Rabby’s interface, the business’s approval workflows, and the specific transaction types they are authorized to execute.
Practical onboarding also includes a small test transaction. The new employee makes a transaction with a small amount to a business address under observation. The transaction completes successfully, and the employee and supervisor both verify that it appeared on-chain correctly. This confirms that the employee can actually use Rabby and that the account is properly configured. Only after this test should the employee be given access to larger amounts or time-sensitive operations.
Offboarding is equally important and more urgent. If an employee departs, the business should immediately revoke their access to all shared devices and accounts. In Rabby terms, this means: removing their account from any business device, confirming they no longer have recovery phrases or backup keys, and auditing that they have not transferred assets from operational accounts to personal wallets. If the employee had a personal Rabby account for receiving business payments, the business should direct future payments to a different address. If they co-signed any multi-signature smart contracts or had approval authority over shared accounts, that authority should be revoked on-chain (which may require a transaction initiated by another authorized signer).
For medium to high-value businesses, offboarding should also include a confirmation from the departing employee that they have securely deleted any backups of their personal Rabby account if it was installed on a business device. This is difficult to verify absolutely, but a written confirmation and a device reset can reduce the risk. The employee’s personal hardware wallet should remain theirs, but any business-related accounts should be removed from shared systems.
Multi-chain operations and asset liquidity
Rabby supports Ethereum and EVM-compatible blockchains—Arbitrum, Optimism, Polygon, Base, and others. A business may need to hold assets across multiple chains for different reasons: yield opportunities, partnerships, or reduced fees on lower-cost chains. Rabby’s account view displays assets across all connected chains simultaneously, though each transaction is signed and executed on its specific chain. This means an employee can see total business liquidity but must remember that moving assets between chains requires a bridge or swap, which introduces additional fees and execution risk.
For the Treasury account, this multi-chain visibility becomes a significant operational tool. The treasurer can see that the business holds 100 USDC on Arbitrum, 50 USDC on Optimism, and 200 USDC on Ethereum Mainnet, all within a single account balance view. When an operations manager needs 60 USDC on Polygon to make a payment, the treasurer can authorize a cross-chain transfer—or more likely, direct the operations manager to swap assets available on Polygon rather than paying bridge fees. This decision-making is difficult without a multi-chain wallet view, making Rabby’s interface more than just convenience; it becomes a tool for cost optimization.
The risk in this setup is that an employee might assume that a transaction on one chain has the same finality as another. Ethereum Mainnet has higher gas costs but very strong security finality. Arbitrum has lower costs and strong security through Ethereum’s consensus. A newer EVM chain might offer different trade-offs. When structuring team permissions, the business should be explicit about which chains each account can use. The Operations account might be restricted to mainnet and established L2s; riskier or experimental chains might require explicit Vault approval before assets are moved there.
Auditing, record-keeping, and regulatory clarity
One often-overlooked advantage of a blockchain wallet structure like Rabby is that all transactions are permanently recorded on-chain. There is no hidden ledger or corporate account statement to subpoena. When a government agency or auditor asks how the business used crypto, the answer is: the address is public, every transaction is immutable, and you can inspect it yourself at any time. This transparency can simplify compliance in some contexts—particularly if the business is holding assets, not trading frequently or operating a protocol.
A business using Rabby should maintain parallel records: a ledger or spreadsheet noting which account holds which assets, the business purpose of each transaction, and the date it was executed. This is not for Rabby’s benefit or privacy; the blockchain already records everything. It is for the business’s own audit trail, tax filing, and legal clarity. When the treasurer pays an employee 10 ETH from the Operations account, the business should log: “2024-01-15, Operations, 10 ETH to Employee A [address], salary distribution.” If a tax authority asks later, the business can produce both the on-chain record (immutable and verifiable) and the internal ledger (showing the intention and authorization).
Different jurisdictions have different requirements, and a crypto business should consult a lawyer familiar with local regulations. Some jurisdictions treat self-custody wallets the same as personal wallets for tax purposes; others have specific rules for corporate crypto holdings. A multi-account Rabby setup does not affect the underlying legal classification, but it does make accounting clearer: Operations is its own profit-and-loss unit with a clear address and transaction history. Vault is the corporate treasury. Treasury is the optimization and liquidity layer. Each has a defined purpose and can be audited independently.
Frequently asked questions
Can multiple team members access the same Rabby account?
Multiple people cannot safely access the same account because they would all need the same private key or recovery phrase, creating uncontrollable custody risk. Instead, each team member should have their own account within Rabby or within their own installation, and the business should grant them access to specific business accounts based on their role. This maintains individual accountability and prevents any single employee from unilaterally controlling all assets.
What happens to a business account if an employee with access leaves?
The account itself is unaffected as long as the business retains control of the private key or recovery phrase. If the employee had access through their own Rabby installation, remove their device’s access or change permissions on-chain. If they had a copy of the business account’s recovery phrase, treat it as compromised and transfer assets to a new account with a fresh seed phrase. For accounts secured with hardware wallets, the business retains the device and the employee’s departure does not affect ownership.
Should a business back up multiple Rabby accounts in the same location?
No. Recovery phrases for different accounts should be backed up separately and stored in different secure locations. If one location is compromised, only the accounts backed up there are at risk. A Vault account’s recovery phrase should be in a safety deposit box or physical vault. An Operations account might be backed up in a separate secure location. This compartmentalization means a single theft or breach cannot drain all business assets at once.
Views: 0
