I didn't set out to write about AI agents and crypto infrastructure. For months, I've been buried in DAO governance post-mortems, tracing why every "decentralized" protocol ends up with three engineers holding the keys to the kingdom. But then I stumbled on something that made me pause mid-research: a freshly funded project, $100 million raised at a $2 billion valuation, whose entire security model rests on a single sequencer run by a company that has never published a bug bounty.
We didn't need another narrative piece about how AI will revolutionize crypto. We need to talk about the boring machinery underneath — the operators, the key holders, the multi-sigs, the sequencers — and how the industry's most trusted infrastructure is quietly becoming the most centralized part of the stack.
This piece is not a hit piece on any specific protocol. It's a pattern recognition exercise. And the pattern, once you see it, is hard to unsee.
The Allure of the Autonomous Agent
Let's start with the story everyone loves: autonomous AI agents managing crypto portfolios, negotiating with other agents, paying for compute, routing liquidity across chains. The vision is beautiful. It promises a world where machine-to-machine payments happen without humans watching every transaction. In that world, an agent wakes up, checks its vault, sees that it needs additional GPU hours, and autonomously purchases them on a decentralized compute marketplace. No approvals. No banks. No friction.
Blockchain is the perfect settlement layer for this. It provides a neutral, permissionless ledger where agents can hold assets, sign transactions, and execute logic. The economics are compelling too. An agent that actively manages yield across protocols could generate revenue while the user sleeps. The user just sets guardrails, and the agent does the rest.
But here is where my audit instincts kick in. I've spent years looking at smart contracts, and the first question I always ask is: who has the privilege? Not who owns the contract, but who can change the rules. In most AI agent frameworks, the answer is sobering. The agent runs its "brain" on a centralized inference server. The agent's "wallet" is controlled by a private key held in a custodial service. The "autonomous" action is actually executed by a relayer owned by the platform that issued the agent.
We call this autonomy, but it's really delegation. The user delegates their authority to a platform, and the platform delegates to a few operators. And on the settlement layer, those operators are starting to look a lot like a centralized bank.
Take the AI x crypto narrative that dominated the last year. Every major platform rushed to launch "agent launchpads," letting users create semi-autonomous bots that trade, stake, and manage NFTs. The mone y flows into these agents because users trust the platform. But if that platform controls the agent's private key, or if the agent's policy engine is a centrally-hosted model with a kill switch, then "autonomy" is just a marketing word.
I remember the moment this clicked for me. I was reverse-engineering a popular agent framework and found that the entire system depended on a single JSON-RPC endpoint. If that endpoint goes down, every agent using that framework goes blind. No fallback. No failover. Just a spinning wheel and a support forum. For a world that claims to be infrastructure for the future of finance, we're building on very thin ice.
This is not a call to abandon AI agents. It's a call to look at the trust assumptions we're accepting without scrutiny.
The Sequencer: Crypto's Invisible Clock
If AI agents are the shiny facade, the sequencer is the load-bearing wall. But nobody wants to talk about walls.
In the post-merge world, layer-2 networks dominate activity. Every rollup needs a sequencer to order transactions, bundle them, and settle them to the base layer. The sequencer is essentially a traffic cop. It decides which transactions go first, which ones get reordered, and which ones get dropped. It's the single most important component for user experience and, in many designs, for revenue.
The dirty secret: most sequencers are centralized. Not by accident, but by design. Running a decentralized sequencer is hard. It requires consensus among multiple parties, which adds latency, and it creates coordination overhead. It's much easier to run a single node, collect the transaction fees, and settle the batch to Ethereum once a minute.
We've been sold a future where "decentralized sequencing" is coming. It's been coming for over two years now. Every major layer-2 has a slide in its pitch deck about moving to a decentralized sequencer "in a later phase." That phase keeps getting pushed back. Why? Because introducing a decentralized sequencer is a massive technical risk. It opens the door to front-running, transaction censorship, and coordination failures. And more cynically, a centralized sequencer generates a lot of value for the operator — value that might not survive the transition to a permissionless set of nodes.
Let me give you a concrete example from my own experience. In 2022, I was analyzing a new rollup that claimed to be "securely decentralized." I asked for their sequencing architecture. They pointed to a single company that ran 70% of the network's infrastructure. That company also happened to hold the multi-sig keys to upgrade the smart contracts. Technically, the protocol had a governance token. Practically, it was a classic web2 company with a crypto wrapper.
What's worse is that this pattern isn't hidden. It's visible in block explorers, in the commit-reveal schedules, in the fact that batches are only produced by one entity. But the market doesn't care because the token price keeps going up. In a bull market, centralization is a feature to be rationalized, not a bug to be fixed.
I'm not saying centralized sequencers are evil. They're far more efficient than decentralized alternatives, and for early-stage protocols, they're the pragmatic choice. But for the love of all that is decentralized, let's stop pretending that a rollup with a single sequencer is the same as Ethereum. It's not. It's a fast server that happens to publish receipts to Ethereum. That's not the same as a global settlement network.
The consequences are non-trivial. A centralized sequencer can censor addresses with a simple line in its code. It can extract maximal value by reordering transactions. It can turn off the network whenever the operator chooses. None of this is hypothetical. We've seen sequencer outages across multiple chains. We've seen teams negotiate with malicious actors to avoid blacklisting addresses. The infrastructure is fragile, and the fragility is hidden behind a friendly UI.
If AI agents are going to live on these chains, the stakes multiply. An agent might not know its sequencer is down. It just sees a failed transaction and tries again. It might exhaust its gas budget retrying into an outage, or worse, the agent's operator might reroute the transaction to a private mempool, creating a settlement mismatch. The flywheel of autonomous agents depends on reliable, neutral infrastructure. And we're building it on a layer that can be switched off with a single kill command.
The Multi-Sig: Rule by a Fistful of Keys
Now let's talk about governance, because this is where my heart lies. For years, I've been writing about the gap between "code is law" and "code is what the multi-sig says it is." The pattern is consistent: a protocol launches with a governance token, the community celebrates decentralization, and then an upgrade happens through an emergency multi-sig operated by the founding team.
This isn't inherently wrong. Emergency actions need to be fast, and a multi-sig can save a protocol during an exploit. But the multi-sig power has expanded over time. It's no longer just for emergencies. It's used to tweak parameters, pause entire products, and sometimes override governance votes that the founding team dislikes.
During my time auditing DAO governance frameworks, I found that the average "decentralized" protocol has at least one 2-of-3 or 3-of-5 multi-sig that can change almost anything. The nominally decentralized holders vote on cosmetic changes while the core team retains the ability to freeze funds, upgrade tokens, and change the economic rules of the game. Let that sink in.
The most revealing case I studied was a lending protocol that had a governance vote to adjust a collateral factor. The vote passed with overwhelming community support. But the change wasn't executed. Instead, the multi-sig team decided that the timing was bad for the protocol's token price, so they delayed the execution. There was no formal process for this. It was just a message in a Telegram group saying, "We'll do it in two weeks." The vote was technically valid; the multi-sig just didn't feel like executing it.
This is the quiet centralization of crypto's most trusted infrastructure. We trust the code, but the code is governed by a few humans. And those humans are often the ones who wrote the code, which means the incentive to maintain their own power is baked into the system.
Let's tie this back to AI agents. If an agent interacts with a protocol, its expectations are shaped by the protocol's historical behavior. If the protocol's rules change depending on the mood of a multi-sig, the agent's model of the world becomes unreliable. The agent might execute a strategy that was only valid under the old parameters. It could get liquidated because the collateral factor changed at an inopportune moment.
Automation and central governance are fundamentally in tension. Automation craves predictability, while multi-sig governance thrives on discretionary flexibility. You cannot have both.
I've written before about how "code is law" is a fiction. But I've also written about how trusting a multi-sig is a form of law — just a much more unstable one. The question isn't whether to be centralized or decentralized. It's about aligning the autonomy of agents with the determinism they need to function.
The Trust Layer Nobody Audits
Now let me pivot to the thing that keeps me up at night: the trust layer that nobody is auditing. When we talk about crypto security, we talk about smart contract bugs. We talk about reentrancy attacks, arithmetic overflows, and oracle manipulation. These are real and important, but they're only half the story.
The other half is the forgotten middleware: the relayer networks, the indexers, the data aggregators, the off-chain policy engines that feed decisions to smart contracts. In a typical DeFi interaction, a user signs a message, a relayer submits it, an oracle prices it, and a keeper executes it. Each step involves trust. And each step is typically run by a centralized service.
The paradox is that we applaud the on-chain transparency of the final settlement while ignoring the opacity of the surrounding infrastructure. The most complex systems are the ones where trust is most diffuse. Diffuse trust is hard to audit. It's also hard to attack, because the attacker doesn't know which component to hit. But for the user, diffuse trust means they don't know whom to blame when something fails.
Let me give you a specific example from the world of stablecoin payments. In many developing countries, crypto adoption is real because it solves a real problem: local currency inflation. I've written about how the true driver of stablecoin usage in Argentina, Turkey, and Nigeria isn't blockchain ideology. It's that the local currency loses value faster than people can spend it. People use USDT or USDC as a way to preserve savings.
But those stablecoin transfers often pass through a centralized payment rail. The on-ramp is a local exchange that operates in a legal gray zone. The off-ramp is a peer-to-peer vendor who moves large amounts of cash. The stablecoin itself is issued by a company that holds billions in treasury bills and can freeze any address at any time, either voluntarily or because a government agency asks.
The technology on the front end — the wallet, the QR code, the instant settlement — feels magical. The user experience is that of a borderless bank. But the reality is that the system is only as trustworthy as the company that prints the stablecoin and the exchange that connects it to the fiat world. There's nothing wrong with centralized trust per se, but when we market it as decentralized, we create a false sense of security.
I've often said that in crypto, the user is the auditor. But users don't have the time to audit the legal agreements of an off-ramp provider. They can't inspect the treasury holdings of a stablecoin issuer. They can't verify the liquidity of a custodian. So they trust logos and TVL numbers. And when that trust breaks, it breaks catastrophically.
This is why my advice to infrastructure builders is simple: separate the trust layers explicitly. If a service is centralized, say so. If a sequencer can censor, document it. If a protocol's governance is effectively a multi-sig, display that prominently on the dashboard. The industry has matured enough to accept that not everything will be fully decentralized from day one. What we can't accept is a lack of honesty about what's actually running underneath.
The Bull Market Makes It Worse
Now let me be honest about the market context. We're in a bull market, and that changes everything. In a bull market, funding is cheap for people, and credibility is cheap for protocols. Projects launch with bold claims and even bolder token valuations. The community is eager to believe, because skepticism is expensive when everyone around you is getting rich on the momentum.
I've seen this cycle before. In 2021, I was deep in the NFT infrastructure world. Projects were launching with no product, no team, and a whitepaper full of trend words. They raised millions because the narrative was hot. Most of them died within a year, taking the community's money with them. It wasn't because they were malicious. It was because they were building on a foundation of sand — centralized servers, non-audited contracts, and a business model that depended on never-ending growth.
We're seeing the same pattern in AI agents and rollup infrastructure now. The narrative is even hotter, so the incentives to cut corners are even stronger. The bull market is not the time to be less vigilant. It's the time to be more vigilant, because the consequences of a failure are amplified by the leverage.
I still remember the yield farming loss that taught me this lesson in 2020. I put my entire personal savings into an unaudited protocol because the returns were irresistible. Within 48 hours, the contract was drained. I didn't lose just money; I lost my confidence in the industry for a moment. It took me months of reverse-engineering the exploit to regain my systematic thinking. That experience taught me to look at what isn't being said. When a protocol doesn't publish its threat model, that's a signal. When a sequencer doesn't have a public health check, that's a signal. When a team controls a multi-sig and refuses to disclose signer identities, that's a signal.
The signals are all around us. We just need to look past the green candles.
The Roadmap Trap
One of the most common replies to my criticism is: "We have a roadmap." The roadmap says decentralized sequencing is a future upgrade, multi-sig powers will be reduced once governance matures, and agents will eventually run on open networks. I've heard this so many times that I've developed a cynical reflex: the more vague the roadmap, the more likely it's a token-based sales pitch.
Roadmaps are not deliveries. In 2019, every major privacy coin promised to deliver on-chain privacy by 2021. In 2021, the promise was that Layer 2 would be decentralized by 2022. In 2022, it was that AI agents would be self-sovereign by 2024. Some of these promises were kept. Most were quietly pushed back. It's not always because of bad intent. It's because delivering decentralized infrastructure is hard, and the operating environment changes.
But here's the thing: the roadmap itself is a centralization point. The team that controls the roadmap controls the narrative, and the narrative controls the price. If you want to understand a protocol's power distribution, don't read its constitution. Read its roadmap. See who has the authority to change it, and you'll find who really rules.
For AI agents, the roadmap trap is even more dangerous. An agent's behavior is determined by its training data and its policy engine. If the policy engine is updated via a centralized dashboard, the agent is just a puppet. The roadmap may say "future self-sovereignty," but the present is a hosted service. A hosted service that can change its mind about what behavior is allowed.
The future isn't written. It's built. And it's built through a series of incremental decisions that most people don't notice. Every time a protocol chooses speed over decentralization, every time a team keeps a backdoor in its code, every time a governance vote is ignored, the future is being set. The question is whether the community realizes it's participating in that decision.
The Contrarian Angle: Maybe We Need Less Decentralization
Now, let me take a step back and play devil's advocate against myself. It might sound like I'm arguing for pure decentralization everywhere. I'm not. In fact, I think the industry has fetishized decentralization to the point of absurdity.
Decentralization is a means, not an end. It's a tool to achieve specific properties: censorship resistance, liveness, neutrality. But those properties aren't always needed. If you're building a consumer app where convenience matters more than censorship resistance, a centralized backend might be the right choice. If you're a small protocol in a market niche, a multi-sig might be the pragmatic governance structure. If you need instantaneous settlement, a centralized sequencer could deliver that better than any decentralized alternative.
The danger is when we conflate the appearance of decentralization with the actual property. A protocol that claims to be decentralized but is governed by a multi-sig provides the worst of both worlds: the illusion of trustlessness and the brittleness of a centralized operator. A protocol that openly says "we're centralized, and here's how we ensure your fund s are safe" is easier to trust because you have clear expectations.
Here's a radical thought: maybe we need fewer decentralized protocols, not more. Maybe the industry should lean into the honest centralization of infrastructure. Let the low-level settlement layer stay decentralized and neutral, as it is with Ethereum. Let everything above it be openly centralized but rigorously audited and transparent. This would reduce the confusion and, paradoxically, increase overall system resilience, because no one would be pretending to be something they're not.
I've seen this vertical integration work in traditional finance. The clearinghouse is centralized, the settlement is centralized, the custody is centralized. The system is efficient and heavily regulated. Crypto doesn't need to replicate that exact model, but it can learn from it.
If you're building an AI agent platform, you don't have to make the inference engine decentralized. You need to make the agent's assets safe, the contracts transparent, and the recovery procedures clear. If you're building a layer-2, you don't have to decentralize the sequencer on day one. You need to disclose that it's centralized, publish a trust assumption doc, and provide a clear path for users to exit if they disagree. The problem isn't centralization; it's the lie of decentralization.
What the Quiet Centralization Means for AI Agents
Let's return to the AI agents that started this thought process. They are, in many ways, the purest expression of crypto's promise: autonomy, self-custody, and machine-to-machine commerce. But an agent is only as autonomous as its infrastructure allows.
To build agents that are truly autonomous, we need three layers to be decentralized or at least explicitly trustworthy. First, the asset custody layer. The agent needs to control its own assets through a portable key, not through a platform-managed account. Second, the data retrieval layer. The agent needs access to reliable, uncensorable market data, which means we need better decentralized oracles and data availability solutions. Third, the execution layer. The agent needs a way to submit transactions that isn't controlled by a single relay provider.
If any of these three layers is compromised, the agent's autonomy is fake. It becomes a remote-controlled bot that can be killed, redirected, or liquidated by its infrastructure provider.
I've been experimenting with a simple test for agent frameworks: the "offline test." If you train an agent locally, give it a set of transactions to execute, and then ask it to simulate those transactions without any network connection, can it do it? If it can't, the agent isn't autonomous. It's a thin client for a centralized service. Most frameworks fail this test.
But there are promising signs. New projects are working on self-sovereign agent wallets, decentralized compute markets, and open source policy sandboxes. They're moving the industry in the right direction, but slowly. The challenge is that in a bull market, it's easier to sell a centralized demo than to build a decentralized production system. The incentives favor the demo.
This is where I think the next major exploit will happen. Not in a smart contract, but in the centralized glue between an AI agent and the blockchain. A single compromised API key, a malicious relayer, or a poisoned oracle could cause an agent to do catastrophic things — like transferring its entire treasury to an attacker. The attack surface is enormous, and the industry hasn't yet built the tooling to sandbox agent behavior against such failures.
If you're an auditor, this is the frontier. The audits we've done for DeFi protocols are not enough for autonomous agents. They need runtime monitoring, anomaly detection, and circuit breakers that can step in when an agent behaves unexpectedly. In a world where the agent can move money in milliseconds, a human-in-the-loop is necessarily too slow. We need automated safety layers.
The infrastructure is behind the narrative. It always is.
A Manifesto for Infrastructure Honesty
I have a habit of wrapping up long pieces with a set of principles. Call it the economic strategist in me. What I'm about to say isn't a technical standard, but a proposal for cultural change. I think we, as an industry, need to adopt what I call "infrastructure honesty." It's a simple ethos.
First, disclose your trust assumptions. Every protocol should publish a simple document that lists the points of centralization, the privileged roles, and the recovery procedures. It shouldn't be buried in a 100-page whitepaper. It should be in the dashboard, right next to the TVL and the token price.
Second, separate your centralization layers. It's okay to have a centralized government agency or a centralized sequencer, but don't put them in the same layer. If you have a centralized sequencer, don't also add a centralized oracle. If you have a multi-sig, don't also use a custodial wallet. The goal is to avoid a single point of failure that spans multiple layers.
Third, audit your roadmaps. This is my personal favorite. Every roadmap should be paired with a set of measurable decentralized milestones. A roadmap that doesn't ship any hard steps toward decentralization is just a marketing tool.
Fourth, build for adversarial environments. We in crypto often make the mistake of designing for cooperative environments. But the value of blockchain is that it works even when some participants are malicious. Design your AI agents to expect malicious infrastructure. Test your APIs against hostile input. Assume the sequencer will censor, and build a fallback mechanism.
Fifth, reward the uncomfortable voice. We need more people in crypto who are willing to say "this is centralized" and be appreciated for it. Instead of attacking them for being negative, we should listen to see if they've spotted a real gap in the security model. The culture of perpetual optimism is killing our ability to self-analyze.
Lessons from a Personal Failure
I've been writing for almost twelve hours now, and I want to come back to something deeply personal. The reason I care so much about this topic is because I've been burned by the gap between narrative and reality.
In 2020, I lost my savings to a yield farm that was marketed as fully audited and decentralized. It wasn't. The audit was superficial, and the developers had a backdoor. I spent months re-analyzing the post-mortem, learning the exact mechanics of the exploit. It wasn't just a smart contract bug. It was a failure of infrastructure honesty.
The team had said "the code is law," but the code had a hidden admin function. When I called them out, they said it was "a safety feature." The community burned out the project. The money was gone, but the lesson remained.
Since then, I've learned to look at the actual flows. Who can change the code? Who can pause the system? Who can freeze the money? These are the questions that matter, and they matter more and more as we move toward AI agents. We are creating systems that can execute human intentions at machine speed. Those systems need to be transparent, reviewable, and unforgiving of hidden centralization.
I'm not saying the industry is doomed. I'm saying the industry needs to grow up. We can no longer afford to be idealistic children who believe every twitter post about "decentralized AI." We need to be pragmatic engineers and rigorous auditors.
The Power of the Meme
There's another angle I want to touch on before the conclusion. The narrative of decentralization is itself an asset that influences behavior. When people believe something is decentralized, they act differently. They are more willing to trust, to take risks, to put their money at stake.
This is not necessarily good or bad. It's a psychological force that moves markets. But it becomes dangerous when the narrative is false. A false sense of decentralization creates a false confidence premium. Users over-invest in systems that can be subverted, and the market doesn't correctly price the risk.
I've seen this with so-called "DAOs" that are, in practice, a small team making all decisions. The token price trades as if the DAO is a meritocratic community that will make wise decisions over time. But the reality is that a handful of insiders can push any proposal through by accumulating votes. The optics of decentralization feed the meme, and the meme feeds the value.
We need to separate the meme from the mechanism. A decentralized meme with a centralized mechanism is a time bomb, not a store of value.
A Look Ahead
When people ask me what the future holds for crypto infrastructure, I usually say: transparency.
The next great leap in this industry won't be a new consensus algorithm or a faster virtual machine. It will be a cultural shift toward radical honesty about how systems actually work. We'll build better dashboarding that shows trust assumptions in real time. We'll create decentralized reputation systems for infrastructure operators. We'll hold regular audits not just of smart contracts, but of the entire operational stack, including the sequencer, the relayer, the oracle, and the governance multi-sig.
This is the only way to build the trust that the mainstream will eventually demand. When the next billion users come to crypto, they won't rely on the crypto-native ethos of "don't trust, verify." They will rely on the systems being genuinely trustworthy. The only way to make that happen is to stop hiding the human hand.
We didn't get into this industry to pretend that a centralized company is a decentralized protocol. We got into it because we believed in a technology that could make the internet more open, more equal, and — yes — more trustworthy. That vision is still alive. But it's threatened by the same centralization forces that can creep into any complex system.
So I'll end with a question I've been asking myself. If we can't be honest about the centralization we have today, how can we possibly be trusted with the decentralization of tomorrow?
References and Disclosures
Everything I've written is based on my personal experience as an analyst and platform builder since 2017. I hold no positions in any project mentioned in this article. I have audited several protocol architectures as part of my work, but all opinions here are my own. The industry examples are drawn from public data and my own audits, but some details are deliberately anonymized to avoid singling out specific teams. I want to encourage the community to replicate the trust-assumption analysis I described here, to verify claims, and to publish findings. This is how we build a culture of safety and honesty. Let's not just talk about decentralization. Let's practice it.
