DeFi Sessions by App Relations, Ethereum Foundation: Cannes, 2026.
A summary of DeFi roundtable sessions with 70+ teams (Cannes, 2026). Participating teams from categories like aggregators, DEXes, vaults, lending protocols, privacy, AI...
Authors: App Relations team at the Ethereum Foundation (Jason Chaskin, Charles St Louis, ivangbi). FYI: personal opinions of the team don’t represent that of the entire organization.
Since the Ethereum Foundation published its commitment to supporting DeFi - we’ve done hundreds of calls with teams of various maturity stages and focuses. This includes mentoring for newer projects, some research discussions, and some warm connections for collaboration. But this didn’t feel like enough, so we decided to set up a few days at ETHcc in Cannes to chat with teams in person, hear about their pains in detail, and identify where we can come in and support them.
Roundtable sessions with 70+ teams
Over the course of two days, we held 7 roundtable sessions with 70+ DeFi teams (some privacy teams as well, and two separate sessions for the vaults-RWA category). While we were somewhat concerned that founders wouldn’t share their pain points and plans openly in a room of competitors - it wasn’t an issue at all. Everyone was super supportive, constructive, and direct. We really appreciate all the thoughts and feedback shared, it went even better than we anticipated!
Below is a summary of what was discussed.
EF Mandate + CROPS
We will assess each project based on how far it sits from the optimal CROPS direction. We understand that the landscape and the market may sometimes push teams toward different approaches, but the DeFi protocols and applications we are prepared to support should be as close to the CROPS guidelines as possible and if not there yet, actively showing transparent progress towards it.
We do not want users harmed by avoidable access-control failures (example), poor key management, such as storing private keys in a password manager, or weak security practices more broadly. Cutting corners may be a choice some teams make, and the market may tolerate different forms of compromise, but EF support has to be held to a higher bar according to the road we’ve chosen for ourselves.
There is obviously nuance here, licensing is a good example. Is BUSL bad from a purist perspective? Yes. But we also hear the feedback from founding teams who feel safer using it, even if they understand that the current AI landscape may limit how much protection it really provides. So what is the better path? Maybe BUSL with an 18-month deadline before moving fully FLOSS open-source.
Some things are less negotiable: user self-ownership, minimizing offchain components where possible, and maximizing user ownership and self-sovereignty over interactions where possible. That is our opinionated approach.
It is all a gradient at the end of the day, but our goal is to see economic value and rules live onchain, on Ethereum, with strong user ownership. We prioritize those properties over opaque offchain structures. For some categories, this is easier, for others, it is harder, and we understand that (for example, for RWA assets).
DeFi Sessions Summaries
Teams were grouped together according to the following categories:
Tokenization, vaults, RWAs, risks, standards.
More decentralized stablecoins, payments, wallets.
AMMs, DEXes, aggregators, solvers.
Lending protocols.
Exotic yields, options, derivatives, onchain degens.
Privacy and AI.
Note: the topics below are not presented as final answers, but as major goals, recurring pain points, and discussion areas. Some of these are multi-year issues that teams across the ecosystem have been working on for a long time. We are aware of that, and in several cases, other internal and external EF teams are already focused on parts of the problem.
1. Standards for vaults, tokenized assets, and data reporting
Standards can make protocol integrations safer, at least in theory, because predictable and battle-tested interfaces reduce integration risk. The harder question is which standards are actually worth pushing, especially in the context of DeFi.
Vault standards are a good example. We are already speaking with teams working in this area to make sure they receive useful feedback before going too far down a specific path. Some founders think ERC-4626 is outdated, while newer efforts like ERC-7540 from OpenZeppelin and ERC-3643 are still being developed, but the question remains, what is the better version?
RWA wrappers, whether vault-based or not, are another important topic that DeFi teams are actively working through. We see standards as a way to enable adoption in a safer and more CROPS-aligned way, if done right, but we do not plan to productize those standards as the EF. Our role is to understand which standards teams actually prefer, then help coordinate around the most useful paths.
Reliable data reporting also came up repeatedly. The industry needs standardized ways for multiple sources to corroborate important information, such as Proof of Reserves, NAV oracles, and related disclosures, then report that information clearly to users, issuers, underwriters, and other stakeholders. This is badly needed, but today, it is serviced by only a small number of companies. In practice, many of these feeds rely on one another, which weakens the overall offering and creates additional risk for everyone involved.
2. Aggregating risk scoring dashboards
Risk dashboards were another major theme. There is strong demand for more transparency around asset ownership and legal structures, not only onchain, but also across offchain components, especially for tokenized assets and RWAs.
People want to know who is holding what, what a user actually owns, and what legal or technical claims sit behind that ownership. Naturally, many comparisons were made to L2Beat. There is a clear appetite for that same level of scrutiny in DeFi, supported by better education from the EF as an impartial organization.
If we can clarify the differences between a vault, a multisig, and a centralized CeFi component, it helps everyone identify which teams are taking security and user ownership seriously, and which teams are simply cutting corners.
To be clear, we are not trying to rebuild risk scoring ourselves. The ask from teams was for a new or existing group to aggregate risk data and frameworks already being done across the ecosystem, including subjective scoring, technical analysis, security reviews, liquidity analysis, and related research. Relevant examples include teams like DeFiScan, CuratorWatch, Block Analitica, DeFiPunk’d, Pharos, DeFi Sphere, DeFi Saver, Credora, and others.
3. Access control layer, reducing admin key issues
On the technical side, teams were very vocal about the need for better visibility into access control. Given how many recent hacks have involved basic key compromises, there is strong demand for clearer disclosure around admin keys, governance permissions, and who actually has the ability to change a protocol.
Even though everyone is operating in a commercial, for-profit environment, there is still a shared desire for a security North Star. This is partly about stewarding a new market before it becomes a lemon market. Participants, especially institutions, need to understand the risks clearly, so teams building DeFi the right way can stand out.
4. Security in the age of AI
AI is clearly changing the security landscape, but the feedback from senior teams was specific. Mature teams do not need hand-holding on how to work with auditing firms, they have already learned those lessons, and they should be asked to share that feedback with others.
What they did ask for was better guidance, educational content, and tooling around the pre-audit phase. There are many peculiarities in that part of the process, and even veteran teams feel they could use better support.
Look into Trillion Dollar Security (blogpost here) and the recent TheDAO Fund.
For 1TS, in some cases this means providing grants to teams like SEAL, TrustX, CredShields; collaborating closely with the Clear Signing Working Group to improve transaction clarity; working upfront on security features like Transaction Assertions, etc. Here is a recent post to add to the list of what is being done. Vitalik’s recent post on open-source security in the age of AI is also directly relevant to this discussion:
5. MEV, impermanent loss, and the usual demons
MEV was one of the more divisive topics, especially the question of whether it should be addressed at the protocol level, through encrypted mempools, or through other mechanisms. This is not a new debate, but the fact that there is still no unanimous view in 2026 is notable.
Some teams view MEV as a positive incentive structure for sophisticated participants, while others believe it needs to be addressed much deeper in the protocol stack. The result is that there is still no clear consensus on how to handle the dark forest at the core of the system. The LUCID forum proposal being discussed for the Hegota network upgrade is worth reviewing for anyone interested in this topic.
Onchain liquidity, or the lack of it, is also becoming a real bottleneck. When liquidity is scarce, especially for exotic assets or niche vaults, users are the ones who get hurt. Building efficient routes for long-tail assets takes time and resources, and in many cases the economics do not justify the work, which leaves those routes neglected and users underserved.
There is also growing concern that heavy reliance on offchain components, including solvers, intents, and off-order-book liquidity, is creating its own problems. It is not only about the difficulty of calculating LTVs for lending protocols or underwriting risk, it is also that the less liquidity exists onchain, the more routing and pricing need to be calculated at the exact moment of settlement.
To make trades more likely to go through, systems may increase the delta, but that can also increase MEV and worsen outcomes for users. In other words, attempts to improve UX can sometimes make pricing worse. Teams are starting to want more onchain liquidity again, because it makes execution more reliable and more calculable. That brings us back to the old problems of impermanent loss and toxic flow, but the desire for a more predictable settlement environment is clearly growing.
6. TradFi and DeFi interplay
The “big brother” dynamic is showing up across the board. Most teams, unless they are already major players, are looking for a more consistent source of liquidity or volume. At the same time, they are not looking for a traditional acquisition or acquihire. They want to preserve their vision while securing a place in a larger ecosystem that can provide reliable capital flow, activity, and fees.
The ideal outcome is an alliance that helps solve the distribution and liquidity problem without forcing the team to give up its soul to a corporate buy. Another recurring pain point is that institutions and large clients often want turnkey solutions, but those solutions require coordination across several protocols. For example, compliance, vaults, oracle reporting, admin permissions, and other components may all be handled by separate teams. Composability is powerful in principle, but when selling a package to TradFi, coordination becomes difficult.
There was also an interesting discussion about business models shifting from subscriptions toward pay-per-call or pay-per-execution models. That has major implications for licensing, protocol economics, frontend monetization, and the relationship between interfaces and protocols. If the industry moves toward per-execution fees, it changes the incentive structure for building and maintaining frontends.
7. UX and account abstraction
Cross-chain standards and Account Abstraction came up again, as expected. Both have been discussed for years, but AA adoption still lags far behind the hype.
There is clear fatigue across the industry from waiting for these supposed game-changers to become frictionless in practice. The vision is understood, but execution and standardization are still behind where many hoped they would be. This is part of a much larger UX discussion, and there are teams inside and outside the EF already working on it.
8. Regulation and lobbying
This session also surfaced a clear split. On one side, some teams are pushing for mass adoption by leaning into centralized components, which are often necessary today to grow adoption. Their pain points are mostly regulatory, including lobbying, navigating traditional legal structures, and figuring out how to scale while playing by existing rules.
EF members can and should spend time educating regulators, banks, and other interested parties, but that specific lobbying and policy function is largely handled by external groups, including Etherealize in the US, the European Ethereum Institute, and others. This work is highly important, but we will likely need to rely on partners for much of it.
That said, when it comes to sharing knowledge, offering technical context, and spending time with people pushing for the right values, we are very open to engaging.
It is also worth noting that some teams are moving in the opposite direction, doubling down on onchain security and onchain users only. They are focusing on non-USD stablecoins or dollar-denominated assets that do not depend on real-world backing. Their goal is to keep the ecosystem as decentralized and resilient as possible, even if that means slower retail adoption and a harder regulatory path. Many people also shared the view that self-custody, DeFi, and peer-to-peer finance should remain legal outside of traditional regulatory frameworks.
9. Protocol <> App feedback loop
Lending protocols, which often sit across both sides of the stack, raised many of the same issues as participants in other sessions. These teams have been around for years and have integrated many parts of the stack, including infrastructure, assets, and other protocols.
One theme was the desire for Ethereum to remain a level playing field, without making application-level decisions on behalf of teams. They want their feedback represented in the Protocol <> App feedback loop. For example, the recent contract size increase discussion. This is also a good place to remind teams that the process for EIPs has a guidebook, but if anything remains unclear, ask for help navigating it.
10. EF treasury allocation
Treasury allocation is the major topic everyone is aware of. We have shared more detail with teams in person, but a more concrete writeup will follow once the framework and process are refined internally.
There are a couple of solid ideas being debated now, but the process is slow because it is both budget-sensitive and security-sensitive. Given recent organizational changes and the mandate, we hope to share an update as soon as we reasonably can. It is a major to-do item, and we are aware of that.
11. Yield ouroboros and yield fluctuation
The current environment is not especially strong for yields, but cycles are cycles. The more diverse and uncorrelated yield sources we have, the more continuous capital deployment on Ethereum can become.
Some teams asked for more context on yield origination, including onchain-native yield sources. We also discussed the yield problem for retail applications. Right now, secure yields are not especially high, but that is largely a market structure issue. Offchain assets are starting to shift the picture, but there was broad agreement that Ethereum needs more diversified yield sources to sustain onchain activity across market conditions.
Here is an interesting piece on the topic of onchain-native yield sources.
Yield cyclicality also makes user retention harder, because users tend to follow bull and bear market hype cycles. That is ultimately finance, but the more uncorrelated financial instruments available onchain, the better retention can become.
At the same time, we need to be careful when bringing offchain yield sources onchain. The structures need to be credible, and users should not end up holding hot potatoes wrapped onchain mainly so managers can earn fees.
Participating teams (thanks to them for being awesome & building cool things)!
1inch, PropellerHeads, Aerodrome & Velodrome, Enso, Balancer, Velora (Paraswap), Barter, CoW Swap, Titan (Gattaca), LiFi, Curve Finance, DefiLlama, 0x (Matcha).
Keyring, Block Analitica, Nexus Mutual, Maple Finance, Lombard Finance, Makina, kpk Karpatkey, Superform, K3, 3F, Midas, Gauntlet.
f(x) protocol, EtherFi, Ambire, Frankencoin, Liquity, Darika, DeFi Saver, Curve, Gnosis, Gyroscope, Monerium, Polaris, Sky (MakerDAO).
Compound, Spark, Liquity, Aave, Euler, Fluid (Instadapp), Gearbox Protocol, Ink Foundation, Wildcat, ACI, Iris (246 Club).
Lighthouse, CAP, Symbiotic, Panoptic, Cork Protocol, IPOR, Rysk Finance, ETH Strat, Infinifi, Mithras, Santiment, xStocks, Trevee, Knox, CollarFi.
Yearn Finance, Mellow Protocol, Sentora (ITB), Enzyme, Redstone, Lido, Octav, Jumper, Chronicle, Kiln, Hyperithm, Steakhouse, Aragon, Keyrock.
Kohaku, Railgun, Generic, Boundless, Hinkal, ZKNox, Unlink, Inco, 0xbow.
Next Steps
We hope to run more sessions later this year, most likely in Mumbai around Devcon / Devconnect, with more teams and more categories represented.
As for action items, we have identified the biggest pain points we need to continue with, as well as the areas that still require more research. Each section above either points to something teams can dig into further, or creates an action item that we need to follow up on ourselves.
Please comment on socials and tag us with feedback on what we missed, where you disagree, and where you think the EF can be most helpful within its scope.
We hope this post gives you more clarity on where we can support, what sits within our mandate, and how we want to move from discussion into actionable initiatives with teams going forward. More updates to follow.
See you onchain!