Abstract

Stablecoin competition has traditionally been framed around reserve composition, collateral quality, regulatory posture, or liquidity depth. The underlying assumption is straightforward: build a safer reserve, offer better yield, or secure broader distribution, and the market should naturally converge toward the superior dollar. Yet the last few years have demonstrated something noticeably different. Reserve portfolios can be reallocated, yield advantages disappear as interest rate cycles evolve, and competing issuers can replicate most technical innovations within months. Despite this, certain stablecoins continue to accumulate disproportionate economic activity while others remain largely interchangeable. The persistence of this gap suggests that the industry's conventional explanation for stablecoin adoption is incomplete. The question is therefore not simply why users choose a stablecoin, but why entire economic systems continue to organize themselves around one long after viable alternatives exist.

Existing discussions (that eventually shadow revenue side entrenchment)

In further reading we will argue and eventually prove that the answer may lie outside the reserve layer itself. Rather than viewing stablecoins as isolated financial products, it proposes treating them as participants in recurring financial workflows, that is, economic relationships that repeat predictably over time, such as remittances, payroll, merchant settlement, supplier payments, subscriptions, and treasury operations. Unlike the speculative trading/investing or short-lived yield incentives, these activities generate a persistent transactional demand and continuously reinforce the surrounding liquidity, market-making, wallet support, merchant acceptance, and operational infrastructure. Every recurring payment is therefore more than a transfer of value; it is another iteration in a self-reinforcing flywheel that gradually transforms a fungible digital dollar into an increasingly embedded financial rail. This paper explores whether those recurring workflows, rather than reserve composition itself, constitute an overlooked dimension of stablecoin entrenchment.

The stablecoin revenue entrenchment is only driven by recurring capital flow ergonomics and substitution cost

This angle of revenue entrenchment (infrastructure stickiness and compactness) of recurring payments workflow and shoulder to shoulder dependency (the competition of alternatives) is primarily the moat for the stablecoin primitive in the near future. We can discuss this angle in a more elaborate way by breaking it down into three different scenarios, backed by institutional data and non-reproducible design that can depict the hidden moat itself. This design or framework is driven by one of the core financial fundamentals saying "It's not how much you process once, but how often they come back at you"!

For most projects, the cold start is in the wrong place, which is a trillion-dollar transfer chart, supply league table or a reserve breakdown that says only numbers as if the biggest number on screen is the same thing as a moat, which actually isn't the case. When you strip out trading noise and internal shuffling, the part that actually looks like people and businesses paying each other iteratively over and over again is much smaller than the headlines suggest, and that's where the real framework that needs stress tuning but will be a good starter for this research. As said above, the moat isn't "projects moved a lot once." It's whether the same users, corridors, and rails keep showing up next month, quarter, and year and whether anyone at the end of that loop actually gets to keep the economics. That "anyone" can be a protocol establishing the completeness of this flow-as-a-service moat.

The Actual Framework (along with revenue defensibility and adjacent data bricks)

Let's name this framework "Cascade" which also means layered linear distribution which directly signifies the moat we are about to discuss.

Now, Cascade (the framework) runs in three drops, each one narrower than the last, each one showcasing a different take about substitution cost:

a/ is this even a payments playground? or is it something mainstream but hidden under the existing ux

b/ who would have to move capital

c/ who actually gets paid when they stay (is this is even significant)

These are the fundamental dots that when connected, projects can avoid fuzz and work on actual skeleton to derive their own whitepaper around Cascade aka the framework. And to be clear, this isn't a highly sophisticated engine that's built with all risk analysis, defi math or some overqualified quant simulation research but a plain execution flow moat.

Initial Drop

Any anon project pitch is based on the same deck everyone in the defi has access to: the transfer volume which is in the trillions, supply rank top positions or the reserve composition (literally the stablecoin vertical is over saturated in terms of huge reserve markets). Defi is mature now more than ever and mere rankings and leaderboards are drifting protocols away even from capturing legacy or proven moats. Clearly any amateur today grasps that alone Liquidity isn't the moat. Intentionally we need to attest to the fact that markets revolving around reserves, liquidity alone are prone to collapse on one depeg, bad counterparties or damaged reputation starts to spread. This is exactly why we should seek a more captive motivation especially for stablecoins.

