AI is the dominant force in technology spending, with Gartner putting the 2026 figure near $2.5 trillion. For institutions, the question has widened well beyond which AI stocks to own. AI is starting to throw off assets of its own and to act inside markets directly, and much of that is taking shape on crypto rails.

The clearest example is compute itself. Over the past two years the GPUs that train and run AI models have become a financial asset, used as loan collateral and packaged into securities, with analysts pegging the GPU-backed debt on neocloud balance sheets above $20 billion. But that is only the asset side. AI has also become an active participant in markets, trading and transacting on the same rails institutions use. For an asset manager or a trading desk, both sides of that are now in play.

The spot Bitcoin ETF took the better part of a decade and a wall of SEC rejections to win. The financial scaffolding for AI is going up far faster. Grayscale already runs a fund holding a basket of decentralized-AI tokens and has filed to turn its Bittensor trust into a NYSE-listed ETF, with a European manager racing to list its own version on the Swiss exchange. On the trading side, a CFTC-regulated US venue for compute futures is working toward launch, giving desks a way to price and hedge GPU time the way they already hedge oil or power. None of this waited for the underlying markets to prove themselves. Institutions are assembling the machinery to trade and hold these assets well ahead of any real track record, which tells you both how convinced the smart money is and how early it still is. The same conviction shows up in our own pipeline, where asset managers and trading desks are increasingly focused on a single question, how to hold these assets.

On a growing number of trading desks, a model now chooses the trade and places the order, start to finish. AI has moved from predicting markets to operating inside them, and it is happening on several fronts at once. In payments, over the past year Visa, Mastercard, PayPal with OpenAI, Google, and Coinbase have each rolled out or backed protocols that let an AI agent pay on its own within set limits and approvals, the groundwork for software that transacts with no person in the loop. And because autonomous systems moving money is a risk as much as a convenience, AI now runs much of the on-chain monitoring, fraud detection, and compliance screening that keeps those flows clean. Underneath all of it sits inference, the work of running these models at scale. A newer idea takes that same computation, the matrix math behind inference and training, and uses it as the work that secures a blockchain, so a GPU can mine a token while it runs AI. A year ago, AI was mostly an asset institutions bought exposure to. Today it operates inside these markets, and in a few designs it is what secures them.

For institutions, the opportunity only becomes real through a wallet, and the demands on that wallet are about to climb. To move early on a new asset, a fund or a desk needs custody that already supports the ecosystem it lives on, which means wallet providers have to put real engineering into networks that are only months old and built on unfamiliar architectures, rather than waiting years for demand to prove itself. To let an AI agent or a trading algorithm act, a wallet has to govern it, with programmatic limits, approvals, and allowlists enforced at the moment of signing, so autonomy stays bounded and every move is logged for an auditor. And beneath both, the security has to be institutional from day one, with no single private key for an attacker to take.

This is what we built Fordefi to do. As a self-custody MPC wallet, we add support for new networks as they emerge, give institutions the controls to put hard guardrails around automated and agent-driven activity, and run it all on infrastructure where the private key is never assembled in one place. More is on the way, with new integrations alongside the customers and partners building at this frontier of AI and crypto.

Institutions Are Repositioning Around AI was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

In early June, attackers drained funds from Gnosis Pay accounts. Gnosis Pay runs a self-custody card that settles onchain, and the accounts behind it are built on Safe. Safe wasn’t the weak point, and neither was the cryptography. The break came through a piece of add-on code those accounts relied on.

The add-on was a Zodiac module called Delay. Its entire job was to make things safer, holding an outgoing transaction for a few minutes so someone could catch a bad one before it settled. A flaw in the module let attackers push their own transactions into that queue, and the safeguard became the entry point.

Zodiac is worth understanding here, because plenty of institutions reach for tools like it. It’s a set of smart-contract modules from Gnosis Guild that you attach to a Safe to give it more to work with. You can define roles so a specific address transacts within set limits, add timelocks, batch actions across apps, and run checks before a transaction goes through. On the surface it behaves like wallet software. It has roles, permissions, simulation, and an execution interface, and it bills itself as a policy engine for running your Safe.

It isn’t a wallet, though, and it doesn’t manage custody. Zodiac is extra code that sits on top of the account you already have, and to do its job it holds standing authority to move funds on that account’s behalf. With the Roles modifier, an approved address can act on the Safe on its own, within its scope. With a module like Delay, transactions execute without each owner signing. That convenience is exactly where the exposure lives. When the code holding that authority has a bug, it can move funds that no person ever approved. That is what happened in June.

None of this means Zodiac is careless. It is widely used, it has been audited, and when the bug surfaced the team disclosed it quickly and Gnosis covered the losses. The problem is structural. Every module you attach is one more piece of code with authority over your funds, so securing the treasury now means securing all of it. Self-custody is supposed to give an institution tight control over what can move its assets. Spreading that authority across a growing set of contracts works against it.

