It was a glitch, obviously. And after 22 minutes, the 300 Trillion in question was burned, just as easily as it was created.

Ironically, this isn’t PayPal’s first brush with astronomical numbers. In 2013, the payment app mistakenly credited a user’s account with $92 quadrillion, then reversed the error before the user even noticed.

In a centralized database, errors like that are mostly harmless. The user can’t actually move that kind of money out of PayPal, and even if they could the risk is contained to Paypal only.

On-chain issuance is a different story, however. The ability to mint a deeply-integrated, deeply liquid asset like PYUSD out of thin air is a systemic risk to DeFi, and 22 minutes is plenty of time to do real damage.

This one was a mistake and it was fixed fast. But it does expose a bigger issue: asset issuance still lacks basic guardrails.

If mint authority is compromised, the outcome will be catastrophic.

Which brings us to this piece’s theme: how issuance works for centralized stablecoins and what a safer issuance stack should look like.

The problem: non-verifiable reserves

Fiat stablecoins are supposed to be fully backed by their underlying fiat currency. For example, for every dollar on-chain, there should be a matching dollar (or dollar-equivalent) in dedicated reserves.

So how did Paxos end up minting 300 trillion PYUSD when there clearly weren’t enough off-chain reserves to back it? Because the mint function was executed without consulting off-chain reserves first.

Most fiat-backed issuance designs used today rely heavily on trust ( and monthly attestations). On-chain mint/burn is gated by issuer permissions, not by querying off-chain reserve balances.

That means there are no safety measures at the protocol-level to halt mints if that control is compromised or is triggered with the wrong parameters, which is what happened with PYUSD.

Stablecoins have clearly hit escape velocity. PayPal’s PYUSD is only the beginning. Multiple Web2 businesses announced plans to explore or issue their own stablecoins because the rails offer structural advantages for moving and storing value.

But if businesses are coming on-chain at scale, the issuance infrastructure has to level up in order to meet this demand. For this to happen, protocol-level verifiability of off-chain reserves is a must.

The good news: @m0 saw this coming years ago and built accordingly.

I think this is a good moment to dig into their issuance mechanism, among other features, and why it matters.

The M0 Issuance Stack

Before we get into M0’s design, let’s quickly recap how things work with centralized issuers:

1. Distributor submits mint instructions (stablecoin, chain, destination address)

2. Distributor wires funds to the issuer’s bank

3. Issuer mints tokens and transfers them to the distributor’s wallet

This design works but it comes with real drawbacks for distributors:

• Issuer-absolute mint power: A privileged signer can mint. Distributors can’t constrain it on-chain.

• Trust-heavy, off-chain operations: With the exception of mint/ burn functions, everything else (reserves proofs, branded issuance, profit sharing) is coordinated off-chain.

Now, how does M0 address this?

1. M0 Protocol Actors

M0 isn’t a company, it’s a protocol. A coordination layer that enforces a set of parameters for all actors to abide by.

Governance-Approved Actors:

• Minters (issuers): Qualified entities with mint power proportional to eligible collateral held in Special Purpose Vehicle (SPV) that meet M0 governance-adopted requirements.

• SPV Operators (custody): Independent operators of the SPVs that control the custody accounts and enforce protocols designed to protect the stability of issued assets.

• Validators (auditing): Independent firms engaged by Minters to verify eligible collateral and post regular proofs.

• Earners (distributors): Holders of M0 stablecoins (and branded extensions) who share in earnings generated by off-chain collateral.

  Note: Minters, Validators and Earners have to be approved by governance and are bound by M0's Adopted Guidance in order to participate in the protocol's activities.

2. Off-chain custody stack

M0 tightens issuance by separating duties and defining how Actors interact, even off-chain:

→ Minters do not control custody. Instead, they sign a legally binding agreement with an SPV Operator, who manages collateral to protect the stability of issued assets in all conditions.

→ Validators have read access to Custody Accounts and are required to publish regular proofs on Eligible Collateral.

3. On-chain mint flow

