Documentation

Learn how Medusa Custody™ organizes accounts, collects approvals and follows operations through governance. These articles are public; you can read them without signing in. They describe the path a team can rehearse on a test network: who proposes an operation, who must approve it, how that approval is recorded, and how a Bitcoin RGB transfer differs from a Bitcoin payment. Reading them does not open a workspace, enable a network, or grant a signing identity.

Create an organization and a Bitcoin account. Follow an unsigned request from submission through device or browser-extension approval to the pending account view. The walkthrough stays on a Bitcoin test network and stops when the account is ready to inspect. It does not issue an asset and it does not move coins.

Understand Bitcoin RGB wallets, why asset transfers need more than a Bitcoin transaction, and how to prepare a small test transfer and a useful backup. The guide is about the protocol and a careful rehearsal. It does not assume that RGB operations are enabled in a Medusa Custody™ workspace.

See how an operation is submitted, signed by one approver or several, and recorded, and how that history rejects a replay or a rewind. One page follows the operation from an editable draft to a recorded result. The other page explains why a repeated delivery is not a second approval, and why a shorter or replaced history stops the governance service.

Start with Getting Started if you want the concrete path: an organization, a Bitcoin account request, and the difference between storing that request and adding your own signature. Then read how governance handles an operation. That page is the same path described for any governed change, including who must sign and what happens after the policy is satisfied. Read the history page next. It is short on procedure and specific about the two checks that sit under the record: a repeated change is not recorded again, and a history that no longer matches its saved tip stops the service.

Read the Bitcoin RGB guide when the question is an asset rather than the account that holds bitcoin. A confirmed Bitcoin transaction is not, by itself, evidence that an RGB transfer was valid or received. The guide explains the receive request, the client-side data that travels with the transfer, and the backup that a recovery phrase does not replace. You can read it before or after the account walkthrough. Creating the account does not create an RGB asset.

Each page stands on its own. The links at the end point at the other public pages, not at a private runbook. A subscribed workspace can have longer technical articles on the same subjects. Those articles are not part of this public set. If a title is absent after you sign in, it is not assigned to the selected workspace. The absence is not a broken link, and opening a public page does not reveal the missing one.

You can learn the names the product uses. A workspace brings people together. An organization groups accounts and carries the approval rule. An account is where the ledger activity is requested. An operation is the proposal to create something, move value, or change who may approve later work. A signature is an approval by an eligible identity. A login confirmation on a phone confirms a sign-in. It is not that signature.

You can also learn the limits of a public page. These guides do not certify a deployment, insure funds, or promise that every network and every module is available. Medusa Custody™ is in beta. Bitcoin paths described here are for a test network unless your own workspace says otherwise. A button name in a guide matches the product. It does not lower the number of approvals the policy still requires. The same key in a browser extension and on a phone is one approver, not two.

Use the pages as a briefing before a rehearsal. Agree which workspace you mean, which organization will own the account, which identities are eligible, and whether one approval is enough or several people must sign. Then follow Getting Started on a test network with a small request. If an action is missing, ask the workspace administrator. The guide cannot enable it. If the result fails, read the change and the error before you retry. A second copy of a change the governance service has already accepted is not a second approval.

Keep the rehearsal small enough to talk through. Name the organization, the account, and the Bitcoin test network out loud before the first signature. Decide who will use Submit, leaving their own signature off the stored request, and who will use Sign & Submit from the browser extension. Write down the contract identifier only when the rehearsal moves on to an RGB asset, and only from the wallet that created it. When the visible result matches the request, stop. The public pages have done their job when the team can point at the preview, the approvers, and the recorded outcome without opening a chat log.

Sign-in does not change these five pages. It can show further documentation assigned to the selected workspace, including a longer technical account of governance and of the history checks for a subscribed workspace. Application permissions, enabled modules, and networks remain separate from the ability to read. If the extra titles are not listed, the assignment is not there. Contact the workspace administrator rather than treating a public guide as a grant.

Sign in to view additional documentation available to your account and company workspace. Application permissions, enabled modules and networks are configured separately.