The first drop is based on this questioning layer: how much of that is the same counterparty paying again next month, versus bots shuffling the size, exchanges moving float internally, and traders opening and closing the same loop before they call it a day? This is the basis of Cascade as a product out of this research. Cascade framework is the product of exploration and attested execution in the narrow funnel of recurring flow architecture that's observed easily with stables.

It's clearly visible with help of the reference (reference from https://digital-assets.fct.bcg.com it became the primary official source for usecase oriented study) that there is widest mouth for projects to fall for but only a narrow band can make them sustain over the cycles.

With almost $62T gross only ~$4.2T is completely adjusted that gives real-economy payments ~$350 to 550B, plus with the split (investments, tradings, CEX, real economy).

This issue does not directly come to notice since it needs a lot of market digest and a usecase which we shall discuss further. It's hard to find this perspective since it's most of the times hidden behind the underlying tech that's keeping this industry alive. This usecase forged the base layer of this research but on secondary basis, data backed findings and analogy was primary.

Just to be clear, the analogy will make sense as we iterate to next couple drops of the Cascade framework and can then easily conclude why this primitive might succeed the way it was meant to succeed.

Intermediate Drop

Drop 1 showed the mouth of the funnel with trillions of adjusted noise, thin green band of real-economy flow which stands vital for us at this stage. The natural mistake after that is to assume whoever wins that band wins the moat automatically. That's still the wrong layer if you're only counting dollars once and only once. The second drop is meant to ask who actually sits inside the narrow slice, and whether they're coming back because of reserve quality or because replumbing their life is a pain they won't repeat every quarter. UX is so heavy for the user end. We don't need to prove that here.

The questioning layer here is blunt: when a stablecoin wallet holds less than what a treasury desk would round away at every timestamp, is that user optimizing backing composition or running the same corridor, same counterparty, same rail, month after month until the loop becomes the infrastructure? The substitution cost at Drop 1 was near zero because the activity was reversible. Here it compounds as not only one swap, but breaking payroll templates, saved addresses, employer configs, local on-off-ramps, and the shoulder-to-shoulder habit of remittances (remember above we discussed about the perfect usecase - yes that is nothing but remittance). That is nothing but recurring capital flow ergonomics, infrastructure level stickiness in a compact form and it's a different moat physics than liquidity on a leaderboard. Remittance is a live, high value throughput example of this flywheel. It's clearly not payment end product or any institutional byproduct but a usecase which will never migrate.

It's only visible once you stop averaging the market into whales. That's the point which may distinguish projects success around stablecoin market in our scenario.

