Getting Across Part 2 — Building
tl;dr The ball was rolling for the Across Protocol team as they approached the building phase. The idea for the fair fair launch was built out and decided on, and the engineers began some heavy-duty brainstorming and implementation. On the frontend, engineers were making sure everything was not only visually appealing but functional. The backend engineers were figuring out a structure for passive liquidity providers, how to rework the way they used the optimistic oracle and more.
Missed part 1? Check it out here.
Glorious goals
As discussed in our previous article, in regards to technical goals, Across Protocol had to be cheap, fast and secure.
Through many created and scrapped documents, energy drinks and virtual meetings, a few more technical goals were also established.
Through a latte-induced brainstorm, the team decided they needed a fee model that was flexible enough to ensure relayers could be profitable under different market and gas conditions.
In a virtual meeting, during which everyone seemed just a tad too close to their cameras, it was decided that the definition of a relay needed to be clear and simple.
Finally, with CTO Matt inspired by a fantastic muffin he was snacking on, he declared that liquidity providers should not be exposed to a lot of risk.
There had to be no way to exploit bots or create invalid relays. This once again tied into transparency, with the rules for relayers and bots being clear, concise and easy to understand.
Low costs were always one of the most important factors. Another one of the team’s goals was to make sure gas was as low as possible, and that their bridging fees were very inexpensive.
Frontend-wise, the team also had to make sure that everything was visually sound. Interactions had to flow well and be complementary to the user’s experience.
Overall, everything needed to be simple, the contracts needed to be transparent and the team had to work hard to get to something that truly worked all together. They also knew this had to be done fairly quickly, with strict deadlines.
In addition to some of the more technical aspects, there were also goals that came from the community side.
The fair fair launch
The goal for Across wasn’t to turn a profit. Rather, the team wanted to create something that was unique in a competitive space, something that hadn’t been seen before and showcased just how cool the optimistic oracle is.
The idea for the fair fair launch came around when UMA Co-founder Hart Lambur and UMA Community Lead, Clayton Roche were coworking in Berlin. A conversation took place around Across’ building, and how they would allocate the needed resources to what. What was the plan for a token? How would it work? A deep dive into scalability, bandwidth and the overall direction for the bridge took place.
Then, a mini breakthrough happened.
Why don’t we make it a goal to pass this on to the community, making it community-owned?
Community members would help with things such as token distribution, truly having a say in what happens to major aspects of the protocol. The team believed that Across’ best chance of success would be to give it away to the community.
There was a bit of nervous excitement — a ‘wait, we’re really going to do this’ moment. This was a bold experiment, but it was something that the team felt was a great step forward.
Since the goal was for the bridge to be passed on to the community, a solid community needed to be built. With lofty goals, there needed to be an aggressive community that would be ready to build around this protocol.
Britt, Across’ community project manager, also needed to make sure that she was informing the community as effectively as possible, to prompt community members to think about Across on a deeper level.
On top of that, the community needed to be really excited about what they were doing.
A goal was set to have at least 1000 community members by the end of the year.
The first steps
Engineering
Once goals were set and the initial design was agreed upon, the team started getting into the nitty-gritty of building the bridge.
One of the frontend engineers, Francesco, designed a 90s-style, bare-bones website to implement all of the functionality. Once everything worked, the site went from nostalgic to techno—design implementation began.
Frontend-wise, the team was striving to create a fee breakdown that was simple to the user with both the LP and relay fees. There typically wasn’t a fee breakdown accessible to users on most bridges, so by making it accessible, they also had to make sure it made sense to those viewing it. The relayer fees and LP fees were separated in the fee breakdown and followed the same simplistic look the rest of the site had.
On the backend, since speed was one of the main drivers behind the idea of the bridge, the engineers were aware that their design had to allow for transfers to be quick. The engineers felt, with painstaking importance, that it was key to focus on how the bridging could be as cheap as possible for users.
The engineers began to focus on those design principles, as well as the rollup to mainnet use case.
Community
On the community side of things, Britt began to do the initial setup of the Across Discord.
Britt meticulously made sure bots were in place and channels were organized so the Discord structure was clear, concise and helpful. It was starting to look ready to be the community’s official oasis.
Crossing the bridge
Engineering
Extensive work on the bridge took place while the team was coworking in Lisbon. Everyone was very specialized — there were specific people responsible for things like frontend engineering, backend, community, design and so on.
On the frontend, four engineers were focused on two independent streams of work — completing the implementation of the send and the pool tab onto the site. The engineers not only had to make sure that it looked visually appealing, but also precise and functional for users.
The technical design of the bridge took a while, especially around passive liquidity providers. They didn’t want relayers to have to be on the hook for both holding and lending out large amounts of money, for weeks at a time. They felt that relayers may not be comfortable with that much capital, and therefore they pivoted. The relayers became the initial fronters for the user, while the pool took on more long-term responsibility.
Another task for the engineers was to ensure the definition of a relay for Across was built to be clear and simple. To achieve this, they made it so as much information as possible could be pulled directly from the L2 deposit event. In simpler terms: relaying that info to L1 and making it easy to verify.
True to another one of their original goals, the engineers found a way to ensure that LPs were not exposed to a lot of risk. By using the optimistic oracle, things were slowed down to allow disputes. Hooray for the OO!
Speaking of the optimistic oracle…
While the engineers were building Across, they realized that they were going to have to completely rethink working with the optimistic oracle. Typically the OO was meant to be a settlement procedure, so the cost didn’t matter as much. If there were multiple settlement requests per hour with the oracle, as there would be with a bridge, this could start becoming very expensive.
The engineers realized there was a workaround — only interact with the optimistic oracle when a relay is disputed, so in the happy path, they didn’t need to talk to the OO at all. This brought the costs down a lot for relayers, from 1.4mm units of gas to about 200K.
The ball rolling for Across meant that there was a lot of back and forth deliberation, ensuring the experience was the best it could be for all parties involved by the time they reached the finish line.
Community
On the community side of things, Britt was rallying a community from UMA’s community leg, The SuperUMAns. The SuperUMAns had been incredibly successful so far in creating a fully functioning, autonomous community for themselves. Britt felt that they would only help when it came to Across Protocol.
She created a side quest for SuperUMAns to seed the community, with the original goal of getting to 1000 members by the end of the year. Spoiler alert: it reached about 5000 by the end of 2021.
Britt’s job was also to ensure that those who joined the community knew how relays work and had a good understanding of all of the other complex mechanics of the bridge. A lot of the process was also trying to properly articulate the fair fair launch. We built this thing, and we wanted to give it away. That didn’t make a lot of sense to people.
People had some good questions that needed proper answers. Britt continued talking to the community to make sure they felt informed and confident as Across’ community. It was great to have some familiar faces around, especially as the team got closer to launch.
As the big day drew closer, the team was buckling down to finish out the last steps before the bridge was launched.
In the next part of our series we’ll talk about these final steps, the launch and future implications for Across Protocol.