The way we think about it at Fordefi, the controls belong inside the wallet itself. Keys, policy, simulation, and approvals sit in one place, and every transaction is checked against what it will do before anyone signs. A team can still move quickly within clear limits. Nothing executes on its own, and no separate contract holds the authority to move funds.

For an institution running a treasury onchain, the goal is a small, well-governed set of things that can touch its funds, each one answering to a person and a policy. The Gnosis Pay incident is a reminder of what you take on every time you add to that set.

What the latest Zodiac exploit means for institutions was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to announce that Fordefi is expanding its Hyperliquid support! Teams already using Fordefi to trade on Hyperliquid can now see exactly what each native operation does before it executes, and write policy rules that govern which operations are allowed.

This update brings enrichment, static simulation, and policy engine coverage to the core Hyperliquid message types that move money. Withdrawals to L1, transfers between perp and spot balances, USDC sends, spot asset transfers, vault deposits and withdrawals, and Core-to-EVM transfers that carry a data payload all now surface in plain language during the approval flow rather than appearing as raw signed messages.

Why this matters

Hyperliquid uses its own message format for operations on HyperCore. When a trader initiates a withdrawal, moves USDC between accounts, or deposits into a vault, the action is a signed typed message rather than a standard EVM transaction. Without enrichment, approvers see the raw payload and have to trust that the signer is doing what they say they’re doing.

That’s a problem for any team running more than one operator, and it’s a serious problem for operations like SendAsset. SendAsset is a flexible message type that can move funds between a user’s own perp and spot accounts, but it can also send assets to any arbitrary address. If you’re running policies that restrict transfers to whitelisted destinations, a SendAsset to an unrecognized address should trigger the same review as any other outbound transfer. Now it does. Fordefi checks the destination field on SendAsset messages and applies your existing address-based rules.

What’s covered

This release adds enrichment and policy coverage to six Hyperliquid operations. Each one can move funds, and each one now goes through the same decoded simulation and policy pipeline that Fordefi applies to standard EVM transactions.

Withdrawals to L1 are now presented as bridge transactions with decoded parameters and fee visibility. Withdrawals currently carry a $1 fee and take roughly five minutes to finalize.

Spot and perp asset transfers are the most flexible of the group. These messages can move assets between a user’s own accounts, but they can also send to any external address. Fordefi now reads the destination on these messages, so teams can apply address-based policies. If someone tries to send assets to an address that isn’t whitelisted, the policy engine catches it.

USDC sends from perp balances and moves funds to another address without touching the EVM bridge. These are now classified as transfers in the policy engine with the same rule coverage as any other outbound movement.

Internal balance transfers between a user’s spot and perp accounts, including sub-accounts, now show the receiving account address in the approval flow so approvers know exactly where funds are moving.

Vault deposits and withdrawals on Hyperliquid are now classified as transfers in the policy engine, giving teams the ability to set rules around vault interactions.

Core-to-EVM transfers with a data payload move funds from HyperCore to a contract on HyperEVM and call that contract’s coreReceiveWithData function rather than a plain token transfer. Because the message carries data that runs contract logic on arrival, the approval flow now shows the target contract and the payload, so approvers can see the action does more than move a balance.

Approvers see human-readable details for all of these in the console and on mobile before they sign.

What this replaces

Fordefi has supported Hyperliquid through HyperEVM chain connectivity and typed message signing via the browser extension. Users could interact with Hyperliquid and sign the right payloads, but native HyperCore operations appeared as unstructured messages. Policy rules couldn’t distinguish between a routine internal transfer and an outbound send to an external address. That gap is now closed.

Getting started

These capabilities are live for all Fordefi workspaces. If you’re already using Fordefi with Hyperliquid, the enrichment and simulation apply automatically. To add policy rules for Hyperliquid operations, open your policy engine and create rules using the transfer and bridge classifications. Existing policies that apply to transfers will now also cover the relevant Hyperliquid message types.

You can read our developer guide here: https://docs.fordefi.com/user-guide/policies/sample-hyperliquid-policies

Hyperliquid Operations Now Decoded, Simulated, and Policy-Enforced in Fordefi was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Policy rules for the parameters inside a contract call

When an institutional team interacts with a DeFi protocol, the transaction that goes out for approval is a contract call, and most of what matters about that call sits inside its data. The destination address tells you which contract you are touching. A simulated amount tells you the rough value at risk. The function being invoked and the values passed to it are where the real instruction lives, and for a long time that part of the transaction was hard to write a policy against.

A policy engine that can only match on destination and amount leaves an operator with two blunt choices. Whitelist a protocol and trust every call made to it, or block the protocol and give up access. Vault curators, market makers, and asset managers running on-chain strategies need the ground in between, where a rule can tell one kind of call apart from another.

Fordefi’s policy engine has an ABI matcher built for exactly this. An ABI describes how a contract encodes and decodes its functions, so with it the engine can read a contract call as the function being run and the parameters being passed, rather than as a block of hex. Over the past several months we have steadily widened what a rule can reach inside that call. Today’s release is the largest step in that work.

