Pantera Capital published Building Permissionless Neobanks. The piece breaks down banking into four core functions — Store, Spend, Grow, Borrow — and maps out crypto projects trying to wedge into each function on their way to becoming full neobanks. It's an intuitive and well-organized framework.

If mobile gave us the neobank, crypto gives us the permissionless neobank. SoFi started with student loan refinancing, Revolut with low-cost cross-border payments, Chime with early paycheck access. Each captured a customer relationship by solving a specific pain point, then expanded into full banking. Crypto neobanks will follow the same playbook. The question is which wedge to start from.

Store (wallets) owns the entry point, but building a neobank from a wallet alone is hard. Users need to be actively doing things inside the wallet. That's why Metamask added a card and Phantom added in-app perps. Spend (payments) is already commoditized — stablecoin cards are table stakes, and the real move is toward next-gen payment methods like QR-based stablecoin payments. At the chain level, merchant acquisition is the main competitive dimension.

The article's framing of onchain's core value proposition as "making money fast" is sharp. From that thesis, Grow and Borrow — where capital velocity and user engagement are highest — are the best wedges for building a crypto neobank. I agree. EtherFi's path from liquid staking to DeFi strategy vaults to card issuance is a textbook example.

There's also an interesting tension between going local (integration with local partners/infrastructure, specific target customers) versus global (leveraging the permissionless nature of crypto). My take is that the answer satisfying both is "hyper-specific target audience that exists globally." Think a neobank for underage TikTok/YouTube creators — the user segment is extremely narrow, but they're distributed across the entire world.

Lastly, among projects pushing the crypto neobank narrative from a privacy angle, Seismic stands out the most. They already have three design partners: Specie (B2B neobank), Cred (private credit service), and Brookwell (retail neobank). Quietly executing.

Giving an AI agent wallet access is currently all or nothing. Hand over the private key and the agent can do literally anything — prompt injection, hallucination, or a bad strategy can drain funds. Don't hand it over and the agent is useless. There's no way to say: "You can swap up to $500/day on these three tokens, and anything above that needs my approval."

Vincent is an open-source security layer that solves this at the architecture level. The core design principle is complete separation between the AI runtime and credentials. Instead of the agent accessing keys directly, it requests actions through Vincent, which evaluates a policy stack and then executes against an airgapped vault powered by Lit Protocol.

Policies are designed as a composable stack. Daily spending limits, action restrictions (only swaps and transfers allowed, no approvals or bridge calls), hourly transaction rate limits — rules stack on top of each other. The key point is that these aren't application-level guardrails where the AI "decides to be careful." They're infrastructure-level constraints that the AI physically cannot bypass. Even if the AI is fully compromised via prompt injection, secrets remain untouched.

For high-value transactions, Vincent supports n-of-m multi-party approval. Below the threshold, auto-executed within policy. Above the threshold, a configured number of humans approve directly in Telegram. "My agent drained $1,800 at 3 AM" becomes "my agent flagged an $1,800 swap and waited for approval."

Compared to existing agent security solutions: Privy offers server-side key management with per-wallet policies. Coinbase Agentic Wallets use TEE enclaves with session/transaction caps. Vincent's differentiator is providing an airgapped vault (Lit Protocol), composable policy stack, n-of-m approval, and full audit logging — all open source. As agentic wallet infrastructure matures, the distinction between "AI choosing to be careful" and "AI having no choice but to be careful" will become increasingly important.

The New York Fed published Stablecoins vs. Tokenized Deposits: The Narrow Banking Debate Revisited. It models whether blockchain-native money should be stablecoins or tokenized bank deposits.

The difference between the two ultimately comes down to backing assets. Stablecoins are 100% backed by safe assets like government bonds. Tokenized bank deposits are backed by a mix of loans and safe assets. Because deposit insurance protects depositors even if a bank fails, banks have an incentive to lend aggressively. The government imposes regulation to keep this in check. Stablecoin issuers only hold safe assets, so they don't need any of that regulation.

The paper's main message is that there's no single right answer:

• When regulatory costs are high and banks aren't overlending: allowing only tokenized deposits is better. Banks can extend more credit, which helps the economy.

• When regulation is light and banks are overlending: allowing only stablecoins is better. It curbs banks from reckless lending.

• In between: letting both compete is optimal.

What makes this different from the historical "narrow banking" debate (the idea that money-creating institutions should only hold safe assets) is scope. The 1930s Chicago Plan and the recent TNB (The Narrow Bank) case in the US tried to apply narrow banking to the entire banking system. This paper only applies it to money used in blockchain transactions. Even if stablecoins are required to be fully backed by safe assets, banks can still issue traditional deposits and make loans. You can have safe money in crypto without killing banks' ability to create credit.

What happens as crypto grows? If existing payments are migrating to blockchain, tokenized deposits become more important. Demand for traditional deposits shrinks, giving banks room to compete in the crypto market. But if blockchain transactions are net new activity, stablecoins become more important. When total money demand expands, banks alone can't keep up.

I've previously written about arguments against tokenized deposits, and my position was: "tokenized deposits can't replace stablecoins, but I can't agree they have no reason to exist." This paper backs up that intuition. Stablecoins and tokenized deposits aren't substitutes — they're complements. Stablecoins are an efficient channel for turning safe assets into money. Tokenized deposits are a channel for enabling bank lending. The optimal mix depends on the regulatory environment. What matters in the end isn't who issues the money, but what assets are behind it.