Note: $M refers to M0’s dollar-pegged stablecoin and the protocol’s canonical unit.

With the custody and attestations design in place, issuance on M0 is reserve-aware and challengeable at the protocol-level:

Minting basically boils down to two moves:

1. Update collateral: Every ~30 hours, Minters publish their Eligible Collateral on-chain with a valid Validator proof. Failure to do so incurs a penalty fee.

2. Request mint: Minters request the amount of $M to issue. The request is checked against on-chain Eligible Collateral and held for a delay window during which Validators can halt the mint if something looks off.

This architecture would have halted the 300T $PYUSD mint event if Paxos was leveraging the M0 stack:

4. Collateral Retrieval flow

M0’s custody design means Minters don’t control the SPV’s custody accounts.

So how do they pull out free collateral (e.g., after burning $M)? Via an on-chain, validator-gated retrieval flow:

→ Deducting the proposed amount immediately from on-chain collateral ensures the Minter remains adequately collateralized throughout the process.

→ On-chain logic initiates the flow, the SPV Operator executes the transfer and Validators attest to the validity.

→ Just like mints, outflows are reserve-aware and challengeable.

Closing thoughts

With reserve-aware issuance and protocol-level safeguards, M0 makes issuance verifiable instead of trusted. Which is critical, in order to reduce the attack surface and operational error risk.

But that's not all. The M0 stack innovation extends beyond issuance to unlock the best building experience for Apps wanting to issue their own stablecoins: fully customizable, yield-bearing, branded stablecoins with interop and liquidity baked in.

I'll be writing about it on my next article.

About a year ago, Plasma landed in Cobie’s group on Echo at a 40m FDV. I was among those who had access to the deal but ended up passing.

At the time, I dismissed Plasma as “just another L1.” Payment-focused infra always made sense imo, but I believed success hinged on tackling the first/last mile problem: Sure, I can send USDT instantly and for free across the world, but the receiver still has to off-ramp somewhere else to actually spend it locally.

Fast forward to last week…

Plasma TGE’d with one of the strongest launches this cycle. That stung. Enough to send me down a deep dive. Nothing like missing out on life-changing money to make you rethink your thesis, right?

So, was I wrong? Obviously. But I still believe Plasma’s biggest unlock will come from solving the first/last mile problem at the protocol level. The good news? The tech that actually solves this is already here.

This piece is my attempt to dig into that problem, go through some of the use cases and why solving it could be Plasma’s real unlock.

Understanding the problem

To clarify, this isn’t a global issue. First/last mile friction mostly shows up in emerging markets with weak/ informal banking systems.

WTF is First/last mile

Let’s take cross-border payments (aka remittances) as an example.

Sending 100$ from the US to Tunisia via Western Union looks like this:

• First mile: Accepting dollars from the sender

• Middle mile: Western Union rails handle cross-border transfer, FX conversion and liquidity

• Last mile: Delivering pesos to the receiver

Now replace Western Union with stablecoins:

Acquiring stablecoins in a developed economies is a relatively seamless process. Off-ramping them into Dinars in Tunisia? Not so much. The options are plenty: P2P markets, crypto debit cards or even an in-person cash exchange. All come with their own trade-offs.

They do have one thing in common though: far from seamless.

And this isn’t just Tunisia. Across emerging markets, the same story repeats.

On top of that, stablecoins in emerging markets often come at a premium thanks to constant demand for dollars.

This is where Plasma One enters the picture. As a neobank and card native to the chain, it tackles the last mile by letting users spend USDT via the Plasma One card in supported countries (+150).

But Plasma One scaling has limits. Card coverage will always depend on local regulations. And it can’t solve the first mile either, users still need to source USDT elsewhere before deploying it on Plasma.

So here’s an idea: what if Plasma can lean on its permissionless design to fill the gap Plasma One can’t, and solve both the first and last mile?

Native P2P markets: The missing piece

That stablecoin adoption is highest in emerging markets shouldn’t surprise anyone. As policies tighten, more people look for stable alternatives.

