This proposal outlines the advancement of a cutting-edge bridge infrastructure solution for Uniswap called MMA (Multi-Message Aggregation), initially rolling out cross-chain governance on Arbitrum and subsequently enabling general purpose cross-chain messaging capabilities for all Uniswap deployments across chains.
Uniswap is the largest DEX in the Arbitrum ecosystem, providing a secure and reputable infrastructure for DeFi users. Since adding support for Arbitrum, the bridge used for cross-chain governance has incurred issues, resulting in significant downtime and the inability to send messages to Uniswap’s Arbitrum deployment. Fortunately, this issue was promptly addressed. Other deployments of Uniswap have also faced similar issues, such as the Celo Optics bridge, which has been down since last year. Needless to say, as Uniswap expands across various ecosystems, one can expect more complex issues to arise. Considering this, we have actively engaged with the Uniswap Foundation, sharing our thoughts on a Multi-Bridge, Agnostic Solution for establishing a more secure infrastructure that underpins Uniswap cross-chain deployments. As the leading bridge and DEX aggregator, LI.FI provides simplified access to cross-chain transactions (bridge, swap, message passing) in a solution-agnostic manner.
We propose allocating a portion of ARB tokens to promote infrastructure development, starting with a bridge agnostic, Multi-Message Aggregation (MMA) solution for cross-chain governance that would benefit Uniswap, Arbitrum, and other supported ecosystems. Used wisely, the funds allocated to the Uniswap DAO have the ability to make a significant impact. Such critical infrastructure requires funding from the entire ecosystem, but due to certain constraints, this is not easy. Thus, we request the Uniswap and Arbitrum communities to take the lead in fostering the development of such key infrastructure, paving the way for the wider industry to follow suit.
The increasing number of security assumptions and implementation details across arbitrary messaging bridges (AMBs) underscores the value of an aggregated solution like MMA, which relies on message verification across multiple bridge designs. We envision MMA to be a long-term governance solution for Uniswap on Arbitrum and other chains, as well as having the potential to be used as an extensible solution for any dApp that wants to execute cross-chain governance without relying on a single AMB.
LI.FI believes MMA is an avenue with the potential to create substantial long-term value for Uniswap, Arbitrum, and the entire crypto industry.
However, building a reliable multi-bridge agnostic solution for cross-chain governance is a complex task that requires an extensive amount of development time, bridge expertise, and ongoing maintenance. With that in mind, we propose that Uniswap grants 250k ARB to LI.FI to build an MMA governance module for Uniswap V3 on Arbitrum.
Our team is already actively engaged in the process of building an MMA module tailored to meet Uniswap’s requirements for a secure and reliable system for cross-chain governance. Our initial deployment will showcase this system between Ethereum and Arbitrum, exclusively for Uniswap's benefit. Subsequently, we plan to expand its reach by combining multiple Uniswap deployments with the MMA, encompassing all chains that Uniswap exists on.
Additionally, to further enhance the MMA’s capabilities, we intend to incorporate support for new messaging bridges, upgrade existing adapters alongside any underlying messaging bridge updates, and extend variations of the MMA to other protocols seeking to secure their multi-chain implementations.
Overall, we intend to create MMA as a modular solution that can be extended to use-cases outside of cross-chain governance. In other words, a modular MMA design can be optimized to meet the diverse needs of different cross-chain message passing use cases, like cross-chain credit scoring, for example. We envision an expanded form of MMA with various modules to resemble the following modular structure:
In addition, a key problem with complex MMA infrastructure is maintenance and adaptation in such a fast-moving space. The core MMA contract is immutable, but multiple adapters need to be maintained. Currently, this is delegated to multiple bridges but there’s coordination needed to make this process work seamlessly without interrupting functionality. LI.FI, as a neutral, bridge-agnostic party with the relevant knowledge, would be greatly suited to take care of this ongoing maintenance.
Having processed over USD 1.3 billion dollars in transactions, LI.FI is known as one of the leading bridge aggregators in the space and provides simplified access to cross-chain capabilities across ecosystems in a solution-agnostic manner.
LI.FI has been around for over two years as an unbiased aggregator of 15+ bridges and is well-positioned in terms of market neutrality and domain expertise to oversee the development of an MMA solution.
LI.FI’s entire mission is to follow the fast paced change of the industry and abstract integration and maintenance away from those who work with us.
As currently proposed, this maintenance is delegated to multiple bridges; however, coordination is needed to make this process work seamlessly without interrupting functionality. LI.FI, being a neutral, bridge-agnostic entity with extensive experience in maintaining multiple bridge integrations and a deep understanding of various messaging bridges (as demonstrated by our comprehensive AMB comparison framework), would be highly qualified to handle all future maintenance tasks.
As stated above, we believe an allocation of 250k ARB tokens is necessary to securely build MMA on Arbitrum and effectively maintain MMA across further Uniswap deployments, along with other dApps.
The specific usage of these ARB tokens, over the next year would be:
We plan to assemble a dedicated and capable team to actively develop the required infrastructure technology and onboard other protocols, and enterprises within and beyond Arbitrum's ecosystem. Our ideal team composition includes:
– 1 Project Manager: Akshaya Nagaraja
– 1 Lead Smart Contract Developer: Sujith Somraaj
– 2 Smart Contract Developers: Ed Zynda and Daniel Bläcker
– 1 Protocol Researcher: Arjun Chand
– Active involvement from LI.FI’s CTO Max Klenk and CEO Philipp Zentner
The grant will be divided into two parts: 75k ARB for the initial deployment, and the remaining 25k ARB will be allocated towards the ongoing maintenance of the protocol.
With MMA being a governance solution, we believe security is paramount. We intend to conduct a community-centric bug bounty program, incentivizing participation from white hat hackers and security experts within the ecosystem. This program will aim to thoroughly test the infrastructure's resilience and security.
To ensure the development of the most secure multi-bridge messaging solution, we recognize the necessity of conducting regular audits. Allocating 75k ARB tokens will enable us to engage reputable auditing firms, thereby enhancing the overall security of the infrastructure.
Our roadmap for the first year of building MMA is split into 2 major tentative phases:
Phase 1: MMA Module for Uniswap’s Cross-Chain Governance
Duration: 6 months
During this phase, our focus will be on customizing (first 3 months) and battle-testing (last 3 months) the solution to best serve the needs of Uniswap.
The customization face will involve building MMA, creating adaptors for initial bridges selected by the Uniswap Bridge Committee, making MMA contracts more efficient, among other things.
The battle testing phase will involve testnet implementations, professional audits, community audits, and an initial roll-out of MMA on Arbitrum.
Phase 2: V2 of MMA to build modules for other cross-chain use-cases
Duration: 6 months
During this phase, we intend to expand MMA’s capabilities by adding support for new messaging bridges, upgrading existing adapters if and when the underlying messaging bridges upgrade, and offering variations of MMA to other protocols that want to use it to secure cross-chain governance.
Additionally, we will begin exploring other ways to commercialize MMA as an enterprise offering alternative use-cases.
The next steps for this would be:
By implementing this roadmap, LI.FI aims to contribute to the development of Uniswap, Arbitrum, and the wider cross-chain DeFi ecosystem, providing secure and efficient cross-chain messaging infrastructure for dApps and enterprises.
This proposal outlines the advancement of a cutting-edge bridge infrastructure solution for Uniswap called MMA (Multi-Message Aggregation), initially rolling out cross-chain governance on Arbitrum and subsequently enabling general purpose cross-chain messaging capabilities for all Uniswap deployments across chains.
Uniswap is the largest DEX in the Arbitrum ecosystem, providing a secure and reputable infrastructure for DeFi users. Since adding support for Arbitrum, the bridge used for cross-chain governance has incurred issues, resulting in significant downtime and the inability to send messages to Uniswap’s Arbitrum deployment. Fortunately, this issue was promptly addressed. Other deployments of Uniswap have also faced similar issues, such as the Celo Optics bridge, which has been down since last year. Needless to say, as Uniswap expands across various ecosystems, one can expect more complex issues to arise. Considering this, we have actively engaged with the Uniswap Foundation, sharing our thoughts on a Multi-Bridge, Agnostic Solution for establishing a more secure infrastructure that underpins Uniswap cross-chain deployments. As the leading bridge and DEX aggregator, LI.FI provides simplified access to cross-chain transactions (bridge, swap, message passing) in a solution-agnostic manner.
We propose allocating a portion of ARB tokens to promote infrastructure development, starting with a bridge agnostic, Multi-Message Aggregation (MMA) solution for cross-chain governance that would benefit Uniswap, Arbitrum, and other supported ecosystems. Used wisely, the funds allocated to the Uniswap DAO have the ability to make a significant impact. Such critical infrastructure requires funding from the entire ecosystem, but due to certain constraints, this is not easy. Thus, we request the Uniswap and Arbitrum communities to take the lead in fostering the development of such key infrastructure, paving the way for the wider industry to follow suit.
The increasing number of security assumptions and implementation details across arbitrary messaging bridges (AMBs) underscores the value of an aggregated solution like MMA, which relies on message verification across multiple bridge designs. We envision MMA to be a long-term governance solution for Uniswap on Arbitrum and other chains, as well as having the potential to be used as an extensible solution for any dApp that wants to execute cross-chain governance without relying on a single AMB.
LI.FI believes MMA is an avenue with the potential to create substantial long-term value for Uniswap, Arbitrum, and the entire crypto industry.
However, building a reliable multi-bridge agnostic solution for cross-chain governance is a complex task that requires an extensive amount of development time, bridge expertise, and ongoing maintenance. With that in mind, we propose that Uniswap grants 250k ARB to LI.FI to build an MMA governance module for Uniswap V3 on Arbitrum.
Our team is already actively engaged in the process of building an MMA module tailored to meet Uniswap’s requirements for a secure and reliable system for cross-chain governance. Our initial deployment will showcase this system between Ethereum and Arbitrum, exclusively for Uniswap's benefit. Subsequently, we plan to expand its reach by combining multiple Uniswap deployments with the MMA, encompassing all chains that Uniswap exists on.
Additionally, to further enhance the MMA’s capabilities, we intend to incorporate support for new messaging bridges, upgrade existing adapters alongside any underlying messaging bridge updates, and extend variations of the MMA to other protocols seeking to secure their multi-chain implementations.
Overall, we intend to create MMA as a modular solution that can be extended to use-cases outside of cross-chain governance. In other words, a modular MMA design can be optimized to meet the diverse needs of different cross-chain message passing use cases, like cross-chain credit scoring, for example. We envision an expanded form of MMA with various modules to resemble the following modular structure:
In addition, a key problem with complex MMA infrastructure is maintenance and adaptation in such a fast-moving space. The core MMA contract is immutable, but multiple adapters need to be maintained. Currently, this is delegated to multiple bridges but there’s coordination needed to make this process work seamlessly without interrupting functionality. LI.FI, as a neutral, bridge-agnostic party with the relevant knowledge, would be greatly suited to take care of this ongoing maintenance.
Having processed over USD 1.3 billion dollars in transactions, LI.FI is known as one of the leading bridge aggregators in the space and provides simplified access to cross-chain capabilities across ecosystems in a solution-agnostic manner.
LI.FI has been around for over two years as an unbiased aggregator of 15+ bridges and is well-positioned in terms of market neutrality and domain expertise to oversee the development of an MMA solution.
LI.FI’s entire mission is to follow the fast paced change of the industry and abstract integration and maintenance away from those who work with us.
As currently proposed, this maintenance is delegated to multiple bridges; however, coordination is needed to make this process work seamlessly without interrupting functionality. LI.FI, being a neutral, bridge-agnostic entity with extensive experience in maintaining multiple bridge integrations and a deep understanding of various messaging bridges (as demonstrated by our comprehensive AMB comparison framework), would be highly qualified to handle all future maintenance tasks.
As stated above, we believe an allocation of 250k ARB tokens is necessary to securely build MMA on Arbitrum and effectively maintain MMA across further Uniswap deployments, along with other dApps.
The specific usage of these ARB tokens, over the next year would be:
We plan to assemble a dedicated and capable team to actively develop the required infrastructure technology and onboard other protocols, and enterprises within and beyond Arbitrum's ecosystem. Our ideal team composition includes:
– 1 Project Manager: Akshaya Nagaraja
– 1 Lead Smart Contract Developer: Sujith Somraaj
– 2 Smart Contract Developers: Ed Zynda and Daniel Bläcker
– 1 Protocol Researcher: Arjun Chand
– Active involvement from LI.FI’s CTO Max Klenk and CEO Philipp Zentner
The grant will be divided into two parts: 75k ARB for the initial deployment, and the remaining 25k ARB will be allocated towards the ongoing maintenance of the protocol.
With MMA being a governance solution, we believe security is paramount. We intend to conduct a community-centric bug bounty program, incentivizing participation from white hat hackers and security experts within the ecosystem. This program will aim to thoroughly test the infrastructure's resilience and security.
To ensure the development of the most secure multi-bridge messaging solution, we recognize the necessity of conducting regular audits. Allocating 75k ARB tokens will enable us to engage reputable auditing firms, thereby enhancing the overall security of the infrastructure.
Our roadmap for the first year of building MMA is split into 2 major tentative phases:
Phase 1: MMA Module for Uniswap’s Cross-Chain Governance
Duration: 6 months
During this phase, our focus will be on customizing (first 3 months) and battle-testing (last 3 months) the solution to best serve the needs of Uniswap.
The customization face will involve building MMA, creating adaptors for initial bridges selected by the Uniswap Bridge Committee, making MMA contracts more efficient, among other things.
The battle testing phase will involve testnet implementations, professional audits, community audits, and an initial roll-out of MMA on Arbitrum.
Phase 2: V2 of MMA to build modules for other cross-chain use-cases
Duration: 6 months
During this phase, we intend to expand MMA’s capabilities by adding support for new messaging bridges, upgrading existing adapters if and when the underlying messaging bridges upgrade, and offering variations of MMA to other protocols that want to use it to secure cross-chain governance.
Additionally, we will begin exploring other ways to commercialize MMA as an enterprise offering alternative use-cases.
The next steps for this would be:
By implementing this roadmap, LI.FI aims to contribute to the development of Uniswap, Arbitrum, and the wider cross-chain DeFi ecosystem, providing secure and efficient cross-chain messaging infrastructure for dApps and enterprises.
Great proposal. I would tend to agree with Matt here on point 1. Similarly to what happened for the vote in the selection of the bridge for BNB governance deployment.
Also it seems that Li.fi with this proposal would be benefitting from both a grants and an ARB distribution as per eek637 comment. I support @eek637 comment on having such proposal handled by grants committee entirely so that accountability is upheld with clear milestones and payments.
Great proposal. I would tend to agree with Matt here on point 1. Similarly to what happened for the vote in the selection of the bridge for BNB governance deployment.
Also it seems that Li.fi with this proposal would be benefitting from both a grants and an ARB distribution as per eek637 comment. I support @eek637 comment on having such proposal handled by grants committee entirely so that accountability is upheld with clear milestones and payments.
By the way, how does the UF gets involved on these matters? is this solely through private comms channel or is there a place where UF openly discourse such thing with community and potential grantee?
I support an ARB allocation toward creating MMA infrastructure, but I think the DAO should take multiple bids before funding an entity toward this goal. Meaning, if there are other developers interested in building MMA infrastructure they should have a fair chance at getting given the job. Healthy competition is good for any hiring process.
I also think precedent for all Uniswap funded working groups should be
I support an ARB allocation toward creating MMA infrastructure, but I think the DAO should take multiple bids before funding an entity toward this goal. Meaning, if there are other developers interested in building MMA infrastructure they should have a fair chance at getting given the job. Healthy competition is good for any hiring process.
I also think precedent for all Uniswap funded working groups should be
Thanks for your comment and question @Damboy!
We have adopted a modular approach to building an MMA model for Uniswap and maintenance needs vary across different layers. As highlighted in the diagram above, the MMA model has 2 layers: the Configuration Layer (outermost layer) and the Transport Layer (middle layer).
1. The Configuration Layer:
Thanks for your comment and question @Damboy!
We have adopted a modular approach to building an MMA model for Uniswap and maintenance needs vary across different layers. As highlighted in the diagram above, the MMA model has 2 layers: the Configuration Layer (outermost layer) and the Transport Layer (middle layer).
1. The Configuration Layer:
The Configuration layer holds the logic related to the validation architecture of the MMA Module. This includes configurations like the list of bridges to use, how many bridges need to pass the quorum for the message to be considered valid, time limit, etc.
For instance, Uniswap can specify the validation architecture they want based on their requirement of making cross-chain messaging as secure as possible. Once this has been set, the configuration layer will remain immutable onchain unless Uniswap decides to have an option to make any changes, like adding or removing bridges. Consequently, the maintenance overhead in this layer is minimal.
Note, we are building this in a way that other dApps can later change validation architecture depending on their security needs. Our goal at the configuration layer is to offer dApps building on MMA as much flexibility as possible – meaning LI.FI will need to continue adding support for new messaging bridges, allow for different signature/time limit setups, etc.
2. The Transport Layer:
The Transport Layer of MMA is where most of the maintenance overhead will be taken care of by LI.FI. As mentioned above, we plan to keep the MMA architecture immutable and each bridge adapter contract will also be immutable individually. As a result, whenever a bridge upgrades its smart contracts and input parameters, LI.FI will need to deploy a new adapter contract for that bridge with the updated changes. The bridging ecosystem changes rapidly, and we foresee such updates taking place for each bridge in almost every quarter to every year. Ensuring such maintenance is taken care of smoothly and in a timely manner is crucial for the MMA model to run without any interruptions.
We’re closely connected to all the bridges in the industry and we get to know as soon as they start working on new versions of their contracts. This is key, as we'll need to make changes to the adapters quickly to keep MMA updated with the latest changes in the respective bridges. Additionally, we take measures to detect and resolve mismatches in bridge smart contracts and our adapters. This enables us to check for changes and resolve any inconsistencies. In addition we consistently monitor and assess the reliability of bridges and make required changes to MMA modules, if necessary.
The combination of such a modular architecture, monitoring tools, and staying up-to-date of the bridging industry as part of our core business enables us to maintain MMA for Uniswap (and other projects) for years to come.
We look forward to building MMA and appreciate any feedback you may have on our response here!
Thanks for the explanation @cshg . Looking forward to this proposal.
Great proposal. I would tend to agree with Matt here on point 1. Similarly to what happened for the vote in the selection of the bridge for BNB governance deployment.
Also it seems that Li.fi with this proposal would be benefitting from both a grants and an ARB distribution as per eek637 comment. I support @eek637 comment on having such proposal handled by grants committee entirely so that accountability is upheld with clear milestones and payments.
Great proposal. I would tend to agree with Matt here on point 1. Similarly to what happened for the vote in the selection of the bridge for BNB governance deployment.
Also it seems that Li.fi with this proposal would be benefitting from both a grants and an ARB distribution as per eek637 comment. I support @eek637 comment on having such proposal handled by grants committee entirely so that accountability is upheld with clear milestones and payments.
By the way, how does the UF gets involved on these matters? is this solely through private comms channel or is there a place where UF openly discourse such thing with community and potential grantee?
I support an ARB allocation toward creating MMA infrastructure, but I think the DAO should take multiple bids before funding an entity toward this goal. Meaning, if there are other developers interested in building MMA infrastructure they should have a fair chance at getting given the job. Healthy competition is good for any hiring process.
I also think precedent for all Uniswap funded working groups should be
I support an ARB allocation toward creating MMA infrastructure, but I think the DAO should take multiple bids before funding an entity toward this goal. Meaning, if there are other developers interested in building MMA infrastructure they should have a fair chance at getting given the job. Healthy competition is good for any hiring process.
I also think precedent for all Uniswap funded working groups should be
Thanks for your comment and question @Damboy!
We have adopted a modular approach to building an MMA model for Uniswap and maintenance needs vary across different layers. As highlighted in the diagram above, the MMA model has 2 layers: the Configuration Layer (outermost layer) and the Transport Layer (middle layer).
1. The Configuration Layer:
Thanks for your comment and question @Damboy!
We have adopted a modular approach to building an MMA model for Uniswap and maintenance needs vary across different layers. As highlighted in the diagram above, the MMA model has 2 layers: the Configuration Layer (outermost layer) and the Transport Layer (middle layer).
1. The Configuration Layer:
The Configuration layer holds the logic related to the validation architecture of the MMA Module. This includes configurations like the list of bridges to use, how many bridges need to pass the quorum for the message to be considered valid, time limit, etc.
For instance, Uniswap can specify the validation architecture they want based on their requirement of making cross-chain messaging as secure as possible. Once this has been set, the configuration layer will remain immutable onchain unless Uniswap decides to have an option to make any changes, like adding or removing bridges. Consequently, the maintenance overhead in this layer is minimal.
Note, we are building this in a way that other dApps can later change validation architecture depending on their security needs. Our goal at the configuration layer is to offer dApps building on MMA as much flexibility as possible – meaning LI.FI will need to continue adding support for new messaging bridges, allow for different signature/time limit setups, etc.
2. The Transport Layer:
The Transport Layer of MMA is where most of the maintenance overhead will be taken care of by LI.FI. As mentioned above, we plan to keep the MMA architecture immutable and each bridge adapter contract will also be immutable individually. As a result, whenever a bridge upgrades its smart contracts and input parameters, LI.FI will need to deploy a new adapter contract for that bridge with the updated changes. The bridging ecosystem changes rapidly, and we foresee such updates taking place for each bridge in almost every quarter to every year. Ensuring such maintenance is taken care of smoothly and in a timely manner is crucial for the MMA model to run without any interruptions.
We’re closely connected to all the bridges in the industry and we get to know as soon as they start working on new versions of their contracts. This is key, as we'll need to make changes to the adapters quickly to keep MMA updated with the latest changes in the respective bridges. Additionally, we take measures to detect and resolve mismatches in bridge smart contracts and our adapters. This enables us to check for changes and resolve any inconsistencies. In addition we consistently monitor and assess the reliability of bridges and make required changes to MMA modules, if necessary.
The combination of such a modular architecture, monitoring tools, and staying up-to-date of the bridging industry as part of our core business enables us to maintain MMA for Uniswap (and other projects) for years to come.
We look forward to building MMA and appreciate any feedback you may have on our response here!
Thanks for the explanation @cshg . Looking forward to this proposal.
LIFI Has Proven to have a good record so far, and this is actually a good initiative.
a key problem with complex MMA infrastructure is maintenance and adaptation in such a fast-moving space. The core MMA contract is immutable, but multiple adapters need to be maintained.
LIFI Has Proven to have a good record so far, and this is actually a good initiative.
a key problem with complex MMA infrastructure is maintenance and adaptation in such a fast-moving space. The core MMA contract is immutable, but multiple adapters need to be maintained.
You mentioned that maintenance is a challenge for complex infrastructure like MMA. Could you kindly clarify the specific strategies and processes that will be in place to ensure smooth coordination and uninterrupted functionality of the MMA solution? How will LI.FI handle the ongoing maintenance.
LIFI Has Proven to have a good record so far, and this is actually a good initiative.
a key problem with complex MMA infrastructure is maintenance and adaptation in such a fast-moving space. The core MMA contract is immutable, but multiple adapters need to be maintained.
LIFI Has Proven to have a good record so far, and this is actually a good initiative.
a key problem with complex MMA infrastructure is maintenance and adaptation in such a fast-moving space. The core MMA contract is immutable, but multiple adapters need to be maintained.
You mentioned that maintenance is a challenge for complex infrastructure like MMA. Could you kindly clarify the specific strategies and processes that will be in place to ensure smooth coordination and uninterrupted functionality of the MMA solution? How will LI.FI handle the ongoing maintenance.
Hi all,
I've chatted with the Li.fi team about MMA specifically and support this proposal in principle. Implementing multi-bridge aggregation could be an important step in the Uniswap DAO's cross-chain governance journey, and using funds from a non-Ethereum chain's air drop to drive this development forward seems fitting.
Hi all,
I've chatted with the Li.fi team about MMA specifically and support this proposal in principle. Implementing multi-bridge aggregation could be an important step in the Uniswap DAO's cross-chain governance journey, and using funds from a non-Ethereum chain's air drop to drive this development forward seems fitting.
That said, and though this proposal does a good job of defining the scope of work, administering this type of grant from the DAO poses some operational burdens for which on-chain governance is not well-suited, as I discuss here. It's also worth nothing that the UF has committed to funding an audit of the MMA code by Trail of Bits and is helping to coordinate between Li.fi, Celer, and @Kydo to move the project forward. I'd love to see this project funded with ARB either via a grants working group or the UF to make sure that roadmaps are made and milestones are hit.
Hi all,
I've chatted with the Li.fi team about MMA specifically and support this proposal in principle. Implementing multi-bridge aggregation could be an important step in the Uniswap DAO's cross-chain governance journey, and using funds from a non-Ethereum chain's air drop to drive this development forward seems fitting.
Hi all,
I've chatted with the Li.fi team about MMA specifically and support this proposal in principle. Implementing multi-bridge aggregation could be an important step in the Uniswap DAO's cross-chain governance journey, and using funds from a non-Ethereum chain's air drop to drive this development forward seems fitting.
That said, and though this proposal does a good job of defining the scope of work, administering this type of grant from the DAO poses some operational burdens for which on-chain governance is not well-suited, as I discuss here. It's also worth nothing that the UF has committed to funding an audit of the MMA code by Trail of Bits and is helping to coordinate between Li.fi, Celer, and @Kydo to move the project forward. I'd love to see this project funded with ARB either via a grants working group or the UF to make sure that roadmaps are made and milestones are hit.
This is a very well structured proposal and we believe this will be a positive infrastructure development for Uniswap. On the other hand when considering all the great proposals made regarding the ARB allocations, we believe this is more fitting for the grants program and are well aligned with @eek637 comment's.
This is a very well structured proposal and we believe this will be a positive infrastructure development for Uniswap. On the other hand when considering all the great proposals made regarding the ARB allocations, we believe this is more fitting for the grants program and are well aligned with @eek637 comment's.