Pantera Capital published Building Permissionless Neobanks. The piece breaks down banking into four core functions — Store, Spend, Grow, Borrow — and maps out crypto projects trying to wedge into each function on their way to becoming full neobanks. It's an intuitive and well-organized framework.

If mobile gave us the neobank, crypto gives us the permissionless neobank. SoFi started with student loan refinancing, Revolut with low-cost cross-border payments, Chime with early paycheck access. Each captured a customer relationship by solving a specific pain point, then expanded into full banking. Crypto neobanks will follow the same playbook. The question is which wedge to start from.

Store (wallets) owns the entry point, but building a neobank from a wallet alone is hard. Users need to be actively doing things inside the wallet. That's why Metamask added a card and Phantom added in-app perps. Spend (payments) is already commoditized — stablecoin cards are table stakes, and the real move is toward next-gen payment methods like QR-based stablecoin payments. At the chain level, merchant acquisition is the main competitive dimension.

The article's framing of onchain's core value proposition as "making money fast" is sharp. From that thesis, Grow and Borrow — where capital velocity and user engagement are highest — are the best wedges for building a crypto neobank. I agree. EtherFi's path from liquid staking to DeFi strategy vaults to card issuance is a textbook example.

There's also an interesting tension between going local (integration with local partners/infrastructure, specific target customers) versus global (leveraging the permissionless nature of crypto). My take is that the answer satisfying both is "hyper-specific target audience that exists globally." Think a neobank for underage TikTok/YouTube creators — the user segment is extremely narrow, but they're distributed across the entire world.

Lastly, among projects pushing the crypto neobank narrative from a privacy angle, Seismic stands out the most. They already have three design partners: Specie (B2B neobank), Cred (private credit service), and Brookwell (retail neobank). Quietly executing.

Giving an AI agent wallet access is currently all or nothing. Hand over the private key and the agent can do literally anything — prompt injection, hallucination, or a bad strategy can drain funds. Don't hand it over and the agent is useless. There's no way to say: "You can swap up to $500/day on these three tokens, and anything above that needs my approval."

Vincent is an open-source security layer that solves this at the architecture level. The core design principle is complete separation between the AI runtime and credentials. Instead of the agent accessing keys directly, it requests actions through Vincent, which evaluates a policy stack and then executes against an airgapped vault powered by Lit Protocol.

Policies are designed as a composable stack. Daily spending limits, action restrictions (only swaps and transfers allowed, no approvals or bridge calls), hourly transaction rate limits — rules stack on top of each other. The key point is that these aren't application-level guardrails where the AI "decides to be careful." They're infrastructure-level constraints that the AI physically cannot bypass. Even if the AI is fully compromised via prompt injection, secrets remain untouched.

For high-value transactions, Vincent supports n-of-m multi-party approval. Below the threshold, auto-executed within policy. Above the threshold, a configured number of humans approve directly in Telegram. "My agent drained $1,800 at 3 AM" becomes "my agent flagged an $1,800 swap and waited for approval."

Compared to existing agent security solutions: Privy offers server-side key management with per-wallet policies. Coinbase Agentic Wallets use TEE enclaves with session/transaction caps. Vincent's differentiator is providing an airgapped vault (Lit Protocol), composable policy stack, n-of-m approval, and full audit logging — all open source. As agentic wallet infrastructure matures, the distinction between "AI choosing to be careful" and "AI having no choice but to be careful" will become increasingly important.

The New York Fed published Stablecoins vs. Tokenized Deposits: The Narrow Banking Debate Revisited. It models whether blockchain-native money should be stablecoins or tokenized bank deposits.

The difference between the two ultimately comes down to backing assets. Stablecoins are 100% backed by safe assets like government bonds. Tokenized bank deposits are backed by a mix of loans and safe assets. Because deposit insurance protects depositors even if a bank fails, banks have an incentive to lend aggressively. The government imposes regulation to keep this in check. Stablecoin issuers only hold safe assets, so they don't need any of that regulation.

The paper's main message is that there's no single right answer:

• When regulatory costs are high and banks aren't overlending: allowing only tokenized deposits is better. Banks can extend more credit, which helps the economy.

• When regulation is light and banks are overlending: allowing only stablecoins is better. It curbs banks from reckless lending.

• In between: letting both compete is optimal.

What makes this different from the historical "narrow banking" debate (the idea that money-creating institutions should only hold safe assets) is scope. The 1930s Chicago Plan and the recent TNB (The Narrow Bank) case in the US tried to apply narrow banking to the entire banking system. This paper only applies it to money used in blockchain transactions. Even if stablecoins are required to be fully backed by safe assets, banks can still issue traditional deposits and make loans. You can have safe money in crypto without killing banks' ability to create credit.

What happens as crypto grows? If existing payments are migrating to blockchain, tokenized deposits become more important. Demand for traditional deposits shrinks, giving banks room to compete in the crypto market. But if blockchain transactions are net new activity, stablecoins become more important. When total money demand expands, banks alone can't keep up.

I've previously written about arguments against tokenized deposits, and my position was: "tokenized deposits can't replace stablecoins, but I can't agree they have no reason to exist." This paper backs up that intuition. Stablecoins and tokenized deposits aren't substitutes — they're complements. Stablecoins are an efficient channel for turning safe assets into money. Tokenized deposits are a channel for enabling bank lending. The optimal mix depends on the regulatory environment. What matters in the end isn't who issues the money, but what assets are behind it.