But no matter how strong that demand gets, it’s unlikely we’ll see regulated venues openly selling USDT. It cuts against the point of those monetary policies, which aim to keep hard currencies flowing in, not out.

That vacuum has fueled crypto<>fiat P2P markets, especially on CEXs.

What began as a workaround for onboarding users in emerging markets is now a standalone business line, processing millions in volume daily.

Which raises the obvious question: if the goal is to build an all-in-one money app, why send users off-platform to hunt for USDT before they can even touch the Plasma ecosystem? Why not let them acquire it directly inside the app in a trustless, permissionless way?

How? Put CEX-style P2P markets on-chain.

And here’s the kicker: someone’s already done it.

In my last piece, I broke down ZKP2P, a project solving a major blocker for crypto: permissionless crypto<>fiat interop.

https://x.com/EarlMontagu/status/1970939210975641929

I recommend reading it for full context but the tl;dr: they took CEX P2P markets, stripped out the middlemen and brought them on-chain. It supports any real-time payment network, any currency and uses cryptographic proofs to verify off-chain payments.

This is where Plasma’s permissionless design kicks in.

With ZKP2P-style rails baked into the chain, Plasma doesn’t just fix onboarding. It unlocks a set of use cases that could finally make it the full-stack payments product it aims to be.

Here are a few that come to mind.

Use Case 1: Cross-Border Fiat-to-Fiat Transfers

Here’s how Fiat-to-Fiat looks like with Plasma One:

1. First mile: Sender on-ramps into Plasma One

2. Middle mile: Free in-app USDT transfer from sender to receiver

3. Last mile: Receiver cashes out at an ATM with the Plasma One card

Good but limited. The moment someone’s outside a supported country, or doesn’t have a card, the flow breaks. And it gets worse if the sender is in a non-supported region.

Now imagine Plasma with both native P2P markets and the card. With both built into the chain, users can move freely between the app and real-time payment networks, no matter where they are.

That’s all it takes to enable true fiat-to-fiat transfers, anywhere. And the best part? App users won’t even realize the whole thing is powered by USDT under the hood.

Use Case 2: Payment Service Provider

In many emerging markets, international card payments are still restricted. Friends and family sometimes ask me to book a flight or an Airbnb on their behalf, paying me back in cash.

With native P2P markets covering the first mile, a temporary virtual Plasma One card covering the last mile and everything in between handled trustlessly by smart contracts and USDT, that workaround disappears.

Users, from anywhere, can make online payments directly from the Plasma One app.

That means someone in a restricted market could pay for ChatGPT, stream Netflix or shop online for whatever they want. That’s not just cool, it’s freedom to access the same digital services the rest of us take for granted.

Final thoughts

The chain that will win payments won’t be the one that moves stablecoins the fastest or the cheapest. It’ll be the one that nails distribution…

The neobank + card model can’t do that on its own. It will always be tethered to traditional banking rails and that limits how far it can scale.

That’s exactly why stablecoins blew up in struggling economies: people needed rails that worked outside the system.

In order to truly redefine how money moves, having native P2P rails alongside the neobank/ card is a must. Together, they create the only setup that can scale globally and serve emerging markets.

Earlier this year, MegaMafia opened applications for its second cohort to find the next wave of breakout apps launching on MegaETH.

One section asked applicants to choose a question from a list and answer it.

I went for this one: “Bonding curves have become a core mechanic in breakout apps. What’s the next big design mechanism that will unlock new user behavior at the app level?”

My answer: zkTLS.

MegaMafia’s answer: thanks, but no thanks. I didn’t make the cut.

Many months later and we’ve yet to see a zkTLS-powered breakout app. But I think that’s about to change.

Below I dig into an overlooked protocol tackling crypto’s biggest pain point: web2-web3 interoperability, and drop in a feature-request to the team while at it: ZKP2P

WTF is zkTLS?

I’m not gonna bore you with technical jargon and even if I wanted to, I’m not qualified. Instead, let’s walk through a real-life example:

While attending ETH Cannes last year, Ben’s employer committed to cover his Uber rides to the conference venue and reimburse him in USDC upon providing proof.

