Questions, answered

With you. Each wallet is a standard BIP39 hierarchical-deterministic wallet derived from a phrase created in your environment. Before that phrase is stored it is encrypted to your personal encryption keypair, whose private half is protected by a password only you know and, if you turn it on, a private file you choose. The server keeps wallet metadata, the public addresses it needs to watch, and that sealed copy. Nothing else.

No, because there are no spendable keys to take. A withdrawal is only valid once it carries a signature produced on your side, and API keys can prepare and broadcast but can never sign. The worst a breach reaches is metadata: names, addresses, balances and transaction history. That is worth protecting, and it is not your money.

Guveno cannot reset or recover either one, by design. If your recovery phrase is backed up offline you can restore the wallets it derives anywhere, including in a fresh Guveno account. If both the phrase and your credentials are gone, nobody can bring the funds back. Keep an offline backup of the phrase, and of the exact original key file if you enabled that. Copying and renaming the file is fine; editing, resizing or recompressing it is not, because the bytes are the credential.

Through the vault’s key holders page in the dashboard. Someone who already holds the key re-encrypts the phrase to your teammate’s public key on their own device and offers it; the teammate accepts or declines. Until they accept they hold nothing and can sign for nothing. Both halves ask for a second factor, an unanswered offer expires after seven days, and everyone who holds that key is notified once it is accepted. It is a dashboard ceremony on purpose: API keys cannot read, offer, accept or remove key access at all.

Yes. Import an existing BIP39 recovery phrase from the dashboard, the SDK or the CLI and Guveno derives and watches the same addresses you already use. The phrase is encrypted on your device first, exactly like a phrase created here, so importing never shows it to us.

Sign-ups are referral-based for now: enter a referral code and you are in. If you do not have one, ask. Request a demo or email support@guveno.com and we usually send a code the same day. The Developer tier is free once you are in.

Yes. Every paid plan starts with a 14-day free trial. Pick a plan and add a card after signup to activate it, and you get the plan’s full limits straight away. The first charge lands when the trial ends, and you can cancel any time from the billing portal.

No. Everything works point and click in the dashboard: create vaults and wallets, generate deposit addresses, watch balances, request and approve withdrawals. The API, the Node and Python SDKs and the CLI are there when you want to automate, not as a requirement.

Bitcoin, Ethereum, BNB Smart Chain, XRP, Polkadot and TRON today, including ERC-20, BEP-20 and TRC20 tokens such as USDT and USDC. The free Developer tier runs on Bitcoin and Ethereum testnets. Startup covers Bitcoin and Ethereum mainnet, with the other chains available as $49/mo add-ons, and Pro and Enterprise include every chain we support.

A vault is one recovery phrase and the key-management boundary: it decides who can see and sign for what. A wallet is one chain and network inside a vault, derived from that phrase at its own derivation path, so a single vault can hold Bitcoin, Ethereum and XRP wallets at once. An address is one receiving address inside a wallet. Bitcoin wallets usually hold many, account-based chains often need one.

Once the transaction is both successful and deep enough to be final. Being in a block is not enough on its own: a failed or reverted transaction sits in a block too, so we check the chain’s own success signal first and read the amount that was actually delivered rather than the amount someone asked to send. Then we count depth against the tip, using the threshold for that chain: 2 blocks on Bitcoin, 12 on Ethereum, 15 on BNB Smart Chain, 19 on TRON, and a single validated ledger or finalized block on XRP and Polkadot. Blocks close to the tip stay under review until they are past the reorg window.

Because seeing a payment and being able to rely on it are different events. deposit.detected fires as soon as we see the transaction, deposit.confirmed fires once it is final by the rule above, and deposit.rejected fires if it fails or is reorged away. Credit a customer balance only on deposit.confirmed. A transaction that pays several of your addresses, or moves more than one asset, fans out into one event per transfer, so dedupe on the envelope id.