From the function to its parameters

The ABI matcher started with the function itself. You could write a rule against a method’s 4-byte selector and require approval for one method on a contract while letting another pass without friction.

In December we extended matching to the parameters inside the call. A rule could now condition on an address, an integer, or a Boolean argument and the specific value it carried. A rule could require approval when an amount argument climbed above a threshold, or when a function was called with a particular flag set.

In January we added the is origin vault operation for address parameters. This lets a rule check whether an address inside a contract call points back to the vault that initiated the transaction. When a call carries a recipient field that resolves to anything other than your own vault, a rule can catch it before it reaches an approver.

Reaching the rest of the call

Today’s release covers the parameter types that real contract calls use beyond the simple ones. Policy rules can now match on fixed and dynamic byte values, on arrays, and on tuples.

For an array argument, a rule targets a specific element by its position. You can write a condition against the second address in an address list or the first amount in a list of amounts.

For a tuple, which contracts use to group related fields into a struct, a rule targets an individual field by its position. You can place conditions on several fields of the same tuple, and they are combined together so the rule matches only when all of them hold.

Byte matching also covers a pattern common in routers and multicall contracts. A bytes4 value is itself a function selector, so when an outer function accepts a selector as an argument, a rule can constrain which inner function that call is allowed to invoke.

What you can write now

With the parameter types in place, a rule can speak the language of the contract:

• Require approval when a swap’s amount argument is above a set size, while smaller swaps on the same protocol clear automatically.
• Block a contract call when a recipient address inside a struct is not your own vault or a known address book entry.
• Require a higher quorum when a specific element of an array argument matches a flagged value.
• Allow a router call only when the inner function selector it carries is one you have approved.

The policy engine now governs DeFi the way it actually happens on chain. A curator operating a vault, a market maker running automated execution, or an asset manager working across lending protocols can write rules against the precise content of a contract call instead of approving or blocking a protocol wholesale. Destination and amount still matter in a rule. What is new is that the function and every parameter between them is now yours to govern with the same precision.

You can see the full set of supported parameter types and operations in the policy documentation.

Deeper ABI support in the Fordefi policy engine was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Walking into Consensus this week felt different. It was the first time Fordefi and Paxos shared a single booth, one brand on the wall, and the conversation found us before we’d even unpacked! After April, security was the topic everyone wanted to dig into.

And that makes sense. With 28+ hacks across the industry in April, two protocols saw significant losses last month: KelpDAO at $292 million on April 18, and Drift Protocol at $285 million on April 1, totaling roughly $577 million. Neither was a smart contract bug. Drift’s Security Council was the target of a months-long social engineering campaign in which attackers posed as a quant fund and committed more than a million dollars of their own capital to build credibility before walking the team into pre-signing administrative transactions. KelpDAO’s incident traced back to a single-verifier configuration that LayerZero had previously flagged as risky. Both incidents pointed to the same layer. Who can sign, what policy runs before they sign, and how a team catches a signer going off script.

That’s the conversation that came up over and over on the floor.

State Street’s Angus Fletcher made the point clearly on the Capital Markets stage. Big traditional finance firms need guardrails in a world of blockchain-based assets, particularly given how often DeFi has been drained. Tom Zschach, formerly SWIFT’s CIO, put it tighter on the same panel. “We’ve solved the transaction problem,” he said. “What’s missing is a standard for governance.” That framing held up across most of the institutional sessions we sat in on.

It tracked with the announcements too. State Street and Galaxy launched the Onchain Liquidity Sweep Fund, a tokenized cash-management vehicle for large investors. Western Union shipped USDPT, a dollar stablecoin issued by Anchorage Digital Bank on Solana, for 24/7 settlement with agents and partners. NYSE is building a regulated tokenized US equities venue that starts with pre-funded tokens, a careful approach that contrasts with the offshore synthetic stock tokens already in the wild. Citi’s Ryan Rugg captured what most corporate treasurers would tell you themselves. “No one wants just a Citi token. They want that multi-bank aspect of it.”

Each of those launches becomes more exciting once the operational layer behind it is solid. Who holds the keys, what policy fires before a signature, how multiple approvers coordinate, what the system does when a transaction looks off. That’s the work that earns the right to ship a Western Union stablecoin or a State Street fund.

Agentic commerce was the other big draw. Cloudflare is now processing a billion HTTP 402 responses a day on its network, which is a wild stat to sit with for a minute. Erik Reppel from Coinbase made the case for x402 as the agent payments standard, with Visa, Mastercard, Google, and Circle behind him. Christian Catalini from MIT drew the cleanest line we heard in any agentic session. Most of what gets demoed today, he said, is an LLM paired with a credit card. That’s assisted checkout, not true agentic payments. Real agentic payments begin when the AI is the counterparty, signing for itself, against rules that run before each transaction. The four protocols racing to be the standard (x402, MPP, AP2, ACP) have the payment piece. The signing and policy piece is what comes next.