Ben could wait until the end of the conference, send receipts, and wait again for review and refund. But that process is clunky, invades his privacy and isn’t fraud-proof for the company.

This is where zkTLS comes in. A cryptographic primitive that lets users export data securely and verifiably from any website while revealing only the minimum required.

In Ben’s case, he can share just the fare amount and destination address in a way the company can verify:

You might ask, “Why do we need a blockchain for this?”. We don’t.

The real unlock comes from submitting those attestations on-chain, so on-chain actions can be triggered based on off-chain behavior.

Back to Ben: what if his refund happened automatically the moment he left the car?

Today, that’s possible by combining zkTLS attestations with smart contracts:

With this setup:

• Ben gets refunded instantly after stepping out of his ride.

• He hides all unnecessary info from the Uber invoice. E.g., his pickup address, which just happens to be a nightclub (Ben was partying all night).

• The company is certain the invoice is authentic and saves time.

That’s how zkTLS and blockchains work together. Think of zkTLS as a bridge between web2 and web3, letting users bring verified web2 data on-chain and enabling use cases that simply weren’t possible before.

Automated expense reimbursement is cool, but it’s not exactly the killer app we’ve all been waiting for.

Now that we’ve got the basics down, let’s get into that part.

zkTLS killer app

The problem

For retail users, depending on their location, crypto⇄fiat swaps remain pricy, slow and/or unreliable.

The reason? Fiat on/off-ramp providers depend heavily on legacy banking rails, currency stability and each region’s regulatory environment. Making them sub-optimal for anyone who wants to on/off-ramp at a reasonable speed and a reasonable cost.

P2P markets, brought back by centralized exchanges, resurfaced as a reliable solution. By connecting local users to trade on their own terms, with transparent fees and broader fiat currency support, CEX P2P platforms are fast becoming the retail’s go-to solution for on/off ramps. But they’re hardly perfect:

• Users take on custody risk.

• Users rely on CEX to settle disputes.

This is where a blockchain + zkTLS combo really kicks into action: Smart contracts handle custody and zkTLS removes the need for human arbitration.

That’s exactly what ZKP2P is building.

Enter ZKP2P

Simply put, ZKP2P is an on-chain version of CEX P2P markets. Except it’s faster, trustless, and composable with on-chain activity. Here’s how it works:

Think of ZKP2P as a two-sided marketplace for crypto ⇄ fiat swaps.

• Supply side: sellers lock up USDC and set limit orders.

• Demand side: buyers fill those orders when the quotes make sense.

The first visual uses an example of Revolut as payment network platform and USD as currency to keep things simple, but the reality is broader.

ZKP2P is platform-agnostic & currency-agnostic, the protocol can support any payment network and any fiat currency as long as sellers are willing to accept payments there.

With eight payment platforms supported, USDC liquidity across 20+ fiat currencies and +$3.4M in total volume, ZKP2P has already gained traction and quickly found PMF as the go-to ramp for on-chain natives.

Compared to ZKP2P, CEXs P2P markets fall short on speed, custody, cost and composability but still holds one advantage: Liquidity.

Liquidity is the last moat. Remove it and ZKP2P becomes the default on-ramp. The question is how to spark that momentum?

Cold starts and network effects aren’t solved overnight, but a few smart features could narrow the gap and draw in more liquidity.

Fiat-side LPing: ZKP2P’s missing piece

The current design of ZKP2P relies entirely on USDC-side LPs ( offrampers) to function.

Meaning that only USDC sellers are able to dictate terms. So if no one locks USDC, ZKP2P cannot function.

This is a feature, not a bug. We can rely on smart contracts to enforce the conditions of the exchange —i.e., release the USDC ONLY IF the proof is valid— but the same cannot be said about humans. That’s what makes ZKP2P-powered swaps trustless.

But this design introduces significant limits, especially when compared to CEX P2P markets:

• USDC sellers cannot offramp quickly. They must wait for a buyer to come in.

• Buyers are forced to choose from existing rates and sizes, preventing them from expressing their own bids.

