New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
A recovered Blockchains Manager report about a staking and custody partnership places several activities in one story: operating validators, safeguarding assets, maintaining customer relationships and offering additional financial arrangements. The historical report documents what was published then; it does not establish the firms' current products or status. It does, however, suggest a useful way to read any staking service. Ask who performs each activity, who can authorise each consequential action and which records connect those responsibilities. This new guide develops that method through hypothetical service designs. It does not rank providers, forecast rewards or assume that every service implements the same architecture.
Start with a responsibility map, not a percentage
Imagine a hypothetical service with an application, a custody partner and a separate validator operator. A customer sees one account page, but the displayed experience depends on several organisations and technical systems. The application might handle requests while the operator maintains validator software and another party controls a withdrawal destination. Those roles can be combined in one entity or divided among several. The first task is to identify the actual arrangement rather than infer it from the simplicity of the interface. A single button does not imply a single decision-maker.
Write the responsibilities as verbs: accept a request, hold a credential, operate a validator, calculate an allocation, authorise an exit and deliver a withdrawal. Attach an accountable party to each verb. Then identify the record that demonstrates completion. This produces a practical map that can be questioned. If the service documentation only supplies an attractive rate and a familiar brand, several parts of the map remain unanswered. The missing information concerns how the arrangement works, not merely how much the interface suggests a participant might receive.
Operating a validator and controlling withdrawals are different powers
Ethereum's staking overview distinguishes direct participation from arrangements involving operators, pools and custodial services. Its withdrawal documentation describes the separate role of withdrawal credentials. These distinctions matter because operating the software that participates in consensus is not the same question as controlling where withdrawn funds ultimately go. A review should identify both powers instead of treating possession of any one key as proof of complete control. The appropriate description depends on the implementation and credentials actually used, not on a broad label such as managed or non-custodial.
In the hypothetical service, ask what happens if the validator operator becomes unavailable but the customer still controls the relevant withdrawal authority. Then ask the reverse question: what if the application remains online but a separate custodian will not process the request? The two scenarios expose different dependencies. Documentation should explain the applicable route and prerequisites, including whether any action requires cooperation from another party. Do not assume a fallback exists merely because a different service or a different protocol has one. The map needs evidence for the arrangement being examined.
An allocation record introduces its own accounting layer
A pooled arrangement may combine contributions before allocating results to participants. The protocol-facing activity and the participant-facing accounting are then separate records. A dashboard balance might depend on an allocation formula, a receipt token, an internal ledger or some combination of these. To understand the displayed amount, identify which record is authoritative for the participant's claim and when it updates. A validator's public activity can be relevant evidence without directly proving that a particular account has been allocated the correct share under a service's own rules.
Use a small hypothetical reconciliation exercise. Several participants enter at different times, the operator earns rewards and the service charges a fee. Determine which events change the allocation and which merely change its display. Then introduce a correction to a previous entry. Can a reader reconstruct the result from retained records and the published rules? This is an accounting test, not a reward forecast. It helps reveal rounding, timing and reconciliation questions that can be hidden when an interface presents one smooth balance line for a process involving many separate events.
Liquidity and protocol withdrawal are not interchangeable
A participant may be able to sell a token associated with a staking position without waiting for that position's underlying withdrawal process. Conversely, a service may offer an internal redemption route whose conditions differ from the protocol's own exit mechanism. These are distinct paths. The existence of one does not guarantee the availability, timing or exchange value of another. A complete description should name the action being discussed rather than use instant access as a phrase covering every possible way to leave an arrangement.
For a hypothetical service, draw two exit paths. One transfers the participant's representation to a willing counterparty. The other requests the underlying assets through the arrangement's documented process. List the dependencies of each path, including service availability, counterparties, processing conditions and any relevant queue. Then consider a stressed period when several dependencies become strained together. The exercise should not invent a particular loss estimate. It should show which promise concerns a software mechanism, which concerns another party's performance and which depends on a market remaining available on acceptable terms.
Additional uses add dependencies rather than erasing old ones
The historical partnership report also discusses using assets in other financial arrangements. A general lesson follows without adopting its commercial claims: reusing a position can create another layer of obligations. An asset's involvement in staking does not explain every condition attached to a separate loan, collateral arrangement or trading account. Those relationships need their own records and controls. A service map that stops at the validator layer will miss the additional decisions that can affect a participant's ability to move or recover value.
Consider a hypothetical receipt that is deposited into a second application. The participant now depends on the first arrangement's accounting and exit process as well as the second application's rules. If either changes or becomes unavailable, the combined experience may differ from the experience of holding the receipt alone. Write down the order in which the dependencies must be unwound. This makes the structure intelligible without treating every additional feature as either automatically beneficial or automatically unacceptable. The relevant question is what authority and failure path each additional layer introduces.
Read incidents through the same map
When a service experiences a problem, identify the affected responsibility before drawing a conclusion about the entire protocol. A delayed customer withdrawal, an unavailable dashboard and a validator fault can be different events with different evidence. The responsibility map gives each event a place. It helps a reader ask for the relevant record, such as an allocation entry or protocol-facing event, rather than accept a generic statement that the blockchain is working or staking is broken as a complete explanation of what happened to a particular request.
The resulting method is deliberately concrete. Identify the actors, separate their powers, follow the accounting and describe each exit path. Revisit the map when software, partners or terms change, because the same product name can remain in place while its dependencies evolve. Historical reports can prompt the right questions, but current arrangements require current evidence. A clear staking explanation is therefore a description of responsibilities and boundaries before it is a description of a headline rate: who does what, which record proves it and what must happen for the participant's intended action to complete.
Technical references
From the recovered archive
- Galaxy and BitGo Buddy Up for Crypto Staking Despite Legal Spat · captured 14 February 2025