Chain-Abstracted Asynchronous Application Architectures | Adair Kelley

we're almost there everyone we're almost there uh to your Saturday happy hour um but we' got a few more talks and I'm super excited for the next talk um it is called chain abstracted async apps though I think there's a version two of the name um so please welcome adir Kelly uh co-founder of abstract money round of applause oh that's fine hey everyone thank you so much um yeah so hi I'm ader Kelly co-founder of abstract money and I'm here to talk about some really cool application architectures so who here knows chain abstraction has anyone like raise your hand if you've used the chain abstraction solution in the last like two weeks or a few months no okay well chain abstraction unifies your balances allows you to transfer assets across multiple different chains quite easily and swap any asset in your wallet for another so the GIF this is supposed to be a gif here um but you'll see that the my balance of usdc is Unified across all of the chains um and hidden from me as a as a user however chain abstraction is an illusion so chain abstraction solves a problem that most crypto users have been experiencing for years the fact that you have to get gas tokens for every new chain you have to um actually care about which chain your assets are on is my usdc on polygon or is it on eth or an optimism same with any other token it's quite cumbersome and in the past year we've seen a number of chain abstraction Solutions like particle Network and one balance and um all of these wallets that unify this experience however it comes with quite a few limitations if you try to use these unified balances to build cross chain protocols you end up with fragmented liquidity and the hard reality that these chain abstrac chain abstraction Solutions centralize the execution of your actions on chain so um how does train abstraction work uh if you look uh here in this example we have uh an omni account this is actually a diagram generated by The Rhinestone team so thank you shout out to them we have an omni account which is a universal account that works across multiple different chains when I go to use assets in my Omni account um I will Ex those actions through the orchestrator so let's say that I have usdc on one of these chains whether it be ethereum optimism or any one of these evm chains I have usdc but I want we so the way these wallets work it'll unify your balance across each of these chains it'll know that you have usdc you tell the orchestrator someone who coordinates actions across multiple chains that you want we and you have usdc uh this will broadcast the message to the orchestrator it'll figure out the best path to get you your we give you your we and then provide a proof that it gave you we to withdraw your usdc so as an end user at the end of the day you get we for usdc but um if you try to use this for any applications or protocols the illusion starts falling apart so if you think about yield aggregators or cross-chain lending where you have assets on ethereum and you want to borrow them on optimism or cross-chain governance when you want to um create decisions between multiple different chains or even investment strategies where you hold assets on one chain move them to another to you know essentially act as another yield aggregator you cannot use these chain abstraction Solutions because the the liquidity is not abstracted it's completely fragmented across all these chains despite what the user interface tells you so let's take a specific example here uh does anyone know about Trend following um if not uh Trend following uh looks at the previous price history of an asset um and it generates a signal based on the strength of the price movements of the asset so if bitcoin's been trending up it's a very trendy asset so it's probably going to continue trending up so if you implement a trend following algorithm it'll see that and give you a signal that says hey Bitcoin starting to Trend up let's increase our allocation from 0 to 25% and uh to to implement these algorithms efficiently they're generally done on perpetuals protocols so that you can have leverage to meet a certain Target volatility um and your collateral stays on that chain but this is kind of inefficient um if you have just usdc you can't collateralize a yield bearing asset and so you really but since you have access to leverage you can use less of that asset um and actually use the unused excess collateral and put it in a yield bearing asset but here in lies the problem even though we have chain abstraction we have many chain abstraction protocols today if you try to build a vault that holds a hyper liquid position and then a yield bearing asset like sde you run into a big problem and that that that is that the liquidity is fragmented across the trains um at the bottom you'll see uh the trend BTC signal can go from negative 1 to one uh which will be multiplied by The Leverage to implement Trend following so what are the requirements for a trend following Vault one it needs to be able to rebalance your assets across multiple chains here we just have two we have hyper liquid and ethereum um and those rebalances will be calculated based on the signal for the day um second one is it needs to calculate the value of your Vault shares ACR well of the entire Vault across multiple chains so they can give you the proper value that um of those shares when you go to purchase uh shares in the vault finally processing those shares which is an asynchronous action because Trend following is best implemented on a 24-hour interval um and cannot happen synchronously or you get uh end up with bad execution every single one of these actions is asynchronous uh and many applications in web 3 are fully synchronous which yes it offers novel mechanisms like flash loans but this is not a case where that applies so if we look at the cross-chain rebalance you start by uh calling rebalance on the Vault and what'll happen it'll calculate the number of assets it wants to send or request from a remote chain so it'll send that request via a messaging protocol to that chain it'll get a confirmation um and then you'll get the asset back what you don't see here is the acknowledgement or the failure case uh on this action when you start building asynchronous applications you start increasing the complexity and increasing the number of edge cases that you have to take care of as a developer um and Al Share value calculation it's the same story you send an execute message across another chain to query the value because you actually can't query the um query States across multiple chains at least right now given the current state of evm then you get the value back and then you calculate the rebalance okay that's cool it works with two two chains but what about with three so let's say that we wanted to improve our risk adjusted returns in this trend followed Bitcoin Vault many of you may not know but gold even though Bitcoin is supposed to be digital gold gold is entirely uncorrelated from Bitcoin so it's a good it's a good asset to add into your portfolio if you combine Bitcoin and gold um you'll have better risk risk optimize returns um but you're also adding another chain to this mechanism so now on a rebound you'll be sending and requesting assets from plume or hyper liquid to plume and then hyper liquid to ethereum and this uh this complexity increases with every other chain that you add um okay yes it's a completely contrived example that would probably involve multiple vaults but it's a good one for this demonstration purposes um most of these chain abstraction protocols they operate by using intense and intense as mentioned earlier uh just allow you to say I have X I have usdc and I want we in the case of this Vault um if you're on plume chain you can say hey I've got 15% uh gold but I want 25% gold and you can broadcast this intent um as the Vault and some intent solver could come in and solve for that intent providing the liquidity where you need it but what happens if this Vault holds over $100 million or some arbitrary amount where the solvers aren't able to actually solve for that amount of liquidity what solver has the size the answer today is none of them by the way so let's take a step back and think about what cross chain apps uh what features that they require so one is they require cross-chain messaging you have to send requests from one chain to the other and you'll get an acknowledgement or a failure case uh once you send that request out these failure cases or these acknowledgement you do also have to persist uh you're developing a state machine and it's not you know across um it's not on one computer so you don't have a centralized entity that can handle the state for everyone um next you need to recover from failure cases what happens if you were rebalancing between hyper liquid plume and ethereum but the plume rebalance call actually failed what do you do with the rest of the rebounds do you retry it do you like which point do you determine that the entire operation has failed okay and these last two are actually something that is very common in web three web 2 but hasn't been implemented in web 3 and that is authentication so application authentication um allowing you to register different services on different chains for example my Vault service on plume and My Vault service on hyper liquid as well as name resolution uh when you have a cross chain application you don't actually always know the addresses of the services that you're interacting with on the destination chains um I'll I'll give an example from the cosmos ecosystem because IBC is a widely used bridging protocol when you bridge assets from one chain to another you um end up with a denomination specific to the path by which you bridged it so if you bridged an asset from hyper liquid to plume the asset would be hyper liquid plume usdc or whatever it is it's not going to be the canonical variant yes intent solve this but if you're building an onchain protocol you'll need to be able to resolve those names onchain on demand at quot unquote runtime so you send a generic message across the chain to rebalance for usdc so let's take a look at Cross chain architectural patterns one um is the Hub and spoke model this is used by axar it's used by Zion um and it allows for one centralized entity even if it's running on a decentralized network to act as the orchestrator to perform actions across chains the second one is intent-based this is the model that's used by most chain abstraction wallets that you use today um and is quite effective at least at at moving small amounts of liquidity across chains however it has some limitations as I will go ahead and address finally the one that's actually kind of interesting is a mesh application so a mesh application actually shares State across every single participant every actor in the state machine so um if you want to yell out the one mesh mesh architecture implementation um it's probably going to be blockchain so every blockchain is comes to mesh consensus depending on the consensus mechanism if we look at HUB and spoke architectures you have a decent amount of benefits uh you get deterministic execution it's really easily verifiable because you have one place that's managing State on behalf of multiple Chains It's error resist ilent because you can run these actions sequentially you don't have to deal with um asynchronicity in terms of State Management but it offers a single point of failure and as we saw with the chain abstracted wallet in the you know in the first example you are um you are actually executing your actions through a one point and you're constrained by that one point's throughput um yeah so what about intent based coordination uh this generally happens offchain where you have a solver like solve for the intent that you that you uh that you propos and this has very high Capital efficiency because it's just an offchain entity you don't need to bridge things you don't need to unwrap your assets um and it's you can execute this independent of the time uh within your within your application because you can broadcast an intent and maybe it gets solved a month later maybe it gets solved in the next few minutes um it's also resilient to solve our failures if someone was unable to fail your uh fulfill your intent then some other solver will be able to solve it eventually okay the big limitation with intent-based protocols is that they completely rely on economic incentives if you don't have tokens moving alongside your message there's no incentive for the solvers to actually solve it uh let's say that you were trying to develop an interchain session key application where you had one chain that registered session keys on remote chains this protocol is actually not able to be intensified because there are no tokens associated with those actions and you need to verify the finality of the origin chain um so you end up with also non-determinate execution non-deterministic execution you don't know what the message is once you execute it what's going to be okay so let's go back to our bit Gold Plus Vault um and look at the design pattern for this so the best executor for rebalancing assets is going to be the Intense or if your uh your balances in the vault are over $100 million probably best to be done on the protocol level same with calculating Vault shares and then processing those shares is actually going to be done completely locally but not one single pattern that we looked at before the Hub and spoke or the intent model is sufficient to build this type of application you need to combine them so okay Universal accounts let's go back to these so so if you think about Universal accounts they allow you to move assets between chains very easily via intents they're also quite special because you have at least on evm chains the exact same counterfactual address on every single chain that means that you already have authentication baked into these accounts and you can trust that if you get one address on one chain that um a message from one address and is the same address on your local chain then it is the same actor it's the same contract what most people don't think about is that you can actually build apps on top of these Universal accounts so if you use the universal account as an authentication layer you can extend that account like a 7579 account with a module that enhances the functionality of that account um and that module can execute messages which are authenticated by another contract that checks the sender and the receiver on the destination chain and communicates via an interchain messaging protocol this could be IBC it can be hyperlane Stargate you know any one of these messaging protocols that we know and love um and so what this means is if we were able to build a vaults protocol on top of univ universal accounts we would be able to use intents to solve for the rebalances and then we'd be able to write custom protocol Logic on top of that account with bakedin authorization to do the share calculation and the order execution which is actually quite cool um and yes this type of model scales very well across different chains you have the authentication and you can uh send a message from any chain to any other chain and it's all authorized via the Hub so something that's not mentioned on the slide is that this middle account here is acting as the client and the The Hub and these right and left accounts are actually the spokes uh for this different application so we have a hub and spoke model that also uses intense um so if we go back to our problem at the beginning of the presentation we know that yes chain abstraction unifies balances unifies or allows you to transfer any asset to any other chain and uh swap any asset for any other but yes it has limitations though if you combine it with a protocol level protocol level logic installed on those Universal accounts you can actually build amazing cross-chain protocols um solving for the fragmented liquidity and decentralizing that execution um this is actually something that we are using at abstract money to tokenize uh institutional investing strategies called Factor assets we use orchestration which is the the term for uh The Hub and spoke model plus intense uh to allow for um the creation of single vaults that operate across multiple different chains with the exact same address with all of the logic um being EX uted on the universal accounts upon which the vaults are running so if we look at our Trend BTC signal here we can see there's an offchain strategist providing that signal to the Vault um The Vault will rebalance them across a Perpetual Dex and allow for the transfer of those assets um to any chain to get us the best uh best yield based on our capital in the vault uh these are asynchronous multi strategy multi chain vaults and they're super duper cool would love to chat if if any of you want to chat about this after the talk happy too CU they're cool uh so yeah come build with us uh we've been building abstract or developer infrastructure for around two years now um and uh there's a lot of really interesting applications that you can build and in my opinion every single application going forward in the next few years will be asynchronous it will be multi-chain as we move towards an application specific world so thank you very much my name is Adair and uh yeah happy eth Denver