• Spreads are wide and liquidity thin because LPing is one-sided.

• Growth of supported markets and expansion to new ones depends entirely on USDC LPs.

That got me wondering: could ZKP2P add a way for onrampers to LP just in an equally-trustless manner?

The mechanics I have in mind aren’t far off from existing flow. But they do require an extra step:

1. Intent: the fiat LP (onramper) expresses intent with a tx specifying currency, amount, rate and Telegram ID (optional).

2. Escrow: a USDC seller (offramper) who likes the terms locks the required USDC and adds his off-chain payment ID.

3. Payment: the fiat LP makes the off-chain payment to that ID and submits a proof with zkTLS extension.

4. Settlement: a valid proof triggers the smart contract to release the escrowed USDC to the fiat LP.

The fiat-side LP experience might not be as slick as USDC LPing as the intents are collateral-free and the extra step can slow things down. But a tight escrow window, in-app chat (like CEX P2P markets) and Telegram alerts can smooth it out.

The trade-off is a bit less speed, but the protocol stays fully trustless. And the upside is huge:

• Faster fills for USDC sellers. No waiting for buyers to appear

• Tighter spreads with both sides able to dictate their own terms

• Deeper liquidity overall

• Native market-making on ZKP2P: Today USDC LPs earn yield by selling at a premium, but to keep doing that they have to re-onramp somewhere else. Fiat-side LPing closes that loop.

Final thoughts

Recently Venmo announced an upcoming integration with Paypal, enabling immediate, seamless transfers between the two platforms. Cool, right? Not really… Apparently it took them 12 years to make it happen.

Now imagine how long will it take for all platforms to talk to each other.

ZKP2P is uniquely primed to solve this much faster. And by this I mean: interoperability between off-chain payment platforms.

Enabling LPing on the fiat side is the first step for the protocol to evolve beyond bilateral crypto ⇄ fiat swaps, to enable multi-lateral fiat-to-fiat swaps. The use cases that can be unlocked are endless; my next post will dive into some of them.

That's it. That’s the killer feature: borderless, near-instant fiat-to-fiat swaps powered by crypto rails in the middle.

Despite DeFi's maturity, most users remain locked out of its most lucrative yield opportunities. Tapping into MEV, arbitrage and complex yield strategies remains, for the most part, exclusive, limiting the average user’s choices to wrapped TradFi products and “player vs. player” schemes when pursuing yield.

Current solutions fall into two categories, each with distinct limitations:

1. Single-strategy products, such as Ethena's sUSDe focusing on funding rate arbitrage, leaving users vulnerable to changing market conditions.

2. Modular solutions like Morpho connect users with yield curators but shifts risk assessment to users who often lack the qualifications for the task.

This isn’t, in any way, a critic to Ethena or Morpho ( both are great products imo) but rather the challenges facing the average user when pursuing yield on DeFi.

Not to add that both approaches share a critical flaw: users bear full responsibility for losses from exploits, insolvencies, or rugs, in return for a significantly limited upside potential.

Enters CAP, a Stablecoin engine attempting to solve these frictions through a three-sided marketplace:

1. Lenders: Users deposit capital into asset-specific CAP Stablecoins

2. Yield Experts: Vetted Agents compete to generate yield using deposited assets

3. Guarantors: EigenLayer Restakers provide risk coverage in exchange for a share of the profits

In addition, CAP will leverage this marketplace to power native asset issuance on MegaETH, unlocking additional yield sources for CAP stablecoins.

That’s the what. Does it sound complicated? Only if you stop here. Read on to learn how CAP will achieve this, with illustrations.

Let’s start by addressing the elephant in the room:

Yield strategies on CAP - AKA where does the yield come from?

At its core, yield in crypto could be split into two categories:

• Endogenous yield

  This refers to revenue generated purely from in-protocol mechanisms. As an example, consider Maker’s DAI where the protocol relies on borrowing fees paid by direct users to generate yield.

