Abacus 🛠 Building Interchain Apps with Abacus

foreign [Applause] [Music] Mexico welcome to the Abacus developer Workshop my name is York Rhodes I'm one of the lead protocol developers over at the Abacus Works team and today we're going to be doing a general overview of the Abacus system what potential projects you can build on the platform for the hackathon this weekend and kind of the future of the protocol as we see it moving forward so what is abacus Abacus is primarily a developer tool and platform that enables you guys to build interchain applications now you may have heard this term thrown around a lot interchain applications if in traditional decentralized applications a smart contract system exists on a single blockchain an abacus application which is an interchain application exists on many blockchains simultaneously and there's what we call a shared State model that these applications are architected in which um solves many problems with the kind of Monolithic architecture that most decentralized applications have employed in the ecosystem thus far um so today in this monolithic architecture decentralized app developers are faced with a choice when they set out on their journey of which blockchain they want to deploy on and this Choice has immense consequences in that it impacts the developer experience building that application out the user experience once that application actually ships and users have to interact with it typically they're kind of require knowledge of the specific blockchain that the application is deployed on as well as a platform risk that the developer team is taking on in that it may become very hard in the future for that application to migrate away from the initial platform that it deploys on and the way that most developer shops go cross chain to mitigate some of these consequences today is they go and deploy a new instance of their monolithic application on a different chain and each one of these deployments of their application exists as a tire an entirely separate deployment and set of participants call this like an island the problem that this introduces um is a fragmentation of Network effects so when an application like uniswap wants to go cross-chain whether they're trying to um mitigate the platform risk of ethereum mainnet that they're on or they're trying to provide a user experience which maybe has lower fees or lower latency for the users of their application or they just want to access some some developer primitive that exists on some other blockchain they go and deploy a new Singleton instance of their smart contracts but the set of participants of that new deployed instance is entirely distinct from the kind of canonical deployment on ethereum mainnet and this is a problem because the utility of most or the utility of any decentralized applications comes from the users and from the the network effects of the users and uniswap is only as valuable as the uh liquidity providers the decentralized lp is that are willing to provide liquidity for other users to swap tokens through and so when uniswap deploys a new instance of their application let's say polygon in order to bootstrap the utility for that deployment they basically need to deploy liquidity incentives and typically these are basically short-term injections of capital or or additional interest rates that um the Dow or the uniswap labs organization will manage to draw kind of initial traction to to a deployment that they do on a new chain but there's this kind of classical problem in the ecosystem of liquidity providers being what we call mercenary capital in that they're constantly just chasing the highest interest rate they can get for their um LP service and this these liquidity incentives that uniswap is deploying will eventually dry up because it's not sustainable for them to be just paying for people to kind of initially bootstrap their application on a new chain and the liquidity is won't be sticky so the liquidity will just migrate to wherever the next liquidity incentive is deployed whether it's from uniswap or some project which is forking their code base so what this means is um there's not great ways for applications to kind of mitigate these consequences of the blockchain they initially Deploy on in in in the market today and the way that most developer shops are are scaling cross chain is really unideal and so with Abacus we hope to solve this problem with a fairly unique approach in that instead of providing some additional blockchain with the same sorts of consequences of developers choosing our ecosystem and kind of siloing their Network effects to our ecosystem Abacus is actually a network that exists between blockchains um and the hope is that we can exist between all of the blockchains that users are on and eliminate the choice for developers of deciding which is the right blockchain ecosystem for them to deploy their system on and so they still get the the same I guess developer experience when they're choosing Abacus of writing their smart contracts once but um they're actually going to deploy those smart contracts on all of the chains simultaneously and instead of these deployments having strict boundaries between the set of participants abacus enables this connective tissue between smart contracts on different chains and between these different deployments and so we can actually get composability of the smart contracts that are deployed on all of these different blockchains through communication between the smart contracts and this basically allows us to uh concentrate our our Network effects into kind of a single Global application while making our application accessible to users that are on any blockchain so for both the end user and the developer The Experience should be quite familiar in that there's still a single chain interface for um for for interaction and for development so um no one needs to go and kind of re-architects their application in a super severe way or understand this kind of new framework new blockchain new paradigm but you eliminate this platform risk and this kind of siloing effects that you have when you depend on a single chain so how does this work so the Abacus system is implemented completely in smart contracts or the Abacus protocol I should say and we tried to break down the inter chain communication Concepts into kind of real world analogies so it should be quite easy to understand so the abiscus protocol consists of mailbox smart contracts that are deployed on all of the supported blockchains more specifically an outbox and an inbox and the outbox on each chain is uh where you you open up that mailbox and you put outbound messages for the mail service to go and you know send them off to deliver to whatever the the address is on the front of your envelope and there's various inbox inboxes on each blockchain which allow you to receive mail from other blockchains now in between these mailboxes there are validators and relayers for the purposes of this hackathon I don't think it will be super important for you to understand the nuances of the off-chain participants of the protocol um mainly the validators but just to kind of go over the life cycle of this male delivery system basically your application when it puts mail in the outbox on a specific blockchain the message is inserted into a Merkle tree and committed to by a Merkle root and these off-chain validators are basically signing each Merkle root that new messages are committing to and or rather are producing and messages once they've been signed by a quorum of validators they can be processed on the corresponding inbox contract on the destination chain so from the perspective of the application you put mail on the outbox and you receive mail from the inbox um and this all happens in smart contracts so just to kind of illustrate this process if your application exists on the spot chain over here Put mail in the outbox and then there's these off-chain participants the Abacus validators that are assigning basically commitments to these messages that you've put in the outbox and there's actually a separate role that will then go a separate permissionless role that will then go and relay the signed messages that the validators Merkel root signatures are committing to to the inboxes of various other blockchains and I guess to kind of just demonstrate the power of or potential of this type of communication to um compose into quite complex application logic you can imagine a single message on this blockchain over here being sent between chains to a bunch of other blockchains and then subsequently causing additional messages to be dispatched back to the origin chain and you can have you know quite complicated interchained communication just through this simple API and um you know this has pretty massive um implications from adapt developer perspective so that's kind of what I want to dig into for the purposes of this Workshop so what does it mean to build on the Abacus platform today so the Abacus Works team has built out a bunch of developer tooling for you to integrate with the protocol um today we are live on I believe um seven evm testnets as well as seven evm production main nuts um please check out our docs to keep up with progress there but um like I mentioned earlier we're hoping to basically be on to deploy the system between all of the blockchains where there's users demonstrated demands and so um you know more coming soon but uh for now we're going to focus on the evm blockchains the reason for that um hopefully it's not super controversial but today I think we recognize the evm as kind of a shelling Point within the ecosystem and um kind of confining the Abacus protocol to the ethereum execution environment allows us to have some of these nice properties of basically maintaining only a single version of our smart contracts which from a security perspective at least while we're hardening our our protocol I think is super important to kind of um minimize the attack surface area but what this also means is you guys only have to implement a single version of your smart contracts um because there's only one integration surface area so that's what I'll be going over first is the Smart contracts SDK the messaging API that that exposes which I was kind of just illustrating that's the inbox in our box API we can talk about a few libraries that we expose that you can leverage as kind of like common utilities and then this router pattern that uh is more of a specific application architecture that we think a lot of developers will benefit from but um is that required to integrate with abacus and then there's also a bunch of kind of peripheral or peripheral or higher level tooling that we've built out for developers we have a pretty extensive typescript SDK which allows you to build kind of full stack web apps as well as integrate with all of the existing like build tests deploy Frameworks um that smart contract developers use today but in a multi-chained context so I'll talk more about that in a little bit and then towards the end we'll hop into basically examples and demonstrations of the Abacus system live in action um and hopefully that'll be inspiring for you guys participating in the hackathon so let's jump into the messaging API um hopefully by now you get the general overview of sending and receiving mail so to send mail from your smart contract um to under blockchain you just call the outbox contract the Abacus has deployed on that chain you call the dispatch function on that contract and then you have to specify you know what chain are you sending this mail to what recipient contracts are you sending this mail to on that chain and then you know what is your message content and this can basically be formatted however you like um it's kind of an application specific implementation detail and then conversely to receive mail what you have to do as a smart contract developer is implement this iMessage recipient interface we specifically have to implement this handle function which takes in the origin blockchain that uh the mail was sent from so where where was the outbox contract that this mail was dispatched by uh the sender address so who which contract called the outbox.dispatch On the Origin chain and then again the kind of arbitrary message content that you can use to then go and uh you know influence control flow in your application so this is like the minimal API that we expose today and you can go and on our docs you can find the addresses and apis and interfaces for these contracts and you can actually go and dispatch costume messages without even doing any development yourself you could go and interact with the outbox on etherskin so that's pretty pretty exciting I definitely recommend you try that out maybe I'll demonstrate that at the end of this Workshop so this is really all you need to know to integrate with the Abacus system like I said there's outboxes and inboxes on each chain just to kind of elucidate what's going on with this iMessage recipient when you dispatch the message I think we talked about this earlier uh there's these off-chain participants which are relaying your your mail from the outbox that you put a message in to the corresponding inbox that you're sending to and actually this inbox smart contracts that um is part of the Abacus core protocol will do a message call with your these parameters to the recipient address as specified in in the mail so the inbox is the one that actually is doing this message call on your smart contract and so if you wanted to communicate between your own smart contracts the recipient address that you pass in the dispatch function call must be a contracts address which implements this interface on the destination chain and with with this kind of simple interface we can basically have these like kind of arbitrarily complex asynchronous communication between blockchains and between smart contracts so you know again very simple API but um it's kind of totally flips on its head the what you can do in a as a smart contract developer now you have access to this like asynchronous execution environment um you can communicate between chains now you don't have to just be confined to this state that's on the blockchain where your smart contracts are you can go and query smart contracts that are on other chains or your own smart contracts on other chains you can synchronize state um it's kind of a whole world of things you can do um but yeah I want to talk a little bit about what additional tooling we provide to kind of simplify this integration experience for you so kind of at the Smart contract Library level um we have some npm packages that you can go and add as dependencies to your project that expose these libraries so there's this Abacus Connection Manager and Abacus connection client um basically the general idea here is you need to know what addresses you're actually interfacing with um to dispatch mail and to receive mail it's you know worth noting here that you don't want any contracts to be able to call your handle function because then kind of anyone could spoof cross chain message from your contracts so you want to basically limit access control to your handle function to only kind of inboxes that are registered in the Abacus core protocol so The Advocates Connection Manager basically is like a registry of these important core protocol addresses um where the domain to inboxes mapping just Maps blockchain remote blockchain identifiers to inbox addresses on those chains um and so this connection manager is just kind of illustrative of the registry but on the client side when you're writing your smart contracts you can install this Abacus Network app npm package which exposes this abstract contract that you can inherit from the Abacus connection client is just a simple wrapper around this manager that keeps track of a manager address and state variable and allows your contracts to conveniently dispatch messages to the outbox and permission message delivery via some like only inbox modifiers and there's what should be a familiar open Zeppelin ownable owner Access Control included in in this abstract contract for modifying the Abacus Connection Manager address in storage so you can imagine your smart contract system maybe it's managed by a multi-sig or it's governed by a Dao with token voting um that multi-sig or that dial can be set as the owner of this connection client and then if there was ever a you know new deployment of the Abacus Court protocol where we needed to change the addresses of the outbox and inboxes um your multi-sig or your Dow could vote to basically upgrade the Abacus Connection Manager address to the new deployment which is again this registry of the local chains outbox and the inboxes from the supported remote chains um worth noting the Abacus Works team basically will manage a Connection Manager for you and so it's kind of Our intention that you just set this address to the registry that we manage and you don't really have to think about um upgrades or you know security vulnerabilities or things of that nature um you just think about the access control of who can change this address in your client code okay so I want to briefly talk about kind of the application architecture that we think many applications will benefit from employing and that is something we call the router pattern so like I mentioned earlier um one benefit of the evm dominance in the kind of smart contract developers world is you only have to write our contracts once but because all these blockchains are evm compatible um we can deploy the same smart contracts to all these different chains um and you know that shouldn't be taken lightly typically these blockchains are designed with like very different security properties in mind they might have quite unique user demographics and so you know this property of evm dominance I guess pervasiveness uh allows developers to basically iterate faster they only have to maintain a single smart contract surface area um but they're kind of inherently composable with any evm compatible blockchain so we've developed this router pattern that we think most smart contract developers can uh can can benefit from which leans into this evm chain interoperability that we see in in the blockchain ecosystem today so to explain a little bit what the router pattern is um it's worth digging into the analogy I guess to traditional Networks so traditional Network routers use what's called a static routing table um and and a simple routing policy to forward internet traffic that they're receiving from the rest of the internet According to some understanding of the Network's topology so you know we use the IP addressing protocol on the internet and routers use the IP addressing protocol to understand the network topology kind of like where do these computers sit in the topology and they use that knowledge of kind of this IP topology to Route traffic around the network and Abacus router smart contracts are not too dissimilar in that they're a made made aware of the network topology through a routing table which is basically a set of addresses of instances of these router contracts that exist on other chains so this pattern allows router contracts to send messages directly to each other without needing a specific address to be provided so each time your smart contracts have to communicate with each other instead of kind of in each one of those interchange communication calls providing the address of your smart contract if your application employs the router pattern it kind of is already aware of this static routing table and network topology of your system and now you have basically this interface to dispatch messages to a specific blockchain without needing to know um I guess the address of that router contract in the call and the message you want to provide and um similarly on the kind of receiving side of things mail recipients out of it of things the router pattern allows us to reject messages from untrusted applications because we have access to this Network topology and so we can basically have a generic Access Control mechanism that says that only routers which are registered in our routing table uh can successfully send our router mail and so um from the developers I guess uh consuming perspective what this means is that you have these two internal functions if you're consuming this this Library code that we provide and you don't have to think really at all about uh Access Control you see these are both internal so no other contracts can interact with these um and all you have to do as a developer is kind of populate this routing table and you can then leverage these dispatch and handle functions which make it slightly easier to have kind of a symmetric communication pattern between all of the smart contracts that exists across all of the different blockchains um as a kind of brief aside what's kind of exciting about the router pattern to me is because we're our applications logic is implemented in smart contracts we can actually have kind of arbitrarily complex routing policies and so this actually is kind of a big improvement over traditional networked routers which have you know very simple or almost circuit-based routing policies we can now have like arbitrarily complex logic that influences our routing policy and so you can imagine or I guess one one use case of this that I'm super excited about is a routing policy that minimizes the gas price of the target blockchain for your computation to be offloaded to so um you could yeah basically dispatch a message to be processed on some other chain where there's cheaper gas or cheaper fees and you get this framework for kind of routing computation based on properties of those blockchains so if there's some blockchain that has maybe like higher security or deeper liquidity for for some pair you can you know you can influence your routing policy based on um this application state which is uh when that's possible this pattern is actually called a software defined Network um I think I highly recommend you go and read up on what a software-defined network is but Abacus and this router pattern basically enables a framework for decentralized software-defined networks which I think is super cool so um okay now I quickly want to jump into the higher level tooling that the advocacy Works team has provided just as kind of utilities for developers like you who are looking to integrate with the system again we're hoping to kind of lean into the familiar evm developer experience and so I think most of you will probably be familiar with the ethers JS Library um ether's JS is kind of a library that allows you to interact with a blockchain using the Json RBC and kind of wraps up a bunch of common utilities into a node.js package and the Abacus Works team has built out this tool called a multi-provider that basically just abstracts away the mapping from blockchains to specific RPC providers and this allows your application to kind of communicate with many blockchain states at once um as well as have utilities for transaction signing and estimating gas costs of different um chains and also you know waiting on a message that was dispatched on chain a to be processed on chain B Etc I think you'll find this highly useful we also have a hard hat plug-in if you're not familiar with hard hat it's again one of these build tests deploy Frameworks for building smart contracts it integrates with the I believe chai JavaScript library that that gives you this testing syntax that I just wanted to illustrate quickly for how you can test your smart contracts cross-chain communication logic and actually unit test it so you don't have to just test everything on testnet or may not even though a lot of smart contract developers like to say they test in prod uh you can also unit test your contracts that integrate with Abacus and we expose this through an npm package you can basically deploy a mocked version of the multi-chain Abacus system to your local hard hat node this stub function will allow you to like simulate that message being relayed between the two blockchains and then you can kind of proceed with a unit test that the text that that message was actually processed you then need to go and test unit tests that whatever state change or event admission that you're expecting from that message recipient handle function has occurred according to the message that you dispatched on the source chain Okay so we've gone over building and testing um once you're ready to deploy your application we have provided this deployer tooling which basically simplifies the experience of deploying to many blockchains simultaneously at most of these abstraction layers there is router pattern specific tooling so in this case the tooling I'm just I guess this is like pseudocode but I'm just showing you a code snippet where if once you just have to implement the deployment of your contracts that implement the router pattern on a single chain and the abstraction will go and deploy your router contracts and then handle populating the routing table that I was referring to earlier as well as the management of the owner configured ownership given that this is a hackathon I think it's worth spending some time looking at some example code to get you inspired and excited about the potential of building on Abacus um I believe there's also a few abacus-specific bounties that are available for you to pursue this weekend so I definitely recommend um checking those out on the Mexico website but um yeah we're going to jump into some example application code so I assume that most of you are familiar with the erc20 standard if you are familiar with the ethereum ecosystem the erc20 standard is kind of the standard interface that the simplest token primitive must Implement to be composable with kind of all of D5 all of the exchanges where you swap tokens or um even coinbase uses this this interface right so probably the most widely used interface on ethereum blockchain in general and we have built an abacus token which extends this year T20 standard to allow for tokens to move natively between chains so if you're kind of quite embedded in the space you'll be familiar with canonical token bridging which allows uh application developers to move erc20 chains between blockchains by creating basically like a synthetic wrapper of that tokens uh application balances on chain a um to to basically migrate those um assets to chain B and the way this is accomplished is through a basically a lock mint so you lock the tokens on chain a you can then mint tokens on chain B and then when you want to kind of unwind you have to burn the tokens on chain B and then you can unlock your tokens on chain name Abacus takes a slightly different approach in that we think this kind of canonical token bridging setup leads to the same liquidity fragmentation issue issues that I discussed earlier with kind of the uniswap case study so instead of creating a wrapped representation of your token on a new chain which kind of still has this collateral or like I guess foreign debt dependency on some canonical chain that is the like canonical blockchain that your application can really never migrate away from the Abacus erc20 token has no notion of a canonical chain but where there's kind of collateral of the original token but instead if you as a developer want to leverage this implementation or choose to I guess implement this interface you can have actually natively fungible erc20s between Abacus chains so this is possible because instead of locking an existing erc20 as collateral on a source chain and then doing the mint on the destination chain and then I guess to unwrap you do the burn and then unlock instead what we do is we actually just burn the tokens on the source chain when we want to transfer assets to a remote chain and then on the destination chain we receive a message which encodes the amount of tokens which were burned on the source chain and um we mint that amount to the recipient address that was specified in the cross chain message and so what this eliminates is the concept of a canonical or collateral chain for an erc20 token so this means like any application which builds with with the standard in mind is never I guess never has this platform uh embedding effects that uh prevents them from migrating their application state or their users to a new chain um without this kind of foreign collateral risk so this is kind of especially relevant to some recent uh token Bridge hacks that we've seen in the Wilds because there's kind of this like property of existing token bridges that all of the collateral uh exists in the same smart contract and so there is this massive honey pot that any token Bridge uh basically attracts the attention of uh hackers that um if they're able to to hack one of these token Bridges they get access to all of the collateral um that's locked up in that one contract which is kind of super scary and as an application developer you have this like shared risk with all the other applications that are using the same token Bridge you are and so um your the likelihood that that your projects uh is going to get hacked I guess is Amplified by the aggregate value of collateral that's locked up in that token Bridge and so with an abacus erc20 you eliminate this kind of shared risk um of collateral because you don't have any escrow so there's no uh single contract that has kind of all this collateral collateral risk embedded in it um other than the I guess uh transfer remote functions themselves but the point is there's no uh there's no risks shared with other applications you can deploy an advocacy or C20 and another application can deploy the same system and you'll actually have kind of application specific token Bridges because there's no again no concentrated collateral risk um and so we kind of view this as I guess safer or preferable to canonical token bridges for a few different reasons hopefully I explained some of them well but even Beyond token bridging um I think in future most decentralized applications will choose to employ a pattern like this because of all the benefits that you know we went over near the beginning of the presentation again you don't have this platform risk you can basically meet users on any blockchain that they're already on um and be immediately composable with all of the applications that they already use on that chain um and anytime you identify a new blockchain with kind of a burgeoning ecosystem you can go and just add that uh you can deploy one of these outer contracts to that new chain populate the routing table of all the other chains with that new deployment and a new blockchain identifier and then you get the native fungibility of your token uh to that to that new chain without um kind of having to construct this synthetic wraps representation of the I guess canonical token um I guess just a illustrate the nft version of this um we have basically the same functionality um as that ERC set as the erc20 except we've also done it for the 721 which is the nft standard again this just extends the existing standard with a transfer remote function that allows you to specify in addition to kind of a recipient address like you would on a local chain there's now also a destination blockchain where that recipient is and the specific token that you want to transfer this is consistent with the kind of local transfer interface and again we're just burning and minting the specific um nft identifier on each chain so there's there's no wrapping there's no canonical representation of all the chains that these router contracts are deployed on should be natively fungible um it's worth noting that this is a very kind of naive implementation of a cross-train 721 in that um when you introduce multiple blockchains to an nft collection you have this problem of identifier collisions what that basically means is you need to ensure that the same uh identifier within your collection let's say you have a collection of like ten thousand nfts what that means is you have nft identifiers from like one to a thousand to ten thousand excuse me you in the minting process you basically can't allow those identifier the same identifier to be minted on multiple chains because what that means is when someone transfers uh token 500 from chain a to chain B and 500 already exists on chain B now you have two people who own the same token ID so obviously that's a problem um this naive implementation I guess basically intends to mint all of the 721s on a single chain just in the initialize function um and and later the the player can go and distribute those to other trains but you can imagine a scheme where each chain is allocated a specific subset of identifiers for like the minting phase um which allows you to load balance the uh I guess execution the minting execution so there's this uh I guess another like classic problem with the ethereum ecosystem when there's a big nft launch uh you know let's say noun style is launching a new uh a new collection and there's ten thousand nfts available for for public mint there's this problem where uh thousands and thousands of users are simultaneously trying to use the same kind of single thread ethereum execution environment to mint um get lucky and admit one of these nfts and you get this problem that uh you basically have this like priority gas auctions like gas Classical Gas Wars and you end up congesting congesting the network unnecessarily um and kind of like boosting up the gas price for everyone else on the network who isn't even necessarily aware of this nft mint that's that's ongoing and so with Abacus we could imagine a scheme where we're load balancing that minting congestion across all the Abacus supported chains um and you know this allows you to um reduce the fees for your users who want to participate in the mint because you don't have to fight in these like pgas you can also allow users now to Mint on the chain that they're already on I think it's like always a point of confusion or friction for nft projects who let's say they're deploying on Avalanche because they want the mint to be cheap they need to now go and get all their users to use a token bridge to move to Avalanche quite often those users don't know how to do token bridging or they get scammed and then their nft is stuck on Avalanche even though they're polygon users or their Avalanche or rather ethereum users and they can't move that nft around they can't use it as collateral they can't LP it and pseudo swap Etc so this is a scheme which allows nft developers to make their token natively fungible you can load balance them in I think this is like a super low hanging fruit if you guys want to extend this implementation to accommodate for that sort of minting scheme that acknowledges that you can have token identifier collisions and manages kind of specific identifier range allocations for different chains that would be a super cool hackathon project and then um I guess those two tokens should be kind of a great demonstration of how to get started just thinking about the kind of interchain application model but I also want to briefly touch on this um template which kind of uh is a great place for you to start from if you want the kind of full stack of SDK tooling that we've built out um to be like configured with with sane defaults um so there's like a hello world contract it employs the router pattern kind of demonstrates a simple cross-train message we are actually using this as kind of like a health check that we're running on a Cron job between all of our supported chains to ensure that messages are actually processing and you should be able to go and just click this button use this template and Fork this repo and this will be a great starting point for you in setting up your hackathon project um so let's go through a few kind of further project ideas that um I think would be really really awesome for you to explore um and would definitely satisfy uh kind of the Abacus specific hackathon prize so if you are familiar with kind of lending markets on in a single chain context things like compound and Ave have these systems where you can put up collateral and take out a loan against your collateral um with some sort of like automated liquidation you could imagine a scheme taking this cross chain where you can leverage uh collateral which exists on remote blockchains so if you want if you have maybe a crypto Punk on ethereum um that you're you don't want to move to a lower security environment but you'd love to have a usdc loan on uh polygon just so that you can you know pay the bills um you could use that crypto punk as collateral in a cross-chain landing Market um and you can use abacus to kind of do the state synchronization um I think we talked about the uniswap example at length so I won't go into too much detail but you can imagine building a cross chain index decentralized Exchange where you have Global uh or unified liquidity pools such that you don't have this like fragmentation of network effects and um you know someone lping on chain a or doing a swap on chain B um can tap into kind of the global or aggregate view into um all of the liquidity which is being provided on any chain another idea is doing a proof of stake yield aggregator um this would be kind of like an interface into managing um staking on chains which have like a native proof of stake emissions so um I don't know how many of those chains are available uh in production today but I think this would be like a quite a useful tool for uh you know users and and staking providers alike to manage positions across uh multiple of these proof stake chains um you could build a cross-chain ens or name service um for resolving kind of more human readable identifiers for specific addresses or specific pairs of blockchain and addresses this could happen atomically in the sense that you are replicating this registry across all the chains using abacus or conversely is going to happen asynchronously in that you do a you know if you want to resolve an ethereum name on Avalanche you do an asynchronous query to the ethereum mainnet blockchain lookup specific addresses uh corresponding or rather specific names corresponding ethereum address and then return that back to Avalanche for kind of use in application logic um I talked a little bit about this liquidity bootstrapping problem that kind of some of the incumbents have encountered when deploying or going cross-chain you can imagine building a balancer has this tool let me just pull it out balancer liquidity bootstrapping pools um lbps basic premise here is this is used to kind of bootstrap uh liquidity on a new deployment and you can imagine using Abacus to move around these uh liquidity incentives um with bouncer or whatever I guess bouncers supported um or you know you can even deploy your own lbps but uh yeah yeah I think you know this is just the tip of the iceberg um hopefully this gives you a general idea of like the potential of Abacus to disrupt some of the existing dap architectures um and yeah like I said any of the above would um certainly satisfy the hackathon prize that we have available for you guys so good luck with the hackathon hopefully uh we'll hear from you in our Discord um but um we always like to say that we are hiring so if you do choose to integrate with Abacus with one of these projects or even if you don't we'd love to hear from you um you can reach out to us via email I'd also probably just refer you to our website use abacus.network where you can get kind of all the relevant socials please hop in our Discord follow us on Twitter and check out the docs I think this will be kind of First Resource for you during the hackathon if all else fails contact us and Discord for for additional help debugging or any questions you have about system and yeah I will be in person at the hackathon so I'm available to answer any questions or kind of sit by with you and maybe do some pair programming yep that's the end of my presentation I'm excited to see what you guys end up building and good luck