Which is when this gets fun for us, because that’s the part of the problem we work on. (Yes, this is the obligatory plug. Bear with us for a paragraph.)

FORDEFI builds the policy engine that runs in front of every signature, whether the asker is a treasury operator approving a stablecoin payout or an AI agent rebalancing a position at 3am. Paxos brings the regulated issuance and custody side. Sharing a booth this year, the conversation we kept having was practical and specific. A half dozen banks and fintechs asked some version of the same question. They have key custody figured out. They’re now working through operations. Approval workflows, transaction-level policy, what it actually looks like to run an MPC wallet under an existing compliance program when half the signing flow involves DeFi positions that need to be rolled every few hours.

That’s a great problem to have. It means the institutional side is past the “should we” phase and into the “how do we” phase. It’s the kind of question that gets us excited to come into the office.

Institutions stopped asking whether crypto matters last year. This week they were asking how to run it well, with the same operational rigor they apply to everything else they do. That’s a healthy place to be, and a fun week to be on the floor for.

Day 1 takeaways from Consensus Miami was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, we’re launching Fordefi Rewards.

Fordefi is a Paxos company. Paxos is the regulated issuer behind both PYUSD and USDG, and we’re using that relationship to do something we think matters a lot for our customers. Hold PYUSD or USDG in your Fordefi wallet and earn credits towards your SaaS subscription. The more you hold, the more your subscription is offset. At qualifying balances, your subscription is fully covered.

Why We Built This

The Stablecoin market has crossed $320 Billion in circulating supply. At that scale, the reserves backing these assets generate billions in annualized revenue. Almost all of it goes to the issuers. The institutions that actually drive stablecoin adoption through custody, settlement, and trading activity don’t see any of that value come back to them.

We think that should change. When you hold either stablecoin in your Fordefi

wallet, we receive custody rewards on the balance and pass them back to you as subscription credits.

How it Works

When you hold PYUSD or USDG in your Fordefi wallet, you earn credits toward your SaaS subscription. Credits scale with your balance, so the more you hold, the more your subscription is offset.

There’s nothing to activate, lock, or tag. Just hold PYUSD or USDG in your Fordefi addresses and credits start accruing. You can move, deploy, or trade your stablecoins whenever you want. You’re already holding stables anyway, and with Fordefi Rewards, holding them here works in your favor.

Why this makes sense for asset managers, market makers, and the broader institutional audience

Every trading firm and fund manager holds stablecoin balances as part of operations. Settlement, collateral, float between positions. That capital has to sit somewhere, and right now it probably sits in other stables doing nothing for you.

PYUSD and USDG held in Fordefi change that. Your operational stablecoin balance now offsets the cost of the infrastructure you use to manage it. The wallet pays for itself.

And not every dollar of stablecoin capital is meant to be deployed into yield strategies. A meaningful portion of institutional holdings is kept intentionally unencumbered, prioritizing liquidity and capital preservation over returns. Fordefi Rewards gives that capital a purpose. You earn subscription credits without changing how you use those assets and without taking on any protocol risk.

About PYUSD and USDG

Both are US dollar-backed stablecoins issued by Paxos, fully backed and redeemable 1:1 for US dollars.

PYUSD is issued by Paxos Trust Company and regulated by the Office of the Comptroller of the Currency.

USDG is issued by Paxos on behalf of the Global Dollar Network (GDN), an open network that passes reserve-generated revenue back to partners based on custody activity. USDG is issued by Paxos Digital Singapore, which is a Major Payments Institution supervised by the Monetary Authority of Singapore. USDG is also issued by Paxos Issuance Europe under the supervision of FIN-FSA and in compliance with MiCA.

Get started

Fordefi Rewards is available to all current and new Fordefi customers. Talk to your account manager or reach out to our sales team to learn more.

[Talk to Sales]

*Access may be restricted for certain customers based on the rules and regulations governing their applicable jurisdiction.

Introducing Fordefi Rewards was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

On-chain lending used to be simple. A protocol set the terms, users deposited, and interest rates adjusted algorithmically. That model worked for a while, but it didn’t scale well. Protocols like Morpho, Euler, and Aave have moved toward more modular designs where the protocol provides the underlying lending infrastructure, and independent teams handle the actual strategy and risk management on top of it.

Those teams are vault curators.

The role

A vault curator is an independent entity that designs, deploys, and manages lending vaults on behalf of depositors. The closest comparison in traditional finance is a fund manager, but the mechanics are fundamentally different. Curators operate noncustodially through smart contracts. They configure strategies and manage risk parameters, but they never take custody of depositor funds. Users deposit and withdraw freely, and the entire operation runs transparently on-chain.

