Getting Across Part 1 — Beginnings
In part 1 of our Getting Across series, we discuss the beginnings of Across Protocol with details of its conceptualization and design process.
Sushi and Strategy
On a hot day in June in New York City, UMA engineer Nick Pai and UMA co-founder Hart Lambur sat at a table at Sushi on Jones. Compared to the chatter around them, their conversation appeared to be more focused — a pinpointed discussion. They were brainstorming around the future of UMA Protocol, and what their next steps could be moving forward. So far, UMA had been focused on products like KPI options and range tokens. These products were meant to be part of the backend, as products for DAOs to help manage their treasury. Ultimately, they felt that those products were an investment banking-type service.
The duo ordered the 12-course omakase while a fresh approach was being introduced — they wanted to build a product that would showcase the power of UMA’s almighty optimistic oracle. Questions swirled around what they could do with this oracle, what some fundamental assumptions could be, and if they could create a consumer-facing product. They knew that the OO could secure anything backed by cold, hard facts, but what were the facts they wanted to secure?
L2s on the horizon
The topic turned to L2s. This was around the time that L2s started to receive a lot of attention. Meanwhile, Arbitrum had an issue of funds taking a long time to cross their native bridge. Theoretically, the optimistic oracle seemed like a perfect way to secure transfers across chains. Paired with the fact that they wanted to get away from the “just for financial contracts” idea, this seemed like it could be something big.
Pai and Lambur agreed to create and announce a foundational document titled: Insured Bridge: Brainstorm Doc. This document became the catalyst to take this thing seriously — it was really happening! Although the rest of the team was forced to operate sushi-less, the gears quickly began to turn in everyone’s minds.
Written at the top, the summary stated the following:
“The purpose of this document is to present an insured bridge infrastructure that could provide insured, cross-chain, and timely transfers that are insured by UMA’s optimistic oracle.”
Mighty Optimistic Oracle
The idea of using the optimistic oracle for a bridge was interesting to the team for a few reasons.
- If they were to build a bridge, the team wanted to make recourse a first-class feature. The optimistic oracle seemed perfect for this, as any wronged party could, for a time, dispute the result of the bridging action with the OO.
- This user-facing product seemed to be a clear use case for the oracle that would add to the ecosystem. It was an elegant way to pass messages cross-chain.
- This was in line with UMA’s mission to weave the optimistic oracle into the fabric of Web3.
Brainstorming Begins
The document acknowledged that transferring funds cross-chain was a fundamentally difficult problem. Through brainstorming the problems users had, 3 features were born:
- Fast: The transfer should be as instantaneous as possible.
- Fully insured: If the transfer fails for some reason, the user should be able to trustlessly get paid back.
- Capital efficient: Minimal amount of capital needs to be paid upfront by relayers.
Multiple iterations of the bridge were written out to determine what approach to take. Red Bulls were consumed, dates canceled and delirium was certainly beginning to kick in.
The team persisted. Multiple versions were created, each being built up and deconstructed again based on their advantages, disadvantages and open questions.
The Olden Days: 2019
In the early days of ETH2 conceptualization, there was this idea that you could insure cross-shard data — aka, “I will say this is correct, and if I’m wrong, I’m insuring it for this much money.”
The team realized that this messaging seemed to make a lot of sense for the cross-chain bridge. Ensuring that an action happened on another chain felt trackable and, well, doable.
Across and… Insurance?
The team discussed the fact that there seemed to be a lack of recourse in DeFi. They not only had to think about how to take data on-chain instantaneously but also, if that info was wrong, how the person who gave the information would have to repay the error. It was very similar to the concept of insurance, insuring the money that is received on the other side.
The Fast and Fully Insured Bridge.
After working through various versions of Across, the team arrived at a final concept: The Fast and Fully Insured Bridge.
This version put up an amount of capital and recourse for the insurance. It also relied on game theory for relayers to be fully insured mechanisms.
Side Note: Across isn’t typically thought of like this, but you can conceptually think of it as an insurance protocol: you have a lending pool, and the relayer provides instant funds to the user. If the data is wrong, they’re providing insurance for the user and the relayer is getting a premium to provide this service.
With this final iteration in tow, we realized we didn’t have a choice — the world needed us to build it! A formal announcement was made and the design process began.
Branding Goals for Across Protocol
With a green light given, the next step was for our design lead, Jesper, to create the conceptual design. Designing requires a high understanding of what works on the user interface (UI) front. A bad UI could make even a good product flop.
Jesper began the design, but it wasn’t going entirely too far. To achieve a good UI, Jesper first needed a name to give a direction to the design. The original document’s Insured Bridge name wasn’t cutting it. Suddenly, a beautiful lightbulb made out of super-secret design glitter appeared over Jesper’s head.
Across Protocol
It made sense. We wanted our users to hear the name and know they would be able to get across in a cheap, fast and secure manner.
After a bit of Figma tinkering, Jesper found the black and aqua green, colors that instantly fit with Across. They were bold, friendly and embodied “friendly techno,” an ideal vibe for the look of the protocol. The colors also felt unique — he hadn’t seen anyone in the niche who had gone with them previously. The purple and orange secondary colors then fell into place, and things were on their way. It all just fit.
A lot of inspiration for Across’ design came from the NFT space, specifically in flat illustrations. As Jesper stated, compared to the 3D illustrations he saw, “flat just fit.” Inspiration also came from Across’ parent organization — UMA. UMA also was inspired by the simplistic idea of using few colors. As a designer, this was a challenge. Jesper was excited.
There were a few things the design needed to be:
- Easy to use
- Minimalistic
- Unique
The simplistic, minimal design tied into this approach of being honest. There is a “no smoke and mirrors” policy when it comes to Across. Nothing is hidden. The platform needed to be transparent and easy to use for all.
To further promote this idea, Jesper took a unique approach with the website design.
Instead of starting with a marketing-type landing page as many DApps had done in the past, the users were brought straight to the bridge. This once again pushed the ideas of transparency and ease of use.
The design was done and agreed on, and the building process began.
The team still had a ways to go before Across’ launch, but everything seemed to be coming together, full steam ahead.
Stay tuned for next week’s article in which we’ll dive into the building aspect of Across Protocol. In the meantime, catch up on our previous Medium articles, follow us on Twitter and join the community.
