HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Security & privacy

Which responsibilities remain with us when we choose self-custody?

3 min read

Your organization still needs owners for access, approvals, recovery, staff changes, and incident response. Making these responsibilities explicit is part of the value of a controlled wallet architecture, not a task eliminated by it.

Choose owners, not just settings

Someone must decide who may request transfers, who may approve them, how recipients are checked, and what happens when a person leaves. These responsibilities should not disappear into a general “IT owns the wallet” assumption. A finance team may own the business decision while security owns access review and engineering owns the integration. The arrangement can vary, but the handoffs need to be understandable to the people using the system.

Protect the everyday workflow

Many harmful outcomes begin with an authorized person approving the wrong request, not with an attacker breaking cryptography. Review the asset, network, recipient, amount, and fee information before authorizing. Protect the devices and accounts used for approval, and use the supported procedures for access changes. Keep public records available for investigation without exposing secret material. A clear approval screen and a well-understood operating process complement the wallet’s technical controls.

Prepare for changes and incidents

Document recovery, escalation, and staff-change procedures before they are needed. Decide how the organization will respond to a suspected compromise, an unavailable service, or an unclear transaction result. Practice representative cases in an agreed environment and review what the exercise did not establish. Self-custody provides a control model; it does not outsource the judgment needed to operate it. A business should be able to explain who acts next in a problem without relying on a single employee’s memory.

Illustrative example

Finance owns payment approval policy while security owns credential handling and the agreed recovery procedure.

In plain language

A policy needs a person responsible for it

A policy is a set of rules about what should be allowed, refused, or reviewed. Software can help apply and record those rules, but someone still needs to decide what they mean for the business. Name the owner of the policy, the people permitted to change it, and the person responsible when an exception occurs. An approval should apply to a clearly identified version or request; otherwise a later change can make an old approval misleading. Keep the technical decision separate from the business decision when they are not the same. For example, a proposal may satisfy a configured limit while still needing a budget owner’s agreement. This is not unnecessary bureaucracy: it lets different teams understand the same result without assuming that another team has completed work that is still outstanding. Start with a small, explicit responsibility map and test the handoffs.

In plain language

Share references, not secrets

A public reference helps someone locate a record without giving them control of it. Examples include an Explorer URL, a transaction hash, a record identifier, and the network name. A secret can provide access or signing power and must be handled differently. Passwords, access tokens, recovery material, and private signing shares do not belong in a support ticket, screenshot, chat message, or public log. Even public identifiers can reveal business activity when combined with other information, so share only what the recipient needs. Before sending a screenshot, check for account details, customer names, browser tokens, and unrelated transactions. A request to “verify your wallet” does not justify revealing recovery material. Use established contact channels and the authorized account workflow. Protecting private information is compatible with transparent evidence: the goal is to demonstrate the relevant fact without publishing everything that sits behind it.

Conditions & limitations

Infrastructure does not replace your operational controls or confer compliance, licensing, or protection from every loss scenario.

What to do next

Assign owners and acceptance criteria before starting a wallet pilot.

Wallet evaluation checklist ↗Transfer Compliance ↗