Staking providers in Europe and the models they sell

Native staking means the institution runs its own validator: it holds the keys, operates the infrastructure and takes both the full reward and the full operational risk. Staking as a service means a provider operates the validator while the institution's assets back it, which splits the operations from the ownership. Delegated staking means the institution delegates to a validator on a network that supports delegation, with the assets staying in the holder's own wallet and being locked there and never moved.

Liquidity pool staking pools assets from many holders into shared validators, which lowers the minimum stake and introduces a pool operator. Liquid staking issues a token representing the staked position, which can then be traded or used elsewhere while the underlying stays locked. Each step down that list adds a party and removes direct control, and the yield differences between them are smaller than the legal differences. The mechanics of the underlying consensus are on crypto staking, and the revenue and penalty side on validator economics.

In native and in delegated staking the institution holds the keys that control the assets. Delegation on networks that support it is a message authorizing a validator to use the stake's voting weight; it does not transfer the assets, and the holder can undelegate. In staking as a service with a custodial provider, the provider holds or controls the keys during the arrangement, which makes the institution a creditor of the provider in an insolvency instead of an owner of an asset.

That distinction is the one an institution should be able to answer from its own contract in one sentence. Where the keys sit with a regulated custodian the arrangement looks like other custody, and the crypto custody in Germany page covers the German licensing. Where a provider holds keys without a custody authorization, the institution is relying on a counterparty with no regulated segregation behind it.

MiCA does not list staking as one of its crypto-asset services, so there is no staking authorization to apply for. ESMA's question and answer on the subject reads Article 70(1) as barring a provider from staking client assets for its own account, with staking as a service permitted where the client agrees and the profits do not go to the provider alone. The activity is caught through the services it involves, and the trigger is control: a provider needs CASP authorization for custody and administration when it holds or controls client assets during the arrangement, when it executes the bonding and unbonding transfers on a client's behalf, or when it issues a token representing a staked position.

A genuinely non-custodial validator that never holds client assets and issues no token can fall outside MiCA's direct scope, and whether it does is a case-by-case assessment by the national competent authority. For a custodial provider, Article 70 requires segregation of client holdings with separate records and the provider bearing liability for them, and Article 75 requires positions arising from staking to be entered in the client's portfolio with the corresponding transactions reported. An institution should expect to see both in the statements it receives. MiCA in Europe covers the regulation and the CASP license the authorization itself.

Before an institution contracts, it checks the provider's authorization status in ESMA's public CASP register, which lists authorized entities by name and country and also lists entities flagged as non-compliant. The register is published as downloadable files and updated regularly, which means the check can be automated into a vendor onboarding process instead of being a screenshot in a file.

Authorization is granted by the home member state's national competent authority, and the application runs over several months, so a provider that describes itself as being in the process is in a different position from one that is listed. The due diligence around the register entry is the ordinary vendor set: the AML and KYC program, DORA compliance for ICT resilience, a data processing agreement for GDPR, and the segregation and incident arrangements. The DORA regulation in Germany page covers the resilience part.

German supervision looks at what the provider actually does with the assets, and not at the word staking. A custodian offering staking has to assess whether it is providing the crypto-asset transfer service under MiCAR, because the bonding and unbonding steps move assets through smart contracts, and that assessment decides which permissions its authorization needs to cover.

The practical consequence for a German institution is that its provider's permission set has to match the steps the provider will actually perform, including the transfers. A provider authorized for custody but not for transfers, which then executes bonding on the client's behalf, has a permissions gap that becomes the client's problem in a supervisory review. The question to the provider is therefore which specific services its authorization covers, not whether it is authorized.

From the institution's own position the two arrangements fail differently, and that is what belongs in the risk assessment. In a non-custodial delegation the institution keeps the keys, so an operator's insolvency costs it the rewards and the time to redelegate, and the assets are never at stake. The exposure is the operator's performance: downtime costs rewards, and a slashable fault by the operator can cost part of the stake, which is why the correlation penalty discussed on validator economics matters when choosing how many operators to use.

In a custodial arrangement the institution has a claim against the provider. Segregation under Article 70 is what is meant to make that claim good, and the quality of the segregation, the record-keeping and the auditing is therefore the thing to examine, not the yield. Both arrangements need the provider's slashing cover terms in writing, because a promise to cover slashing is worth what its exclusions permit.

Two providers Finance Loop covers sell different things under neighboring words. Blockdaemon operates node and staking infrastructure for institutional clients across many networks, so it is the operations supplier in the staking-as-a-service shape. Tangany is a German crypto custody provider, so what it sells is the regulated custody, with the staking arrangement sitting on top of that custody relationship.

The difference matters when reading a proposal. An infrastructure operator and a licensed custodian answer different questions about key custody and insolvency, and an institution comparing the two is not comparing like for like. The institutional crypto page covers the wider set of providers an institution deals with.

It depends on control, not on the service name. A provider that holds or controls client assets, executes bonding or unbonding transfers for a client, or issues a token representing a staked position needs CASP authorization for the relevant services. A validator that only uses the voting weight delegated to it, holding nothing and issuing nothing, may fall outside the direct scope, subject to the national authority's view. There is no authorization called a staking license.

The one whose failure mode the institution can carry. A holder that already works with a licensed custodian usually finds the simplest route is staking on top of that existing custody relationship, because the asset protection question is already answered and documented. A holder large enough to run validators gets the full reward and takes on the operations and key management obligations that go with it. Liquid staking adds a tradable claim and with it a peg and an issuer to assess, which is a separate credit judgment and not a variation on staking.