For Cascade Drop 2 / Intermediate drop, this is the attestation we should be talking about (find this data reference at: https://www.stablecoin.fyi/) Recurring demand in stablecoins is concentrating in enterprise settlement and habitual spending via fixed rails (mediums) or chains to be specific, and not the peer transfers. Substitution cost lives in purple and blue, not the green band everyone still uses to tell the story.

This might make more sense: The substitution cost is the friction of replumbing the recurring loops whereas enterprise settlement and card spend embed that friction. P2P mostly doesn't do that for us.

From other tertiary research legs, we get an estimate of around roughly 80% of stablecoin wallets hold under $100 at every sample time. Also, the activity spreads across chains and timezones rather than concentrated in a few allocator-controlled balances. This is where the funnel still has its radius big enough to play within.

The mass of the funnel isn't BlackRock rotating BUIDL at all but it is millions of small loops that look irrelevant on a supply chart but aren't irrelevant if the thesis is how often they come back. Eventually remittances bring this into picture. It's periodic and transactions compound for great volumes. We enter into new primitive of compounding (which is new around stablecoins but a jargon on Wall Street).

This clearly doesn't show up in headline transaction for the same reason Drop 1's split was buried. The usecase is iterative settlement between the same parties, and not volume that is bragging rights. That sets up the last drop and this is because a locked-in user base still can't point to who keeps the economics at the bottom of Cascade.

Rock bottom Drop (Final drop)

By Drop 2 / Intermediate drop we can conclude that a user or business that isn't going anywhere, that is, same ux or application, same corridor, same rail, long pay history (maybe months or years), substitution cost already paid in sweat and setup. Anyone may assume the win belongs to whoever minted the stable sitting in the middle of that loop. But the cascade shall not be designed that way. It's actually a total opposite to bring out more accrual out of this setup. That was entirely wrong handoff believing that minter is somewhere getting mentioned in this whole scenario.

The Drop 3 / Final drop is where Cascade stops asking who stays and starts asking who gets paid when they do because recurrence can lock in usage while economics leak to whatever wraps the flow, it may be exchange, off-ramp, venue, treasury deployer, the protocol that makes mint, settle, repeat feel like one product instead of four different vendors together. Literally the rock bottom can be anything (its like we dig deep enough the earth and find different entities exist before anyone knew it). Similarly these setups are made available to defi from the start, its just they are not utilized at fullest possible extensions.

But the real questioning layer is ugly and simple: if the sender in Mexico or the importer paying forty suppliers monthly is already sticky, who actually taxes that loop and honestly it can be the issuer, or the stack around it? It can be anyone, this framework isnt about that but it certainly needs satisfactory solver application. This is where we can grasp the blurb about all three layers altogether which ends at very specific domain and which when executed aligned with data is the actual moat in 2026!

That domain is nothing but an application built through to receive this flow - some of them are already capturing the consistency.

Under GENIUS style (the act) economics or system, the overall yield/capture migrates to whoever completes the loop i.e. Coinbase and venues on USDC, Binance on USDT distribution, corridor apps like Felix and Yellow Card, B2B rails like Reap. Remember, all this while minting the token becomes the commodity layer in the middle. Cascade is never about which stables or which strategy but about depicting the moat - again which can be implemented by anyone or any protocol envisioning stablecoins as the future.

That is the beauty about this flowing framework. A flywheel indeed.

Abstract

This article examines the relationship between vaults and escrows in value-bearing crypto systems. It argues that the vault, as commonly implemented across many protocols, is not a distinct settlement primitive but a constrained form of escrow in which the release condition has been reduced to a single operator-controlled signature while traditional depositor protections, including neutral arbitration and timeout-based recovery, have been removed.

Building on this observation, the article introduces a generalized settlement model based on three parameters: release authority, release condition, and settlement velocity. Within this framework, a wide range of financial systems, including structured credit, can be represented as settlement games that differ only in their parameterization. The analysis further distinguishes between bounded and unbounded opportunity systems and argues that these two categories require fundamentally different settlement architectures. While bounded systems often benefit from custodial coordination, unbounded systems are generally better served by protocol-enforced settlement mechanisms that minimize discretionary authority.

Motivation

An escrow is a settlement contract that temporarily holds assets until a predefined release condition has been satisfied. Traditional escrow systems share two fundamental properties. First, the entity responsible for releasing funds is expected to remain neutral with respect to the participating parties. Second, if the intended transaction cannot be completed, depositors retain a protocol-defined mechanism for recovering their assets after a specified period.

Vaults retain the custody function of escrow but frequently omit both of these properties. In many production systems, the release condition consists solely of a signature produced by an operator-controlled key. No externally verifiable condition determines whether assets may leave the contract, and users cannot independently satisfy the release condition.

This characterization is observable directly from common implementations. Deposited assets are transferred into the custody of the vault contract itself using instructions equivalent to safeTransferFrom(msg.sender, address(this), amount). Once transferred, the contract becomes the sole custodian of user funds. Expiration mechanisms generally apply only to vouchers or authorizations issued by the operator rather than to idle user balances. Consequently, users who have deposited assets but have not entered an active settlement process often lack a protocol-defined method for reclaiming their funds without operator approval.

Under these conditions, the vault is more accurately described as a constrained form of escrow than as a new settlement primitive. The custody model remains unchanged, but the depositor protections traditionally associated with escrow have been removed. Neutral arbitration is replaced by unilateral authority, and timeout-based recovery is eliminated. The resulting design simplifies operational control while increasing trust assumptions.

Structured Credit as a Settlement Game

The settlement-game model extends beyond crypto-native systems. Traditional financial infrastructure can be described using the same framework, demonstrating that the model captures a broader class of settlement mechanisms rather than a blockchain-specific phenomenon.

Structured credit provides a useful example. In a tranched credit vehicle, investors commit capital to a common pool. Each tranche represents a position with a defined level of risk and priority during distribution. Cash flows generated by the underlying assets are allocated according to a predetermined waterfall, which determines the order and amount of every payout.

Within the settlement-game framework, committed capital corresponds to the settlement pot, tranches represent participant positions, and the waterfall functions as the release mechanism that redistributes value. The settlement process produces a finite set of outcomes. Investors either achieve the expected portfolio performance or experience impairment through default, write-down, or credit deterioration.

The three model parameters remain applicable. Release authority is exercised by the servicer or manager operating within the constraints of the governing agreements. Release conditions are defined by contractual covenants, payment waterfalls, and credit events. Settlement velocity is moderate, reflecting periodic repayments, portfolio rebalancing, and scheduled distributions.

From a structural perspective, a vault and a structured credit vehicle perform the same underlying function. Both receive committed capital, apply predefined settlement rules, and redistribute value according to those rules. Their differences arise from parameter selection rather than from fundamentally different architectures. This observation has broader implications. If two systems from different financial domains can be represented using the same settlement model, then the decision to introduce a vault should be understood as a choice of settlement parameters rather than the introduction of a new primitive. Many protocols adopt custodial vaults as a default architectural pattern without first determining whether their settlement characteristics actually require that level of discretionary control.

Bounded and Unbounded Opportunity Systems

Not every settlement game operates under the same economic constraints. The cardinality of available opportunities fundamentally changes the settlement architecture that is appropriate.

A bounded opportunity system is one in which outcomes are finite and inherently scarce. Participants compete for access to a limited pool of value, and the protocol must determine how that value is distributed. Examples include structured credit, auctions, prediction markets, tournaments, insurance pools, and many custodial financial products. In these systems, arbitration is an intrinsic part of settlement because multiple participants compete for mutually exclusive outcomes.

An unbounded opportunity system operates differently. Opportunities are not allocated through scarcity but emerge continuously through permissionless interaction. Value can move directly between participants or against open markets without requiring an intermediary to determine entitlement. Decentralized exchanges, payment channels, state channels, peer-to-peer markets, and many programmable financial protocols fall closer to this category.

The distinction is significant because bounded systems naturally justify stronger coordination mechanisms. When scarce outcomes must be allocated, an operator or protocol-defined authority performs necessary work by resolving conflicts and enforcing distribution rules. The same assumption does not necessarily hold for unbounded systems. Introducing discretionary custody into a system that does not require arbitration increases the trust surface without introducing new settlement capabilities. The additional authority exists only because it has been designed into the architecture rather than because the settlement process depends on it.

This observation leads to a practical design principle. Protocols should select the weakest release authority that satisfies their settlement requirements. If deterministic protocol logic or mutually verifiable state transitions are sufficient to complete settlement, introducing discretionary operator control provides little technical benefit while increasing custodial assumptions.

A vault may still serve a legitimate role within an unbounded system, but only for the bounded portion of its value flow. Funds actively participating in a settlement process may require temporary custody, whereas idle balances or open-ended user funds generally do not. Extending vault custody beyond its necessary scope increases systemic trust requirements without improving settlement correctness.

Design Implications

The practical consequence of this model is straightforward. Rather than defaulting to operator-controlled vaults, protocol designers should minimize discretionary authority wherever the settlement process permits.

Several design alternatives illustrate this progression.

The simplest improvement is timeout-based recovery. If assets remain inactive beyond a predefined period, users regain the ability to withdraw their funds without operator approval. This restores one of the fundamental protections traditionally associated with escrow while leaving the core settlement process unchanged.

A stronger approach is co-signed settlement. Instead of authorizing withdrawals through a unilateral operator signature, settlement requires agreement between all participating parties. Trust becomes limited to the assets actively involved in the current settlement rather than extending across every deposited balance.

The strongest approach replaces discretionary authorization entirely with protocol-enforced settlement. State channels, payment channels, validity proofs, zero-knowledge systems, optimistic dispute mechanisms, and similar constructions bind asset release to verifiable protocol state rather than operator judgment. Under these designs, the settlement authority may temporarily delay execution during disputes, but it cannot unilaterally redirect user funds.

These approaches should not be viewed as competing architectures. They represent different points within the same settlement model. Each changes the release authority and release condition while preserving the underlying objective of securely transferring value. The appropriate design depends on the settlement game's characteristics rather than on convention.

6. Security and Trust Considerations

Defaulting to custodial vaults introduces measurable security and operational risks. Because user assets accumulate under a single administrative authority, the vault balance becomes a concentrated target. Compromise of the operator, administrative key, or privileged execution path can affect every participant simultaneously.

These risks may be acceptable in bounded systems where centralized coordination is unavoidable and where operational controls, auditing, and regulatory oversight reduce the likelihood of failure. The same assumptions become more difficult to justify in systems whose settlement process could otherwise operate without discretionary intermediaries. Trust assumptions should also remain internally consistent throughout the protocol. A system that advertises cryptographic correctness for execution, randomness, or state transitions should provide comparable guarantees for custody whenever possible. Verifiable execution combined with discretionary asset release creates an asymmetry in the trust model. Sophisticated participants are likely to evaluate custody separately from execution and assign additional risk where discretionary control remains.

Settlement finality also deserves explicit consideration. Many blockchain systems distinguish between transaction inclusion and irreversible finality. Release conditions that depend on finalized state should treat finality as an explicit prerequisite rather than assuming immediate confirmation. Failure to distinguish between these states can introduce settlement inconsistencies during periods of network congestion, delayed finality, or chain reorganization.

Conclusion

The central argument of this article is that vaults should be understood as one point within a broader design space rather than as the default settlement primitive for value-bearing systems.

Viewed through the settlement-game model, a vault represents a constrained form of escrow in which release authority has become highly centralized and depositor protections have been reduced. Whether this trade-off is appropriate depends entirely on the characteristics of the settlement game being implemented.

The proposed framework evaluates settlement systems using four dimensions: release authority, release condition, settlement velocity, and opportunity cardinality. Together, these parameters provide a systematic method for reasoning about settlement architecture across both crypto-native and traditional financial systems.

The objective is not to eliminate vaults. Vaults remain appropriate wherever bounded settlement requires coordination, arbitration, or controlled distribution of scarce outcomes. The objective is to discourage their indiscriminate application to systems that do not require those properties.

A protocol should not begin with a vault and then justify its existence. It should begin with the settlement requirements of the system and introduce only the minimum level of authority necessary to satisfy them. When settlement can be enforced through protocol rules rather than discretionary control, reducing trust assumptions is generally the more robust design choice.

A useful principle follows from this framework:

Bounded settlement games require dealers. Unbounded settlement games should minimize or eliminate them.

If this principle holds across a broad range of protocols, then vaultification is not a universal design pattern. It is a parameter choice.

Below post was the substrate which transformed into this overall outcomes and research:

(Intentionally there are no technical aspects/terminologies in depth discussed over here, as we all believe code always works but deep down we need more consice understanding of the primitive and our ideation for the product)

To start with, lets checkout an abstract about Banana

The curated vault has become the default way to earn yield on-chain. A depositor hands stablecoins to a vault, a curator decides where that capital goes, and the depositor receives a single liquid share token in return. By early 2026 this pattern had quietly absorbed the majority of net-new deposits in DeFi — Morpho alone held roughly $5.8B in TVL, with risk firms like Gauntlet, Steakhouse, Veda and Sentora running billions in curated strategies on top of it.

But almost all of these vaults share two structural properties that deserve scrutiny. First, they are usually single-protocol: a curator allocates across the markets of one lending platform, not across the whole opportunity set. Second, the curator's power is enforced socially, not cryptographically - the curator is trusted to stay within a risk mandate, and depositors trust the curator's reputation rather than the contract's guarantees.

Banana takes a different position. It is a meta-vault, a single ERC-4626 share that routes USDC across multiple protocols — Aave V3, Morpho Blue, Compound V3, and Pendle fixed-yield PTs — chosen for the best risk-adjusted return at any moment. And it inverts the trust model. The rebalancing decision is delegated to an autonomous off-chain keeper, but every action that keeper can take is bounded by on-chain code it has no authority to change. Allocation caps, an idle-liquidity floor, a per-block churn limit, a NAV circuit breaker, and a strategy-quarantine switch are all enforced inside the vault itself. The agent optimizes; the contract constrains. Depositors don't have to trust the optimizer — they only have to read the limits

DeFi yield aggregation is not new. Yearn invented the category — pool deposits, deploy into yield sources, harvest and compound automatically. The 2024–2026 evolution was the curator model: rather than hard-coded strategies, a human or firm actively manages which markets a vault touches and how capital is sized across them. It is, by most accounts, the single biggest innovation in vaults since Yearn.

The curator model works. It also has two gaps.

First gap: The opportunity set is too narrow. The dominant curated-vault venues are built around a single lending primitive. A Morpho vault allocates across Morpho markets - a Gauntlet vault sizes risk within the universe its host protocol exposes. That is excellent for isolation, but it means a depositor's yield is a function of one protocol's rate environment. When Aave's utilization curve is paying more than Morpho's curated markets, or when Pendle is offering a fixed rate that beats every floating venue, a single-protocol vault simply cannot reach it. The best risk-adjusted yield in DeFi is almost never concentrated in one place.

Second gap: We believe the mandate is a promise, not a guarantee. Curators publish a risk framework and are trusted to honor it. The two leading philosophies here, Gauntlet's simulation-driven position sizing and Steakhouse's conservative asset selection are both off-chain disciplines. They are run by serious teams and have weathered real stress; Steakhouse processed $108.5M in liquidations in a single day in February 2026 while every vault stayed fully redeemable. But the depositor's protection ultimately rests on the curator choosing to behave. The contract does not stop a curator from over-concentrating, draining the liquid buffer, or churning the book. (These are extracted from different research backed sources)

Risk management is far more vital than we think. Any financial service company cant afford a cleanup, some big players hate it even its a small reimbursement, lol. For intance, Quantitative approaches are meaningful and human intervened in most cases. This helps to hand the priority in hands of humans rather than a closed custody benchmarking. We love this approach and are exploring rich tastes around defi risks.

Here at Banana, we love diamond Proxy architecture and standards enhancing code modularity. The contract layer is far more sophisticated in its own way, and to be clear, we are not reinventing the wheel here! We believe in existing development and standards (which has always been a perk being in this industry). But we are struggling with more often market risks evaluation with current standards and innovations being easiliy accessible (most of the services, products are selective in terms of free integration, subscription knots being a bottleneck for engineers to build on top of these protocols). This is expected and we are working to integrate one of these solutions from the research backed institutions.

Some light on the Architecture we aim to scale

We believe every finance/defi instrument should make complete use of the substrate thats being laid down at Banana

The vault is built on the EIP-2535 Diamond pattern. Rather than one monolithic contract, the vault is a single address whose logic is split across facets - independently deployable modules that share one storage space. This matters for a meta-vault specifically: adding a new yield venue is adding a facet, not migrating depositors. A new strategy plugs in through diamondCut without changing the vault address, the share token, or anyone's balance. To make that safe, every module stores its state under an EIP-7201 namespaced slot. Storage collisions — the classic failure mode of upgradeable proxies — are structurally impossible across facets.

Core facets

Vault - the ERC-4626 surface: deposit , withdraw , redeem , share accounting reentrancy guard. This surface is deliberately not casually upgradeable; the asset and share semantics depositors rely on stay fixed while strategies rotate beneath them. And note that these facets are not actually touched by owners or curators but are core part of the underneath base protocol.

a/ AllocatorFacet - the strategy registry and target allocations (in basis points). The owner sets caps and the idle floor; the curator sets targets and rebalances within them.

b/ GuardFacet - the NAV circuit breaker.

c/ FeeFacet - performance fee (capped at 50% of gains, paid only above a high-water mark) and a linear management fee (capped at 10%/yr).

d/ RolesFacet - appoints and revokes curators. The owner is always implicitly a curator, a curator is always strictly less powerful than the owner.

e/ WithdrawQueueFacet / LockFacet - asynchronous exits and an anti-MEV share lock.

Some light on how we revolve around share accounting

Share price is the standard ERC-4626 relationship:

shares = assets * totalSupply / totalAssets

The *totalAssets() sums the vault's idle USDC plus each strategy's live valuation. Each strategy reports its own position honestly: For an instance, Aave and Compound read their rebasing balances directly.

Morpho marks MetaMorpho shares at the current exchange rate; Pendle marks PTs at their oracle-implied discount before maturity and 1:1 after. The vault uses virtual share offsets to neutralize the inflation-attack vector, and fees accrue on every deposit/withdraw against a high-water mark so depositors are never charged twice for the same gain.

We shortlisted three roles, strictly nested to avoid protocol and governance level confusion especially: owner ⊇ curator ⊇ user , and the boundaries are enforced in code, not the convention we laid in ideation or something.

1/ Users deposit, redeem, transfer shares, and queue large exits. Nothing else.

2/ The curator (the keeper, in practice) can only set allocations, rebalance, harvest rewards, fulfill withdrawals, and run the circuit-breaker checkpoint. It cannot exceed a cap, drop below the idle floor, move more than the churn limit in a block, change fees, upgrade a facet, or touch user funds.

3/ The owner configures the limits, registers strategies, manages curators, quarantines venues, and upgrades facets - but cannot directly move depositor capital either.

This is the inversion that defines Banana Markets. The optimizer lives outside the trust boundary. Even a fully compromised curator key cannot rug the vault, it canonly shuffle capital inside a box the owner drew and the code enforces.

Let's also checkout the Offchain base architecture currently holding all strings together and tighter!

The curator is not a desk. It is an autonomous Go agent that wakes frequently and runs one disciplined loop.

a/ Perceive - Read the vault's full on-chain state, then overlay live data from every venue - Aave's liquidityRate and utilization, Compound's Comet rate, Morpho's net APY plus keyless on-chain market risk, Pendle's oracle-implied fixed yield and maturity gate.

b/ Decide - Price each venue's Expected Loss from a closed-form credit model, then water-fill the budget in certain bps increments toward the highest marginal yield i.e λ·EL, never past a cap. Always deterministic, replayable, backtestable. No black box at all.

c/ Validate - Re-check every hard bound off-chain. If a decision would breach one, the agent submits the current targets i.e a deliberate no-op. A bad thought can never become a bad transaction.

d/ Execute - Signing the curator txs before rebalance , harvest , fulfillWithdraw. These are based on independent cadences, with a dry-run mode that decides without sending.

This is a complete water level heuristc , a classic book algorithm. The whole agent (we like to call it dumb agent, since no Large Language Model exists in the architecture yet) has no privileged API and no special channel. It reads what any user reads and sends what any curator could send. There is no off-chain oracle at the Banana Markets as of now (We may add few services as per stratgy fulfillment).

And yes, this is the tornado eye for entire brain of the automated curation that entirely depends on some math that's not over curated.

At a product compounding like this, there is a monolithic need of per asset oracle decentralized service backing, maybe an isolated auction based solver networks and a governance tallying each yeild cycle as a final product. We are interested to keep digging until we find a gem in this space. As we said earlier in above prospect elements, we are working on highly curated risk management modules and tie-ups and we now have an MVP deployed on arbitrum mainnet with all possible ai based audits and formal verification.

~ First Banana intern