Curators decide which lending markets a vault allocates to, what collateral types are acceptable, how much exposure to take on a given asset, and when to adjust. They monitor market conditions, respond to liquidation risk, and continuously tune their vaults to balance yield against safety. Some curators specialize in conservative strategies designed for institutional depositors. Others run more aggressive allocations targeting higher returns. The strategy is up to the curator, and depositors choose which curator’s approach matches their risk appetite.

The business model is typically a management fee, a performance fee, or both. Because vault operations run on-chain with minimal back-office overhead, curators can operate with meaningfully lower costs than traditional fund managers while maintaining attractive margins.

What this looks like in practice

From the outside, curation can look like a set-it-and-forget-it operation. In reality, it involves a steady flow of on-chain transactions that require precision and context.

On any given day, a curator might be adjusting borrow caps on a Morpho market, reallocating vault supply across three different lending pools, responding to a collateral asset that’s approaching a risk threshold, or onboarding a new market that just launched. Each of these actions is a smart contract interaction. Each one changes how depositor capital is positioned. And each one needs to be reviewed, understood, and approved before it goes through.

Most curator teams are small. A handful of people managing hundreds of millions in deposits across multiple protocols and multiple chains. The operational surface is wide, the stakes are high, and the margin for error is thin.

Why the wallet layer matters

This is where infrastructure becomes a real factor in how well a curator can operate.

A standard wallet treats every transaction the same. You see a contract address, a function call, maybe some hex data. You sign or you don’t. For someone sending tokens between two addresses, that’s fine. For a curator processing dozens of complex smart contract interactions a day, it’s not.

Curators need to see what each transaction will actually do before they sign it. They need to know which assets will move, how balances will change, what allowances are being granted, and whether the contract they’re interacting with has been reviewed and approved by their team. Transaction simulation and decoded contract data turn an opaque signing request into something a risk-aware operator can evaluate quickly and confidently.

Governance matters just as much. Curator teams have internal structures, with risk analysts, portfolio managers, and operational leads each playing a different role. The wallet layer needs to reflect that. Rules about who can initiate certain types of transactions, what dollar thresholds require additional approvers, and which protocols the team is authorized to interact with should be enforced automatically on every transaction. When those rules live in the wallet’s policy engine rather than in a team wiki or a group chat, they actually hold.

Token approvals are another operational concern that most teams underestimate until it becomes a problem. Every smart contract interaction can generate a token allowance, and those allowances persist indefinitely unless someone actively revokes them. For a curator interacting with contracts all day, that means the vault’s approval surface grows steadily over time. Active allowance management, with visibility into every standing approval and the ability to revoke automatically after use, keeps that exposure contained.

And for teams operating across chains, the wallet needs to work consistently everywhere the curator operates. Same policy engine, same approval workflows, same transaction visibility, regardless of whether the vault lives on Ethereum, Arbitrum, Base, or somewhere else.

Why this matters for depositors

When you deposit into a vault, you’re placing trust in the curator’s judgment and operational discipline. Strategy is one piece of that. Infrastructure is another.

A curator’s wallet setup reflects how they manage risk at the operational level. Do they review transactions before signing, or approve blindly? Are internal roles and approval thresholds enforced programmatically, or tracked informally? Are token approvals managed actively, or left to accumulate?

These questions don’t show up in a vault’s APY, but they have a direct impact on the safety of depositor capital.

Where curators actually operate

This is why the majority of on-chain vault curators today run their operations from Fordefi.

Fordefi is an institutional MPC wallet built for teams that interact with smart contracts as a core part of their business. Every transaction is decoded and simulated before signing. A DeFi-native policy engine enforces approval rules, protocol allowlists, and signer thresholds on every action. The Allowance Manager and AutoRevoke keep token approvals scoped and short-lived. And the same governance model works consistently across 90+ blockchains.

For curators, the platform fits the operational reality of the job. The tooling maps directly to the daily work of managing on-chain vaults at scale, from collateral adjustments and market allocations to multi-signer reviews and cross-chain deployments.

As on-chain yield management matures and institutions look more carefully at where to allocate, the infrastructure behind each curator will matter more than it does today. The curators who are already operating from governed, transparent infrastructure are the ones building that credibility now.

What Vault Curators Do and Why Their Wallet Infrastructure Matters was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to announce that Fordefi is expanding its Hyperliquid support! Teams already using Fordefi to trade on Hyperliquid can now see exactly what each native operation does before it executes, and write policy rules that govern which operations are allowed.

This update brings enrichment, static simulation, and policy engine coverage to the core Hyperliquid message types that move money. Withdrawals to L1, transfers between perp and spot balances, USDC sends, spot asset transfers, and vault deposits and withdrawals all now surface in plain language during the approval flow rather than appearing as raw signed messages.

Why this matters

Hyperliquid uses its own message format for operations on HyperCore. When a trader initiates a withdrawal, moves USDC between accounts, or deposits into a vault, the action is a signed typed message rather than a standard EVM transaction. Without enrichment, approvers see the raw payload and have to trust that the signer is doing what they say they’re doing.

