Let’s stop trying to be liquidity protocols

Please fol­low and like us:
Pin Share

After a num­ber of large-scale exploits of bridges, a lot of oxy­gen is being giv­en to the nar­ra­tive that cross-chain tech­nol­o­gy is inher­ent­ly flawed — that cross-chain inter­op­er­abil­i­ty means risk. With an esti­mat­ed $2 bil­lion lost across 13 bridge hacks this year, it’s becom­ing increas­ing­ly dif­fi­cult to ignore this argument.

At deBridge, we think that it’s not only imper­a­tive but inevitable that all cross-chain bridges com­plete­ly rethink their approach to liq­uid­i­ty aggregation.

The limitations of locked liquidity

By lock­ing liq­uid­i­ty to pro­vide cross-chain rout­ing (as almost every bridge does right now), bridges have placed them­selves in a com­pe­ti­tion they’re bound to lose. We’re see­ing bridges face off against estab­lished, pur­pose-built liq­uid­i­ty pro­to­cols like AAVE, Com­pound, and Frax, projects that will undoubt­ed­ly mon­e­tize liq­uid­i­ty more effec­tive­ly and secure­ly. Exam­ples abound of bridges with hun­dreds of mil­lions of dol­lars in TVL, with extreme­ly low uti­liza­tion of locked liquidity.

With this design, bridge projects are forced into run­ning unsus­tain­able liq­uid­i­ty min­ing cam­paigns that fail to offer long-term cap­i­tal effi­cien­cy solu­tions. Unless token incen­tives are main­tained indef­i­nite­ly — an unsound ambi­tion for any project — liq­uid­i­ty providers will inevitably remove cap­i­tal to pur­sue high­er-yield­ing opportunities.

To aggre­gate liq­uid­i­ty safe­ly, bridges would need to acquire insur­ance poli­cies to let liq­uid­i­ty providers have the abil­i­ty to hedge risks. This is anoth­er expense that makes liq­uid­i­ty mon­e­ti­za­tion even more dif­fi­cult. That’s why most exist­ing bridges are not prof­itable, as costs and paid liq­uid­i­ty min­ing rewards often exceed the protocol’s net profit.

There are also archi­tec­tur­al con­sid­er­a­tions at play here, giv­en that a cross-chain val­ue trans­fer is a request that can be set­tled in dif­fer­ent ways. All exist­ing bridges set­tle these orders from their own liq­uid­i­ty pools where liq­uid­i­ty is con­tin­u­ous­ly locked when it’s need­ed only at the pre­cise moment the val­ue trans­fer should be fulfilled.

The size of the order can also dif­fer — if it exceeds the size of the bridge’s liq­uid­i­ty pool, then the sender will end up with wrapped tokens or an indef­i­nite­ly suspended/stuck trans­ac­tion. On the oth­er hand, if the order is too small for the liq­uid­i­ty pool’s size, the liq­uid­i­ty uti­liza­tion is very low and inef­fi­cient. This vicious cir­cle fur­ther high­lights that this liq­uid­i­ty pro­to­col approach to bridge design is inef­fec­tive and fun­da­men­tal­ly wrong.

Solving the security problem

As impor­tant of an issue as this is, eco­nom­ic unsus­tain­abil­i­ty is not the only main chal­lenge here. Even sup­pos­ing bridges fig­ured out a way to use the locked liq­uid­i­ty approach and stay cap­i­tal-effi­cient, by now, it’s evi­dent that build­ing a secure liq­uid­i­ty pro­to­col is an all-con­sum­ing task. Indeed, by know­ing­ly or unknow­ing­ly becom­ing liq­uid­i­ty pro­to­cols, bridge projects are giv­ing them­selves the immense task of safe­guard­ing a mul­ti-faceted attack surface.

To start high lev­el, one of the evi­dent issues with a locked liq­uid­i­ty-style bridge is that it cre­ates a risk-mul­ti­pli­er effect, where the vul­ner­a­bil­i­ties of one sup­port­ed chain can spill over to com­pro­mise cap­i­tal held in oth­er ecosystems.

Here, there’s the issue of secu­ri­ty by proxy. A bridge can have its entire liq­uid­i­ty base com­pro­mised if there’s a poten­tial vul­ner­a­bil­i­ty in the code­base of one sup­port­ed blockchain/L2. We saw this pos­si­bil­i­ty ear­li­er this year with a vul­ner­a­bil­i­ty dis­cov­ered in Opti­mism, which would have allowed attack­ers to mint an arbi­trary quan­ti­ty of assets and fore­see­ably exchange these for tokens in oth­er ecosystems.

Again, any issues with the con­sen­sus mech­a­nism of one chain can also lead to sys­temic con­ta­gion, putting at risk any liq­uid­i­ty locked in oth­er sup­port­ed chains. In this case, the bridge sim­ply broad­casts the exploit to oth­er chains. This could include 51% attacks or oth­er pro­to­col-lev­el failures.

Aside from these types of inher­it­ed risks, we’re increas­ing­ly see­ing sit­u­a­tions where mis­takes by the bridge projects them­selves have, in one way or anoth­er, caus­ing a loss of locked liq­uid­i­ty. From botched pro­to­col upgrades, poor smart con­tract design, or com­pro­mised infra­struc­ture of val­ida­tors, there are many sce­nar­ios where bad actors can exploit vul­ner­a­bil­i­ties in the bridge itself.

All these risks are quick­ly com­pound­ed and — as we’ve seen on too many occa­sions — are even­tu­al­ly born by liq­uid­i­ty providers when they lose the redeema­bil­i­ty of their wrapped assets. Such a pos­si­bil­i­ty should be unacceptable.

Few are deny­ing the vast promise of cross-chain inter­op­er­abil­i­ty to push Web3 adop­tion to new heights. But with the sheer size and fre­quen­cy of bridge exploits, it has become painful­ly clear that the fun­da­men­tal design of bridg­ing tech­nol­o­gy needs to be reimag­ined from first prin­ci­ples. The bridge-turned-liq­uid­i­ty-pro­to­col design just isn’t working.

Is there any way we can devise a fun­da­men­tal­ly new and unique approach to bridge design, one that com­plete­ly removes risks for liq­uid­i­ty providers, elim­i­nates attack vec­tors, and at the same time pre­serves the high­est lev­el of cap­i­tal efficiency?

There may be exact­ly that in the near future. At deBridge, we are work­ing on a new cross-chain liq­uid­i­ty rout­ing that solves all these prob­lems. Stay tuned.

Guest post by Alex Smirnov from deBridge Finance

Alex Smirnov is a math­e­mati­cian, researcher, devel­op­er, and blockchain enthu­si­ast. He’s the CEO and Co-Founder of deBridge, a gener­ic mes­sag­ing and cross-chain inter­op­er­abil­i­ty pro­to­col, where he focus­es on pro­to­col design, prod­uct man­age­ment, part­ner­ships, and oper­a­tions. Alex co-found­ed Phe­nom, a blockchain research, and devel­op­ment com­pa­ny, and he has also led a team that has won numer­ous hackathons and devel­oped var­i­ous blockchain solu­tions and dApps.

Learn more →



Source link

Please fol­low and like us:
Pin Share

Leave a Reply

Your email address will not be published. Required fields are marked *