Kraken parent Payward agrees to acquire Magic Labs’ wallet infrastructure business

What Payward is acquiring

Payward, Inc., the infrastructure group behind Kraken, announced on July 27 that it had entered into a definitive agreement to acquire Magic Labs’ wallet-as-a-service business. The transaction covers Magic’s embedded, non-custodial wallet technology rather than the entire company. Financial terms were not disclosed, and closing remains subject to customary conditions.

Magic Labs says its wallet infrastructure has powered more than 60 million wallets, processed over $10 billion in stablecoin volume and served more than 200,000 developers. After the transaction, those wallet customers are expected to move to Payward Services. Magic Labs will continue separately as Newton Labs, focusing on the Newton Protocol authorization layer.

Why the legal-entity boundary matters

Kraken is the public-facing exchange brand, while Payward operates the broader group infrastructure behind Kraken and several other products. The announcement therefore belongs at Payward group level. It should not be described as Kraken itself acquiring an entire company, and it should not be assumed that every Kraken customer will contract with the same entity for wallet services.

This distinction matters because a group can share technology, liquidity, risk systems and compliance infrastructure while different products remain subject to different contracts, licences and regional restrictions. Cexvia will treat the acquired wallet business as part of Payward’s technology and service perimeter only after closing, and will continue mapping customer-facing entities by jurisdiction.

Security and custody implications

Magic’s stack is described as non-custodial and combines trusted-execution-environment signing, an embedded integration layer and developer tools. Bringing those components in-house could reduce the number of vendors that Payward’s enterprise customers need to integrate. It could also give Payward more direct control over product development, incident response and service continuity.

Those potential benefits are not yet evidence of a security-control outcome. An acquisition announcement does not show how keys are generated, which party can change signing policies, how recovery works, whether code has been independently audited or how incident liability is allocated. Cexvia therefore does not raise Kraken’s security score on the basis of this transaction.

Scale, customers and the planned transition

The figures attached to the transaction show why the asset is strategically relevant to Payward. Magic says the acquired wallet stack has created more than 60 million wallets, supported over 200,000 developers and processed more than $10 billion in stablecoin volume. Those numbers describe historical usage of the technology, not assets that Payward is buying or customer balances that will move onto Kraken. They should therefore be read as an indication of integration scale rather than proof of revenue, reserves or custody quality.

The parties say customers using the wallet-as-a-service product are expected to transition to Payward Services after closing. A customer transition is more consequential than a change of brand on a website: agreements, subprocessors, data locations, service-level promises, incident notification and recovery responsibilities may all change. Enterprise users should expect direct notice and updated terms rather than infer the new arrangement from a group-level press release.

Magic Labs itself is not disappearing. The remaining business is expected to continue as Newton Labs and focus on the Newton Protocol authorization layer. That separation matters because customers may continue using technology or services associated with both sides after closing. A complete vendor review must identify which company supplies the embedded wallet, which supplies any authorization component and whether either party can affect key access or transaction approval.

Questions the acquisition announcement does not answer

The announcement does not provide a technical architecture, independent audit, migration plan or post-closing legal terms. It does not state whether signing policies will remain identical, how trusted-execution-environment access is administered, whether customer recovery paths will change or which entity will compensate a customer if the signing service authorizes an unintended transaction. Those gaps are normal in an acquisition announcement, but they prevent a security conclusion.

It also does not change the licences under which Kraken exchange services are offered. The acquisition concerns group technology and a business-to-business wallet product; it is not evidence that a Payward exchange entity has received a new authorization in the United States or another jurisdiction. Cexvia therefore keeps the exchange rating unchanged and records the deal as an ownership and infrastructure event pending closing and customer migration evidence.

The most useful future disclosures will be the closing confirmation, customer-facing contract, service architecture, independent assurance reports and any explanation of how the acquired controls fit Payward’s incident-response process. If those materials show improved key isolation, clearer recovery governance and stronger audit coverage, they can support a later security assessment. Until then, the transaction is strategically important but operationally unproven.

What customers should watch next

The next material milestones are transaction closing, migration notices for existing Magic customers, updated contractual terms and a clear explanation of which Payward entity supplies each service. Enterprise customers should also review whether their integration remains self-custodial in practice and which party is responsible for signing availability, recovery and incident notification.

For ordinary Kraken exchange users, the announcement does not require immediate action. It is a group-level infrastructure development, not a notice that account custody, withdrawals or regional access have changed. Any future product migration should be assessed separately when official terms and affected entities are published.