That’s a problem for any team running more than one operator, and it’s a serious problem for operations like SendAsset. SendAsset is a flexible message type that can move funds between a user’s own perp and spot accounts, but it can also send assets to any arbitrary address. If you’re running policies that restrict transfers to whitelisted destinations, a SendAsset to an unrecognized address should trigger the same review as any other outbound transfer. Now it does. Fordefi checks the destination field on SendAsset messages and applies your existing address-based rules.

What’s covered

This release adds enrichment and policy coverage to five Hyperliquid operations. Each one can move funds, and each one now goes through the same decoded simulation and policy pipeline that Fordefi applies to standard EVM transactions.

Withdrawals to L1 are now presented as bridge transactions with decoded parameters and fee visibility. Withdrawals currently carry a $1 fee and take roughly five minutes to finalize.

Spot and perp asset transfers are the most flexible of the group. These messages can move assets between a user’s own accounts, but they can also send to any external address. Fordefi now reads the destination on these messages, so teams can apply address-based policies. If someone tries to send assets to an address that isn’t whitelisted, the policy engine catches it.

USDC sends from perp balances move funds to another address without touching the EVM bridge. These are now classified as transfers in the policy engine with the same rule coverage as any other outbound movement.

Internal balance transfers between a user’s spot and perp accounts, including sub-accounts, now show the receiving account address in the approval flow so approvers know exactly where funds are moving.

Vault deposits and withdrawals on Hyperliquid are now classified as transfers in the policy engine, giving teams the ability to set rules around vault interactions.

Approvers see human-readable details for all of these in the console and on mobile before they sign.

What this replaces

Fordefi has supported Hyperliquid through HyperEVM chain connectivity and typed message signing via the browser extension. Users could interact with Hyperliquid and sign the right payloads, but native HyperCore operations appeared as unstructured messages. Policy rules couldn’t distinguish between a routine internal transfer and an outbound send to an external address. That gap is now closed.

Getting started

These capabilities are live for all Fordefi workspaces. If you’re already using Fordefi with Hyperliquid, the enrichment and simulation apply automatically. To add policy rules for Hyperliquid operations, open your policy engine and create rules using the transfer and bridge classifications. Existing policies that apply to transfers will now also cover the relevant Hyperliquid message types.

Hyperliquid Operations Now Decoded, Simulated, and Policy-Enforced in Fordefi was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Around 2:54 PM UTC on April 14, someone took over the DNS for swap.cow.fi.

For the next few hours, anyone who typed the URL, clicked a bookmark, or followed a link to CoW Swap landed on a fake site. When users went to trade, their wallet asked them to sign an approval, which is normal in a DeFi swap, and they signed. Nothing on the page, in the URL bar, or in the signing prompt gave them a reason to pause. Unfortunately, the approval was for unlimited spending permissions of an ERC-20 token to an address controlled by the attacker. Security researchers tracking the incident pegged the losses at around $500,000 across several wallets before CoW DAO got the warning out, and people stopped visiting the site.

CoW’s smart contracts and protocol backend were both unaffected. The team paused both as a precaution while they worked on regaining the domain, and they communicated through the whole incident on X and Discord. Blockaid, one of our security partners, flagged cow.fi as malicious almost in real time. Anyone who interacted with the site after 14:54 UTC was told to run revoke.cash immediately.

How an attack like the CoW Swap hijack compromises any web-based aggregator

A DNS hijack is a registrar-layer attack, which means the attacker never touches CoW Protocol’s code or contracts. Instead, they compromise the account that controls where swap.cow.fi resolves on the internet, usually by socially engineering the domain registrar or stealing a credential, and re-pointing the domain to a server they control. From the user’s side, nothing visibly changes. The URL stays the same, the SSL certificate validates, and the page is a pixel-perfect clone of the real CoW interface.

The theft happens in what the malicious frontend sends to your wallet. Instead of a legitimate swap routed through CoW’s settlement contract, the cloned site builds a plain ERC-20 approve() call granting an attacker-controlled spender address an unlimited allowance over your token balance. Your wallet displays this as a standard approval prompt because it technically is one; the only difference between this approval and a real one is the spender address sitting in a field most users don’t decode. Once you sign, the attacker’s contract holds standing authorization to call transferFrom() and pull those tokens whenever it wants. CoW’s contracts are never invoked, which is why every project hit by this kind of attack can truthfully say their contracts weren’t compromised and why that statement does nothing for the user whose capital just left their wallet.

This is also not a one-off. Frontend and DNS-layer attacks have become one of the most common patterns in DeFi, because compromising a registrar account is easier than finding a bug in an audited contract. Some recent examples:

• Curve Finance — multiple DNS hijackings over the years, including another incident the same day as the CoW attack.
• Aerodrome and Velodrome — coordinated DNS attack across both protocols, flagged by Blockaid 36 minutes before the first public report.
• Hacken’s Q1 2026 report — 44 major Web3 security incidents totaling $482M in losses, with the majority tied to phishing and social engineering rather than contract exploits.