• Exogenous yield

  This refers to out-of-protocol mechanics where the protocol exploits external market inefficiencies/ opportunities to generate yield. Take USDe as an example: Ethena deploys users’ capital to capture funding rate arbitrage opportunities and redirect revenue back to users, minus the protocol's commission.

CAP focuses on exogenous yield generation (not exclusively, but more on this later). But instead of executing strategies directly, CAP creates a competitive environment where specialized yield curators (Agents) regularly bid for the opportunity to borrow assets deposited on CAP. Here's how it works:

• Lending market Structure

  • A separate market is maintained for each asset.

  • A hurdle rate ( minimum acceptable return) is assigned to each market

• Competitive Bidding Process

  • Agents submit bids specifying: desired loan amount and estimated return for CAP depositors

  • Any bids that do not meet the hurdle rate are automatically filtered out

  • CAP allocates capital to agents that meet the hurdle rate, prioritizing the highest-yielding bids

Below is an illustration of what the lending market for USDC, one of the assets backing CAP’s USD stablecoin, could look like:

Implementing a hurdle rate, at least initially, will guarantee depositors a minimum return and filter-out any suboptimal bids from agents trying to get more favourable borrowing rates.

By prioritizing the highest bidders when allocating loans CAP ensures automatic capital reallocation to highest-performing strategies, regardless of market conditions.

At the same time, accommodating a diversified set of Agents solves yield’s biggest bottleneck, scalability:

Yield opportunities persist in all market conditions, but maintaining optimal exposure in an ever-changing market is challenging. CAP’s approach of an asset-specific, unified pool of capital which multiple agents, specializing in different domains, can concurrently tap into solves this and presents an optimal solution for scalable competitive yield.

CAP’s success will depend, significantly, on the protocol’s ability to attract borrowing demand. ie, why would agents borrow from CAP instead of other markets?

CAP’s value proposition to borrowers is analogous to flash loans - the backbone of many complex DeFi strategies - but with the benefits of extending the zero-collateral requirement from one block to a few days, and the possibility of deploying capital not just to a specific chain but anywhere.

Another competitive feature CAP’s design unlocks is allow protocols offering specific yield strategies to tap into the Cap’s large pool of assets by onboarding them as agents. Think of this as a better alternative for protocols to scale their proven strategies compared to the overhead and uncertainty of liquidity mining campaigns. For example, Ethena could borrow stablecoins directly from CAP's pools to power their funding rate arbitrage strategy.

So what happens when an agent doesn’t repay borrowed funds? - Those of you who are still following

The short answer is CAP leverages EigenLayer’s economic security marketplace to cover defaulting risks. Keep reading for the long answer.

CAP’s productivity-based incentives on EigenLayer

If you’re not familiar with EigenLayer, I highly recommend checking CAP’s post before continuing.

So far, EigenLayer use cases have been limited to leveraging capital provided by Restakers to underwrite risk for technical tasks performed by Operators. However, with a TVL north of $23B and less than 60 AVS’, is it fair to assume the demand for validation services hasn’t been able to match the supply of capital deposited to earn yield by Restakers on EigenLayer.

If we zoom out, EigenLayer’s trust marketplace extends beyond mere validation services to one where restaked capital can underwrite risks for any type of productive activities.

CAP leverages this framework, by taking advantage of the yield-seeking idle capital on EigenLayer, to introduce a productivity-based service where Restakers delegate capital to underwrite risk for Operators focusing on generating yield.

In other words, CAP will use EigenLayer to allow anyone to be an Agent and source cost-free capital from CAP’s Stablecoins to generate yield, as long as they have enough economic security from restakers to cover shortfalls.

Sounds complicated? Let’s try with an illustration of an Agent looking to borrow ETH:

