Lodge Letter #59

A word from our founder. More than that, a vision. Elk’s vision. Kava incoming. And Dexioprotocol are joining with Elk for some outside action.

The Elk Vision

Reading through the information, excitement and opportunities in blockchain and Web3 interoperability and one can see that both cross-chain messaging layers and value transfers are both important areas being explored. Multiple options have been described, and still further ideas are being experimented with.

Elk too is growing our solution for cross-chain interactions that are simple, secure, fast and, above all, decentralized. For transparent, trustless Web3 architecture we hold that the tenet of true decentralization is a given. But it must be robust.

What are the advantages Elk has over the “competition”? And are they really competition in the business sense of the word? For interoperability we are looking to communicate, and for that we must trust. Well, perhaps verify, not trust.

It’s fair to say that the free market allows for the existence of multiple solutions to similar problems, from aerospace to zoology! We have many different forms of air travel and freight, and many ways to research and conserve our natural environment; the subtle differences between the various solutions allow for many to thrive. And thrive they do, working alongside one another (and yes, sometimes against), but all the time carving out specialisms and gaining invaluable expertise along the way.

Wormhole, Axelar, Cosmos, Stargate, Connext, and most other bridging/comms protocols in the Web3 DeFi space are also looking at building cross-chain messaging systems, along with asset transfer — follow the money, right?

Why are they building cross-chain messaging?

Because they think they need it (since Chainlink, Elk, and a few other projects are doing it). But how they plan to use it is where it differs: Chainlink has a clear purpose for messaging (oracles); but many other protocols don’t. The extent to which they will support data transfers is probably oracle mirroring and being able to call a function on the target chain. Is that really a compelling use-case?

Perhaps it’s a blockchain application of Jamie Zawinski’s Law of Software Envelopment?

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

Maybe the centralized bridges that serve Web asset transfers so well (those who haven’t been “hacked” anyway) now fear replacement by those with a messaging layer?

Elk’s founder, Baal, has a vision for cross-chain messaging that differs somewhat from that:

Firstly

Users don’t want to think about which blockchain they are using. And developers don’t want to bother with spaghetti code that deals with things like “oh, this one is from another chain, but this is local”.

Elk provides a BaaS (Bridge-as-a-Service) API that completely abstracts away these issues into two contracts and leaves the rest as is. Everything remains transparent for the user and, with enough UI work, one can completely hide the fact that there are multiple chains underneath.

Secondly

Developers don’t want to have to think about the possible cross-chain consistency and failures that could result from low-level messaging like what is proposed. Too complicated.

Elk provides recipes and high-level APIs for common patterns, and we tie those APIs to specific events related to token transfers.

Thirdly

This is where it becomes interesting. It can be argued that the logic for cross-chain applications doesn’t belong in either chain involved. It belongs inbetween. In other words, if one is familiar with end-to-end arguments, the argument is that endpoints are the wrong place to implement that functionality. (Why? Because you are breaking the abstraction of the blockchain).

What we want to build with ElkNet is this layer inbetween, and make that the place where cross-chain happens. So rather than build your entire application on the end chains, you build some of it directly inside ElkNet.

Some examples of what you could do: cross-chain order management/order book, batching of transfers/data, scheduling actions, events processing from non-blockchain sources, integration with web2, etc. Elk could actually build an arbitrage bot directly inside ElkNet.

Most of these use-cases are impossible to implement in a system where you have only two blockchains and a dumb messaging layer in between.

Finally

The ultimate vision of ElkNet would be a kind of multi-chain rollup, kind of like a Layer 3, but probably not a rollup based on EVM.

Bridging-as-a-Service (BaaS)

If you’d like to see the (evolving) documentation for the BaaS SDK then check it out here: https://docs.elk.finance/for-developers/bridge-as-a-service-baas

(This is a living document with additions and adjustments occurring as needs dictate.)

New chain alert — Kava

Following some rather fruitful discussions, the Kava EVM is mostly deployed and final testing and tweaks are being made. Keep your eyes on our social channels for the go-live announcement.

Future partnerships taking shape

In the coming weeks we will be working alongside Dexioprotocol in a little something for our communities. Elk and Dexioprotocol fun will be available IRL, that’s all we’ll say for now.

Well, we can also say about $1000 in ELK will be available for those taking part in the frivolities…