Why Fordefi’s MPC wallet removes this class of risk entirely

Executing swaps inside Fordefi takes the entire CoW Swap attack pattern off the table. You’re not resolving swap.cow.fi or any other partner’s frontend domain in a browser, so a hijacked DNS record has no surface to reach your signing path. You’re also not signing with a single private key on a laptop, so there’s nothing for a spoofed page to phish. Every transaction runs through simulation with decoded contract calls and policy-based approvals before a signature is generated, so a malicious approve() surfaces as exactly that to a quorum of approvers instead of hiding behind a clean UI. Fordefi customers can also activate Blockaid Cosigner, the same real-time transaction screening engine that flagged cow.fi as malicious during the April 14 incident, as an additional layer on top of Fordefi’s existing simulation and policy checks. The entire chain of compromise that drained wallets through swap.cow.fi never reaches a Fordefi user.

Risk removal aside, in-app swaps is a product worth using on its own terms:

• The first institutional wallet to surface multiple DEX pricing options from Uniswap, 1inch, and CoW Swap in one view. Best execution across the biggest EVM venues from a single interface, with route details, expected output, slippage tolerance, and fees surfaced before you sign.
• Full Ethereum and Solana ecosystem support. EVM aggregation across Uniswap, 1inch, and CoW plus native Solana swaps powered by Jupiter, all from the same workspace.
• Token approval and swap in a single action. Fordefi executes both steps together to avoid missed swaps when approvals and trades would otherwise get separated.
• Optional MEV protection. Route eligible Ethereum transactions through private execution, and use Jito on Solana, to reduce exposure to sandwiching and front-running on sensitive trades.
• API execution for automated strategies. Run the same swaps programmatically with one integration, with the same policy rules, approvals, and audit trail as manual execution.
• No native gas management required. Swap without holding native tokens for gas, with fees applying only when the sold token requires an on-chain approval.

Try in-app swaps for yourself. The execution layer is worth a closer look before the next frontend incident makes the decision for you.

Lessons from the CoW Swap frontend incident was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

The deal sheet from the last six months is getting hard to ignore.

• October 2025: Ripple acquired GTreasury. Fireblocks acquired Dynamic. Modern Treasury acquired Beam.
• November 2025: Paxos acquired Fordefi.
• January 2026: Fireblocks acquired TRES Finance.
• February 2026: Crypto.com got conditional OCC approval for a national trust bank, joining BitGo, Circle, Ripple, and Paxos. Citi said it would launch institutional Bitcoin custody inside its existing safekeeping framework.
• March 2026: Mastercard agreed to buy stablecoin payments firm BVNK for up to $1.8 billion. Anchorage added Tron custody and staking.
• April 2026: Morgan Stanley said it would operate as a Bitcoin and crypto bank for clients. The FDIC opened a formal study on crypto custody protections.
• Across 2025: Ripple rolled up seven startups across payments, brokerage, treasury, and stablecoin infrastructure, including Hidden Road ($1.25B) and Rail ($200M).

By year-end 2025, more than 265 crypto M&A deals had closed, totaling roughly $8.6 billion. That’s almost four times 2024.

The venture side is moving in the same direction. Wallet and custody infrastructure is now one of the most heavily funded categories of the cycle, with multiple firms closing nine-figure rounds in 2025 and into 2026.

Most coverage treats the M&A wave and the funding wave as two stories. We believe they’re the same story, told from two directions. If your team is about to sign a three-year contract with a wallet vendor, it’s worth understanding what that story actually says.

The acquisitions and funding rounds are saying the same thing

Wallet infrastructure runs the critical path for institutions operating on-chain. It’s become the control layer for payments, settlement, treasury, tokenization, DeFi, and governance. Your wallet provider runs your policy engine, your approval flow, your audit trail, and your execution surface.

Paxos, Fireblocks, Ripple, and Mastercard are buying because they need wallet, policy, and execution inside their regulated stack. Citi and Morgan Stanley are building the same thing from the bank side. Venture investors are writing bigger checks because the category is finally big enough to support platforms, not features.

Every one of them is making the same bet. Institutions will pick a handful of wallet and custody providers and stay with them for a long time. The providers who don’t make that shortlist either get bought, run out of runway, or drift into an adjacent category.

What buyers are really asking

Institutional buyers in 2026 are trying to answer two questions at the same time.

Will this vendor still be running the product I’m using in five years?

We see this question showing up more frequently because the market has seen two failure modes that force an emergency migration while your capital is live on-chain.

The first is a tech acquisition where the buyer wants the MPC technology, not you. The product gets absorbed. You’re pushed into a migration on someone else’s schedule.