You would notice that the illustration used the worst outcome possible for the failure scenario: total loss of funds. This is highly unlikely ( but it helps demonstrate that even in the worst case CAP deposits remain safe.

Instead, I expect partial loss of funds and repayment delays to be the main failure reasons. In which case Restakers will be subject to minor slashing penalties.

Powering MegaETH with yield-bearing CAP stablecoins

So far we’ve covered yield sources and risk management on CAP, but nothing about Stablecoins issuance or MegaETH.

In this part we’ll explore CAP’s key role as the issuance layer for yield-bearing assets on MegaETH, and potentially powering all the chain’s native dApps.

Let’s zoom out for a bit and consider bridging: A bridge allows users to convert tokens that are native to one chain into a representation of those tokens on another chain. Take $ETH issuance on L2s as an example, it’s all done by locking the equivalent amount of $ETH in a smart contract on Ethereum mainnet. Thus, guaranteeing enough backing, even on worst case scenarios when everyone redeem bridged assets at once.

Similarly, assets deposited into CAP are also locked in smart contracts on Ethereum, and while they’re not idle assets they are always fully backed by Restakers’ collateral, if borrowers default.

This enables the tokenisation of CAP deposits, and the yield they generate, on MegaETH.

From a design perspective, CAP is asset-agnostic and will accommodate any asset that could produce yield ( ie, with high-borrowing demand). But initially I would expect CAP to support for the following assets: USD, ETH and BTC. Let’s take a look at how that happens:

Minting stablecoins on CAP:

For every supported asset, a list of tokens to back CAP-token minting 1:1 are selected. For example, capUSD could be backed by deposits of USDC, USDT and potentially any other Stablecoin with high-borrowing demand.

CAP Stablecoins will be deployed as EigenLayer AVS’, meaning that any deposits will take place on Ethereum mainnet but to simplify the UX, users will be able to do so directly from MegaETH where they will receive the issued CAP Stablecoin.

“Now that I’ve minted capUSD, does that mean I’m already earning yield?” - You, just now.

Not exactly, CAP adopts a dual-token design for every Stablecoin:

• stableTOKEN: A token pegged to the asset, backed by deposits 1:1 that does not accrue any yield from CAP.

• yieldTOKEN: A yield-bearing token with exposure to CAP exogenous yield.

Why Two Tokens?

Each version enables different use cases and caters to different users

• yieldTOKENs are best suited for capturing passive yield, generated from borrowing demand from Agents on EigenLayer.

• stableTOKEN taps into active yield, enabled by native-MegaETH DeFi

In addition to the most-competitive yield, CAP aims to leverage MegaETH to offer its depositors more utility and capital efficiency for their assets. This is where the dual-design comes in:

• Enable leveraged exposure to CAP exogenous yield on MegaETH money markets via borrowing stableTOKEN against yieldTOKEN

• Enabling CAP Stablecoins as borrowable assets and settlement assets to unlock additional sources of revenue for depositors ( this can only be done with stableTOKEN)

• Integrating CAP stablecoins deeply within all MegaETH dApps to offer users more utility for their assets

If succeeded, CAP Stablecoins will offer the most competitive yield for any specific asset, regardless of market conditions. This will quickly lead to substantial growth in deposits, as yield-seeking users rotate to CAP.

The tokenization of, both, deposits and yield will take place on MegaETH. This will lead to CAP-issued Stablecoins becoming the most liquid and most adopted versions of any asset, and CAP becoming the canonical bridge to MegaETH which, in turn, will lead to more yield.

Conclusion

The idea of using economic security to underwrite risk for collateral-free loans is intriguing on its own, but when combined with the tokenization of positions on MegaETH—a high-performing blockchain— CAP has the potential to redefine the DeFi yield landscape entirely.

Of course, this doesn’t come without caveats. CAP’s success hinges on the effectiveness of EigenLayer’s slashing mechanism, as it acts as the backbone for protecting users’ deposits. This dependency introduces a layer of risk.

Another potential hurdle lies in scalability. Currently, EigenLayer boasts billions in idle capital waiting to underwrite risk for CAP’s yield agents. But what happens when borrowing demand outpaces the available economic security? This scenario could present an inflection point for CAP’s growth. However, considering EigenLayer’s current TVL of $23B, this seems like a distant problem and a good one to have as it would mean CAP succeeded.

That’s it for now! If you’ve made it this far, thank you for reading and I hope you found this helpful!