Explicit transaction governance
Roles, destinations, limits and approval paths should be expressed as reviewable operating conditions.
Back to homepageTechnical overview
A policy-led operating layer for digital assets.
Explore the bitgo blueprint for coordinating wallet operations, approval policies, developer integrations and eligible third-party services without obscuring who controls keys, data or regulated activities.
This page describes bitgo's intended architecture and product direction. Exact features, providers, supported assets, service levels and availability exist only when documented in a signed agreement for a specific implementation.
Defined control boundaries
Each implementation should document who generates, holds, uses, backs up and recovers signing material.
Composable integration
Programmatic interfaces can connect wallet, policy and event workflows while preserving implementation responsibilities.
These are architecture principles, not performance metrics, certifications or representations of regulatory, custodial, insurance or audit status. Confirm the delivered controls and responsibilities in the applicable agreement.
Discuss the bitgo blueprintPlatform model
Four layers, one accountable operating model.
bitgo is conceived as software that connects blockchain activity with wallet controls, policy decisions and third-party integrations. The client and every external provider retain the responsibilities assigned to them by law and contract.
Wallet operations
A prospective deployment can coordinate addresses, balances and transaction requests while making key-control boundaries visible.
Policy orchestration
Configurable roles, limits, destination rules and approval paths can translate an operating policy into workflow conditions.
Provider integrations
Adapters may connect eligible external providers for activities they independently contract, authorize and perform.
Application infrastructure
APIs and events can expose selected wallet and policy workflows inside a client's own products and systems.
| Platform object | Operational role | Important distinction |
|---|---|---|
| Workspace | Top-level commercial and technical boundary. | Its legal owner, administrators and data region should be documented. |
| Account | Separated operating unit with users, wallets, policies and history. | It may represent a team, entity, fund or embedded customer. |
| Principal | Identified person or service identity with defined permissions. | Human and machine access should follow least privilege. |
| Wallet record | Asset-specific operational object for addresses, balances, policies and transactions. | Key ownership and network capabilities depend on the selected design. |
| Managed workflow | Coordinated process spanning bitgo and approved external systems. | It does not make bitgo the provider of an underlying third-party service. |
The blueprint does not establish that bitgo or any integration partner is licensed, audited, insured or eligible for a particular activity. Provider identity, responsibility and evidence must be verified for each deployment.
Cryptography and key lifecycle
Signing authority begins with an explicit trust model.
A bitgo implementation can be designed around single-signature, multisignature or threshold-signing patterns where the selected networks and components support them. The final protocol, quorum and control allocation must be documented and tested.
Distributed authorization patterns
Multiple keys or key shares can be assigned to independent control domains so that one component does not necessarily authorize a transfer alone.
- The signer set and normal approval path should be recorded before activation
- Recovery combinations require separate authorization, storage and testing
- Loss or compromise of a sufficient threshold remains a material risk
Key management beyond signing
A complete design addresses generation, registration, protected storage, use, backup, recovery, rotation, migration and retirement.
- HSM, KMS or isolated signer options require implementation-specific validation
- Regional or client-hosted components change the responsibility and threat model
- Compliance depends on deployed controls, evidence, contracts and applicable law
| Dimension | Multisignature | MPC / threshold signing |
|---|---|---|
| Signing material | Multiple independent private keys. | Multiple independently protected shares participate in signing. |
| Network result | The network may observe multiple signatures or contract logic. | The network commonly observes a signature in its standard format. |
| Compatibility | Depends on native or smart-contract multisignature support. | Depends on a reviewed threshold protocol and supported signature scheme. |
| Coordination | Signers may be able to act asynchronously. | Participants normally coordinate during the signing protocol. |
| Trade-off | Authorization is visible but recovery and fees can be chain-specific. | Signature format can be flexible, with additional protocol and implementation complexity. |
Cryptographic design is only one control layer. Authentication, software integrity, protected backups, approval separation and operator discipline remain essential.
Wallet operating models
Choose the control model around the workflow.
Wallet architecture should reflect transaction frequency, key ownership, recovery objectives, network support and the legal role of every participant. bitgo does not assume control of client assets merely by coordinating a workflow.
Connected wallet
Designed for frequent activity with online components, tighter automation and a correspondingly broader attack surface.
Restricted signer
Uses offline or highly restricted signing components where stronger isolation is worth additional operational latency.
Self-managed wallet
The client retains the defined signing material and must operate backup, access, recovery and incident procedures.
External-provider workflow
bitgo may orchestrate data and instructions with an eligible provider selected by the client. The provider's role, asset control and legal obligations remain separate and must be contracted directly or expressly allocated.
Three-tier wallet pattern
An illustrative model separates long-term reserves from liquidity and daily transaction processing.
- Restricted reserve wallet for infrequent, high-control activity
- Standby wallet as a governed liquidity buffer
- Operating wallet for bounded day-to-day transfers
The three-tier pattern is educational, not a universal security recommendation. Thresholds, balances and recovery paths require a documented risk assessment and implementation test.
Transactions, policy and access
From request to confirmation, control stays explicit.
A proposed transaction workflow can move through network-specific construction, policy evaluation, human approval, signing, broadcast and monitoring. The actual sequence depends on the wallet design, asset and agreed controls.
Rules become reviewable conditions
A configured policy layer can evaluate destinations, initiators, value thresholds, velocity, approval counts and authenticated external decisions.
Privilege is scoped to the task
Roles, token scopes, administrator separation, strong authentication and network restrictions can reduce unnecessary authority.
- 01
Build
Construct the network-specific request with destination, amount, fee and required metadata.
- 02
Evaluate
Evaluate destination rules, limits, initiator authority and trusted external policy signals.
- 03
Approve and sign
Route recorded approvals and collect the signatures or shares required by the configured trust model.
- 04
Broadcast or hand off
Submit the signed transaction to the network or hand the approved instruction to the contracted provider.
- 05
Monitor
Track acceptance, confirmation, failure, replacement and reconciliation events.
A policy enforced by one online component may not govern an independent recovery path. Recovery material and procedures need controls at least as strong as the primary path.
Developer infrastructure
Programmable workflows with controlled integration.
The bitgo product direction includes API, SDK, event and optional local-service patterns that can connect an institution's systems to agreed wallet and policy functions.
APIs
A prospective API surface may cover wallet records, addresses, balances, transaction requests, policies, approvals, users and integration status.
Typed client libraries
Client libraries can support request validation, transaction construction, serialization and integration with approved signing components.
Client-hosted gateway
An optional client-hosted service can isolate selected validation or signing operations inside the client's controlled environment.
Webhooks
Authenticated event notifications can signal transaction, approval, confirmation and reconciliation state changes.
Compliance integrations
Where separately agreed, workflows may exchange onboarding, sanctions, blockchain-analytics or Travel Rule data with eligible providers. The responsible party and decision authority must be documented.
- Keep production credentials out of browser code, public repositories and unencrypted configuration.
- Use least-privilege scopes, network restrictions and a dedicated secrets-management process.
- Design webhook consumers for duplicate, delayed and out-of-order delivery.
- Verify message authenticity and use idempotency, durable queues, retry handling and reconciliation.
- Keep test and production identities, credentials, wallets and data strictly separated.
- Validate addresses, amounts and network-specific requirements before requesting a signature.
The integrating organization remains responsible for its application security, data handling, operational controls and correct API use. bitgo's delivered obligations exist only to the extent stated in the applicable agreement.
Ecosystem integrations
Connect workflows without blurring provider roles.
bitgo can be designed to exchange approved instructions and status data with selected third-party systems. Availability, eligibility, execution and legal responsibility depend on the provider, jurisdiction and signed agreements.
Execution connectivity
Adapters may route authorized orders or market data to a contracted venue or broker; bitgo does not become that venue or broker by providing the interface.
Settlement orchestration
Workflow states can coordinate delivery instructions and reconciliation with selected counterparties, subject to their finality rules and contracts.
Collateral workflows
Policies can govern proposed pledges, releases and monitoring data while the relevant parties retain legal and operational responsibility.
Staking connectivity
An integration may submit approved instructions to an external validator or provider; protocol, slashing, lockup and provider risks remain with the agreed arrangement.
Embedded wallet operations
Organizations can use APIs to place selected wallet and policy workflows inside their own experience, with clear end-user disclosures and responsibility mapping.
Stablecoin workflows
Software can coordinate approved mint, burn, reconciliation and reporting steps, but does not itself establish reserves, redemption rights or regulatory approval.
Fiat-system adapters
A connector may exchange instructions with an eligible payment provider. Timing, limits, account treatment and protections are determined by that provider and the applicable law.
An integration is not an endorsement, offer or representation that bitgo provides the underlying financial or regulated service. Confirm each provider, permission, fee, risk and responsibility in writing.
Security and responsibility
Controls require evidence, not assumptions.
bitgo's security model is a design blueprint until a specific deployment, control owner and verification method are documented. This page does not represent a certification, regulatory authorization, insurance policy or independent examination.
Key and signing design
Potential patterns include separated authorization, encryption, isolated signing and HSM or KMS integration where the selected implementation supports them.
People, policy and infrastructure
Roles, approvals, limits, network controls, monitoring and recovery exercises should complement cryptographic safeguards.
Verification before reliance
Clients should review current, scope-specific evidence for every material control or provider claim instead of relying on marketing language.
Responsibility mapping
A written matrix should identify the client, bitgo and each provider responsible for keys, data, approvals, incidents, continuity and legal obligations.
| Area | bitgo blueprint position | Evidence required |
|---|---|---|
| Legal role | bitgo is presented here as policy-led orchestration and integration software. | The signed agreement must identify every service provider and its role. |
| Key control | Control can be allocated among client and selected technical components. | Document the key ceremony, quorum, recovery path and accountable owners. |
| Independent assurance | No audit, certification or examination is implied by this page. | Obtain a current report, scope, period, exceptions and reliance terms where required. |
| Insurance | No insurance coverage or recoverable amount is represented here. | Obtain written evidence of insurer, insured party, assets, events, limits and exclusions. |
| Regulatory permissions | No licence or authorization is implied for bitgo or an integration partner. | Verify the exact entity, activity, jurisdiction and current official register entry. |
Security controls reduce selected risks but cannot guarantee immunity from compromise, loss, downtime, software defects, operator error or third-party failure.
Use cases and limitations
Different organizations, different operating risks.
The bitgo blueprint can inform several digital-asset operating models, but every deployment needs its own technical, legal, security, operational and jurisdictional assessment.
Wallet and treasury operations
Deposit addressing, monitoring, withdrawal approvals, treasury transfers and reconciliation.
Embedded digital-asset workflows
Customer-facing wallet records, transfers, provider connectivity and branded operational experiences.
Policy-led asset operations
Treasury approvals, reporting, wallet segregation, provider handoffs and controlled recovery.
Controlled treasury and distribution
Token operations, vesting, distributions, reserves and protocol connectivity where supported and permitted.
- Key risk: enough lost or compromised signing material can make assets inaccessible or enable unauthorized transfers.
- Client-operations risk: weak access, backups, operator separation or recovery procedures can defeat sound architecture.
- API risk: exposed credentials, poor validation or flawed idempotency can create unauthorized or duplicate activity.
- Blockchain risk: congestion, reorganizations, forks, protocol failures and fee spikes can affect transaction outcomes.
- Smart-contract risk: tokens, bridges and protocol integrations may contain defects outside bitgo's direct control.
- Provider and counterparty risk remains whenever an external organization executes, holds, validates or settles an instruction.
- Compliance risk arises when onboarding, sanctions, Travel Rule, reporting or licensing duties are assigned incorrectly.
- Availability and concentration risk can interrupt operations that depend on one cloud, network, signer or provider.
- Recovery risk includes untested backups, unavailable approvers, obsolete software and unclear emergency authority.
- Market risk remains separate from operational security and can result in substantial or total economic loss.
Before relying on a workflow, confirm the current service schedule, implementation design, provider documentation, supported networks, responsibility matrix and contractual terms.
Important information
This bitgo material describes an intended software architecture for general informational and educational purposes. It is not a specification, service commitment, certification, assurance report, licence, insurance representation or statement that a feature or provider is available. Delivered functionality, controls, supported networks, providers, fees, responsibilities and service levels exist only as stated in a signed agreement. Nothing here is an offer, solicitation, investment recommendation or legal, tax, accounting, cybersecurity or financial advice. Digital assets and third-party integrations involve substantial risks, including irreversible transactions, provider failure and possible total loss.
Design the right operating model
Turn technical requirements into accountable infrastructure.
Discuss the wallet, policy and integration architecture appropriate for your organization, networks and jurisdictions.