The second is financial distress. Even if the vendor survives, the uncertainty is enough to trigger a de-risking exercise. Your team has to rebuild vaults, policies, integrations, and approvals, and sometimes unwind on-chain counterparties and contract hooks, while the business keeps running. If you have live exposure tied into on-chain workflows, you usually can’t unwind it in the timeframe your risk team wants.

A fragile vendor turns wallet selection into a board-level discussion every quarter. A durable vendor lets you stop thinking about it.

Can this vendor keep shipping the features my next use case needs?

In 2025, stablecoins forced wallet providers to handle real treasury and payments workflows with auditable policy approvals. Tokenization added issuance, lifecycle, transfer restrictions, and multi-party governance. On-chain credit went stablecoin-native. In August 2025 alone, $51.7B was borrowed on-chain. By early 2026, stablecoin supply crossed $300B, Mastercard was writing $1.8B for stablecoin payments infrastructure, and major banks were folding Bitcoin custody into the same accounts clients use for equities and cash.

If your provider can’t fund a flexible roadmap, you wait on features you need or build fragile workarounds. If they ship fast but underinvest in the controls layer, your approvals slow down and your risk team starts escalating.

Most providers pick (or only have the capital for) one priority. You feel that choice either as operational risk or product stagnation.

Why 2026 is pushing on both at once

The first quarter makes the stakes clearer.

When banks enter custody directly, “institutional-grade” stops being defined by crypto-native vendors comparing themselves to each other. Citi, Morgan Stanley, BNY, and their banking regulators are setting the standard now. Any wallet provider sitting in the critical path for a regulated program has to meet expectations that were built for traditional custody and clearing.

The use cases are also expanding faster. Stablecoin payments, tokenized Treasuries, tokenized deposits, and on-chain credit are all moving from pilot to production at once. Mastercard buying BVNK and Ripple’s rollup tell you the major payment networks are going to route real volume through stablecoin rails. The wallet providers sitting behind them have to keep shipping and meet bank-grade resilience requirements at the same time.

Where Fordefi fits

Fordefi is the most capitalized institutional MPC wallet in the market. That’s not about Fordefi’s venture raise. It’s about the balance sheet under the platform you’re using. Paxos has raised more than $500M from Oak HC/FT, Declaration Partners, Founders Fund, and PayPal Ventures, and is prudentially regulated by FIN-FSA in Europe, NYDFS in the US, MAS in Singapore, and FSRA in Abu Dhabi Global Market.

About 300 institutions run on Fordefi today, and the platform processes more than $120B in monthly transaction volume across 90+ chains. The product, team, roadmap, integrations, and pricing all continue as they were before the Paxos deal. What changed is what’s underneath.

For teams running a wallet evaluation now, a few things look different:

• Counterparty strength. Your risk, security, and BCP teams can treat Fordefi as part of a regulated platform with a long horizon, not a point solution with uncertain longevity. The wallet sits inside a business that earns revenue from stablecoins, custody, and tokenization. It isn’t a standalone product chasing the next round.
• Feature velocity. The roadmap you already rely on stays funded: policy engine, multi-chain coverage, DeFi connectivity, transaction simulation, payments workflows. Over time, you can pair Fordefi’s non-custodial wallets with qualified custody from Paxos, use Paxos-issued stablecoins alongside existing workflows, and extend into more assets and chains as protocol coverage grows. Nothing here is forced. It’s additive.
• Scope. Fordefi stays focused on the institutional wallet problem. Paxos handles the regulated infrastructure layer. You don’t have to pick between a wallet vendor that doesn’t do custody and a custodian that doesn’t do DeFi.

If you’re evaluating wallet infrastructure in 2026

A few things worth taking into your next review:

1. Treat counterparty strength as a product requirement, not a legal checkbox. Ask every wallet vendor how long their runway is, who’s on their cap table, and what happens to your contract and your production workflows if they get acquired for the technology rather than the customer base.
2. Ask where the roadmap money comes from. A provider funded by customer revenue inside a larger regulated platform has different incentives than one burning venture dollars on growth. Neither is automatically better. The answer should shape how you think about a five-year commitment.
3. Separate features today from features in 18 months. Stablecoins, tokenization, and on-chain credit are moving faster than your procurement cycle. Providers who can fund the next wave without raising first are in a different position than providers who can’t.
4. Read the deal sheet as a forward signal. Consolidation in 2025 is accelerating, not slowing. If your wallet provider looks more like a target than a platform, build that into your continuity plan now.

The deals, the rounds, and the bank announcements all point the same way. Institutional on-chain operations are getting more serious, and the platforms that come out of this cycle will be the ones customers can commit to without hedging. That’s the bet Paxos made on Fordefi and it’s the same bet we’re asking our customers to make on us.

If your team is working through a wallet evaluation and wants to talk through what Fordefi inside Paxos means for your specific continuity and roadmap questions, we’ll walk you through it.

What the M&A Wave (and the Funding Rounds) Are Really Telling You About Wallet Infrastructure was originally published in Fordefi on Medium, where people are continuing the conversation by highlighting and responding to this story.