Prepare, sign, broadcast. The server builds an unsigned transaction from the wallet’s public data, you decrypt the wallet secret and sign locally, then you return the signed transaction for us to submit. Each call takes an idempotency key, and a send is made at most once: if the outcome of a broadcast is ever unknown, we reconcile it against the chain rather than sending it again. There is no retry loop anywhere near a signed transaction.

Yes. A member can request a withdrawal without being able to send it, and the request waits for an approver. Approving needs three things at once: a role allowed to send, a key-access grant on the vault being spent from, and team access to the wallet itself. None of the three is enough alone, and owners and admins who can see every wallet still cannot sign for a vault they were never given.

Only if you let it. Give the agent’s API key permission to request withdrawals on the wallets it needs, and not to send them. It can then propose payouts through the API or the Node and Python SDKs, and nothing goes out until a signed-in person approves the request. No API key can approve a request, and what the person approves is exactly what gets signed: the same address and the same amount. A key that is allowed to send can do so without approval, if the machine it runs on can also unlock the wallet with your encryption password or your own key material. Keep an agent on request-only access if you want a person to see every payout.

Yes, and it never needs a key to do it. Receiving addresses are derived from the wallet’s extended public key, which can produce addresses but cannot sign or reveal anything spendable, so an API key can ask for the next address with nobody unlocking a seed. Polkadot is the exception: its derivation needs the secret, so those addresses are created in the dashboard.

Five. Owners have full control including billing and roles; admins do everything except change roles and add owners; members are the day-to-day operators who read their teams’ wallets, generate addresses, request withdrawals and build integrations; viewers read only; and signers hold vault keys and send withdrawals on their teams’ wallets. An invite that names no role joins as a viewer, and the last owner can never be removed or demoted.

Removing them from the company deletes their sealed copies of every vault key, and so does demoting them to a role that cannot hold one. They lose access to the dashboard, the API and every wallet immediately. Be honest with yourself about the phrase itself, though: anyone who held a key could have decrypted and written it down while they had it. If the departure is not amicable, move the funds to wallets derived from a new vault, the same as you would after any staff change with a shared secret.

No. Owners, admins, members and viewers work on every paid plan, with seats included per plan. What Enterprise adds is teams as an access boundary, per-team wallet access and the signer role, for when you want people scoped to part of the organization rather than all of it.

Yes. Every action is timestamped and attributed in the activity log, and it exports for an auditor. Key sharing shows both sides of the exchange. The activity log is included on Pro and Enterprise.

Multi-factor authentication, plus a step-up check on the operations that matter: sharing a key, accepting a key, and other sensitive changes ask for a second factor at the moment you do them, not only at login. Logging in from a device or address we have not seen before triggers an emailed code, you can list and revoke your own sessions, and every sensitive action is written to the activity log.

Revoke it in the dashboard and it stops working at once. A leaked key also cannot sign a withdrawal, because signing needs a secret the server has never had. Scope each key to the wallets and actions it needs, and pin it to an IP allowlist, so a copied key is useless from anywhere else. Key secrets are shown once when created and cannot be retrieved later.

Informally today, with a formal program planned for 2026. Critical findings are paid regardless. Send anything you find to security@guveno.com.

Per organization. Your tier sets a flat base price plus its included resources, meaning wallets, monitored addresses, org members and network access. The Developer tier is free on Bitcoin and Ethereum testnets. Startup covers Bitcoin and Ethereum mainnet with each extra chain at $49/mo, Pro includes every chain, and Enterprise starts at $1,950/mo priced around your requirements.

No. API requests are unlimited on every plan and there is no per-request metering. We count them for your analytics, not for your invoice.

On paid plans, extra wallets bill at $5/mo each and extra monitored addresses at $10/mo per 100, measured from what you hold at the end of each calendar month and invoiced separately. Member limits are fixed rather than billed, and the free Developer tier’s limits are hard caps.

Both. Annual is billed up front and works out about 30% cheaper than paying monthly. Switch whenever you like from the billing portal.

Yes, prorated up or credited down through Stripe. Startup and Pro are self-serve; Enterprise is sales-led, starting at $1,950/mo with limits set with you.