Self-custody often begins as an individual problem: protect a seed, use a hardware wallet and verify transactions. As soon as several people need to manage a treasury, infrastructure or assets belonging to an organization, the nature of the problem changes.
Security no longer depends only on protecting keys. It depends on who may decide, who may execute, who may verify and what happens when the organization changes.
At that point, self-custody becomes a governance problem.
A private key does not define a business role
An organization can run a 2-of-3 multisig and still be unable to explain the responsibilities of each signer.
Holding a key may provide the technical ability to sign, but it does not answer:
- who may initiate spending;
- which amounts require additional approval;
- who verifies the beneficiary;
- who may add or remove a signer;
- who may trigger an emergency process.
Governance begins when cryptographic capabilities are mapped to explicit responsibilities.
Separate request, approval and signature
In a small team, one person may hold several roles. As value and team size grow, separation becomes more useful.
A simple model distinguishes:
- requester, who explains why an operation is needed;
- preparer, who builds the transaction;
- approver, who validates context and policy;
- signer, who exercises cryptographic authority.
Some functions can be combined, but distinguishing them makes it possible to see where control really exists.
Multisig does not automatically provide this separation. Three people can each hold a key while all relying on the same unverified payment request.
Use risk tiers instead of one universal rule
Not every transaction needs the same governance.
An organization can define tiers for:
- routine low-value operations;
- unusual transfers;
- payments to a new destination;
- interaction with a new smart contract;
- signer changes;
- quorum changes;
- emergency operations.
Approval level, verification requirements and delay can change with the risk.
This avoids two extremes: a process so weak that it adds no control, or one so heavy that teams create bypasses.
Quorum design is a governance decision
Choosing 2-of-3, 3-of-5 or another threshold is not only a cryptographic parameter.
The quorum determines:
- how many people can block an operation;
- how many keys can be lost;
- how many people must collude to misuse the assets;
- how the organization operates during holidays or absence;
- how much coordination is required during an emergency.
A very high threshold can reduce abuse risk while increasing availability risk. A threshold that is too low can make separation of power largely theoretical.
The architecture should reflect how the organization actually works.
Plan for signer onboarding and offboarding
Teams change. An architecture that cannot handle that change gradually accumulates risk.
When someone joins the signing process, the organization should define:
- how their key is generated;
- which responsibilities they receive;
- which training is required;
- which information they need.
When they leave, the organization needs to know whether their key should be removed, whether a new wallet is required and which external permissions need to be revoked.
Custody architecture should treat key replacement as a normal system capability, not as an exceptional event that nobody knows how to perform.
Authority exists beyond the treasury wallet
Serious crypto governance does not stop at the main treasury.
Other powers need to be inventoried:
- smart-contract administration roles;
- deployment keys;
- exchange accounts;
- access to dashboards and RPC providers;
- validator or operator keys;
- DNS and domains;
- code repositories and deployment pipelines;
- accounts capable of changing security settings.
An organization can have an excellent multisig while leaving a critical admin key inside a personal browser profile.
Make decisions auditable without exposing secrets
Governance needs a record: who requested the operation, who approved it, the amount, which destination was verified and which policy applied.
That record should never contain seeds, passphrases or other signing secrets.
The useful audit trail documents decisions and evidence of control, not the material needed to sign.
This separation supports incident analysis, process improvement and handover without creating another copy of the keys.
Plan emergency governance without creating a hidden super-key
Normal procedures may be too slow during a real incident. It is reasonable to define emergency governance.
But an “emergency key” controlled by one person can undermine the entire normal model.
An emergency process should also specify:
- activation conditions;
- authorized people;
- required quorum;
- permitted actions;
- duration of the exception;
- post-incident review.
Emergency governance should reduce decision time, not eliminate accountability.
Design continuity beyond today’s team
An organization should remain functional if a signer is absent, a leader leaves or a key person becomes unavailable for an extended period.
That requires backups, but also system documentation, replacement procedures and shared understanding of responsibilities.
For assets with an estate-planning dimension, continuity can also connect with succession. The technical design then needs to integrate with an appropriate legal framework without trying to replace it.
Governance must remain usable
A theoretically perfect system that is impossible to operate will eventually be bypassed.
Maturity means balancing:
- separation of responsibilities;
- operational speed;
- recovery capability;
- level of control;
- enough simplicity that the rules are actually followed.
Crypto governance is therefore not administrative overhead added after security. It is part of security.
Build an architecture that reflects the organization
A custody architecture should reflect the organization’s real responsibilities instead of forcing the organization to fit a default tool.
GLOV Secure supports the technical structuring of access, backups, multisigs and procedures through a non-custodial model. For projects that also need to clarify organization, responsibilities and infrastructure choices, GLOV Consulting can support the broader design process.
GLOV Solutions does not provide legal, tax or financial advice. The objective is to make technical authority explicit, controllable and transferable without delegating custody of the assets.