How did you first learn about Across and become a contributor on the core team?
I first heard about Across shortly before its initial launch in November 2021. I was relatively new to Ethereum and generally feared that I was a late-comer, so I desperately wanted to get exposure to new protocols in the hope of accruing some airdrops. I was spending time in various Discord servers, and someone mentioned (probably in the Alchemix Discord) that there were opportunities at Across: “Go to the Across Discord and tell Britt that you want to be in Dev Support”. I didn’t really know what Across Dev Support involved, but I have a background as a Software Engineer and wanted to get involved with protocols at a technical level, so I aped in.
It started as an unexpected side-quest in my DeFi journey, but somewhere along the way it became the main storyline.
I started contributing in Dev Support and had to learn quickly in order to support users. I liked the role and found it to be rewarding, partly because it helped me to build out new skills. It was also interesting and surreal to be providing support for a bridging protocol. Bridges were especially controversial at the time because a few had been compromised, and some loud voices in the community were at pains to highlight how risky they are. Over time I came to understand how Across had a novel approach to bridging, and the relationship with the Across Engineering Team started to develop, as we occasionally had to escalate user issues that we weren’t able to resolve ourselves.
One of our community members had asked: When you started contributing at Across, was the intention to get a job or did you just have a general interest in the protocol?
At the beginning I was just eager to be early to a new protocol, and I was lucky to be in the right place at the right time when Britt was looking for support. Once I was in I was eager for the Dev Support Team to work well, but I hadn’t anticipated the opportunity to level up into an Engineering role. Learning that there was an opportunity to contribute to Across via the Risk Labs Foundation (Across’ parent entity) was a really pleasant surprise, and once I had started the interview process and gained a better understanding of the vision for Across, I was even more excited. At that point it became clear to me that the Foundation was really committed to building Across into a very successful product.
We get a lot of people asking where to see open positions for both Across and UMA. The best place to look is the Risk Labs website. (PS. We’re hiring!)
What does your typical day look like in your role as a Smart Contract Engineer?
The work as an Engineer has been a big step up from what I was previously doing in Support, but it’s really interesting and also quite varied. I spend most of my time working on the different off-chain bots that are needed for Across to work. Our days are periodically freed up for work to be done on the contracts, and in those times there’s typically an intense focus on getting the design and implementation of new features right, so that they can be submitted for audit. This is a cyclical process that expands the design space that we have with the bots, thereby extending our runway and allowing us to implement the improvements and new features that are seen by the end user.
There is an Operations aspect to the work as well. Across relies on off-chain actors to interact with the protocol in order for the bridge to work, and Risk Labs has built comprehensive infrastructure to perform this function. The engineering team has responsibility for ensuring that everything remains operational, so the team takes turns at monitoring and responding to any incidents that arise. It helps to keep the work varied and acts as an important feedback loop for the developers on the team.
The team behind Risk Labs is spread throughout the world, so we also take time to discuss our work and align on the progress and future work to be done. This works pretty well despite the obvious barriers that exist when everyone is remote.
Risk Labs has a bit of a notoriously rigorous interview process, that is a bit of a rarity in Web3. Since you were already a trusted member of the community, was the onboarding a bit more streamlined in your case?
The team followed its normal vetting process with me, so I did go through multiple stages of interviews like everyone else. Completing the coding interview with a couple of members from the Engineering team stands out in my memory. The Engineering role that I was interviewing for was obviously quite different to what I’d been doing in Support, and I’d never been required to do coding exercises in previous roles, so I was a little nervous heading into that.
I did have one advantage throughout the process, and that was the technical product knowledge about Across that I’d gained from my time spent contributing in the Discord. This reassured me that I at least had some of the basic requirements in place, and it made me more confident that it would be a role that I’d enjoy.
My experience throughout the end-to-end process was really positive, and my impression is that Risk Labs is invested in making the resourcing and onboarding processes work well. Risk Labs is very self-aware and is learning, adapting and reinventing itself along the way. I’ve been in similarly sized organizations before where this was mostly an afterthought, so it’s definitely refreshing.
This next question is from fellow team member, Clayton, who asks: When you started contributing, you were this anonymous figure, but within the team you had to transition to using your real name. How is it like juggling 2 personas in Across and do you think that anyone on the team still doesn’t know that dxΞ (Dixie) and Paul are the same person?
I still use the same Discord pseudonym from when I first wandered in from the wilderness a couple of years ago, but hopefully there’s only one underlying persona and not two! It was natural to drop the pseudonym within the team though; it enabled Risk Labs to do its necessary due diligence and vetting, and the Across team has a tight working relationship, so hopefully there’s no confusion.
As a side note, anonymity and pseudonymity are interesting topics and I appreciate that there are contradictions that this ecosystem somehow manages to take in its stride. It’s amazing to see the evolution in ways of trustlessly disintermediating anonymous actors, and I think this additional set of constraints helps the ecosystem to develop better solutions.
Which one is Paul, and which one is dxΞ?
You seem to be everywhere all the time, how do you manage to stay on top of it all? This question is from Britt by the way!
I don’t! I’ll readily confess that I rarely feel like I’m on top of everything. I do wonder if this is just par for the course of being a software developer — software is rarely ever “done” in the eyes of a developer, and the DeFi overlay adds its own set of unique constraints and opportunities. There’s always something to be fixed, improved or built out, and Risk Labs has a strong, creative team that regularly produces new concepts and identifies opportunities for the engineers to chew on. The fact that the work is interesting makes it easy to invest a lot of time, though, and it’s self-reinforcing when the results start to show.
The team really seems to rely on you for continuing to support the Discord help tickets and are really grateful for you maintaining your presence in that role.
It’s nice to hear. I have a lot to focus on over on the engineering side these days, but I try to remain active in the community and to keep an eye on the support tickets to make sure everything is working OK. Providing good support to users can actually generate value for Across, so there’s definitely also value in maintaining a presence. There are still occasions where a user presents with an obscure issue that hasn’t yet triggered any of our automated alerts, so detecting and reacting to these scenarios quickly is just another way that we can ensure that Across can keep its users happy and live up to its reputation and objectives.
If you ever need fast help on anything Across related, please create a support ticket in our Discord.
On a personal level, interacting with users is also something that I enjoy. It might seem counter-intuitive, but the vast majority of user interactions are very pleasant, despite the fact that most users only get in touch when they are experiencing a problem. The range of users is also pretty broad. We hear from both users and third-party integrators who want to build on top of Across. Sometimes it’s a user who is completely new and is bridging for the first time, and other times it’s a famous (or infamous?) DeFi veteran bridging serious volume. Being on the opposite side of that is rewarding and it’s always interesting to tap into their feedback on Across.
Wow, so the whales are nice too? 🐳
The whales are very nice. In my experience it’s uncommon for these users to be in a bad mood. Delays in bridging do occasionally occur, and the design of Across includes fallback mechanisms to ensure that even very large transfers are safely completed within a reasonable timeframe. Whales moving millions in volume tend to be very understanding of this, and even appreciative of the fact that we respond as quickly as we can and can provide an estimate for the arrival of their funds.
Thank you to our whale frens for being cool 😎
When you had brainstormed with the team on features, was there ever a time where there was one that you really pushed for that didn’t end up being implemented?
Not really, because in software it’s unusual to say, “We’re going to do something and it’s permanent.” Software is endlessly malleable for the most part (immutable smart contracts excepted, of course). So for me, it’s moreso a question of the things that I’d love to work on, but which fall lower in the list of priorities than other, more pressing tasks. Every developer probably has some lower priority pet project that they’d love to focus on, but finding the time to work on it can be a challenge.
At the moment we’re very busy building out the Universal Bridge Adapter which is super critical work that will extend the runway of Across and enable users to reach new destinations.
If I had a period where I had spare capacity, I would probably focus more on building out the relayer bot with features that make it more flexible and more adaptable to the needs of various third parties. Across has a budding relayer community that produces a stream of interesting ideas, and I think there are some opportunities in that direction. Someone from the community might beat me to it, though…
Have you come across any tickets that were either shocking or a big head scratcher?
I don’t recall anything shocking, but I’ve serviced some semi-famous crypto people in tickets at various times. One standout was the CTO of a top-tier auditing firm in the space. In this role you can’t help but realize that Ethereum can have a very flat hierarchy, so the distance between a newbie and an OG can be surprisingly small.
We haven’t seen Vitalik in a ticket, but if he does turn up one day it could be interesting to catch that one.
In your mind, what do you think is the next big problem that we’ll need to solve for Across?
The long-standing “big problem” has been that Across is dependent on canonical bridges to service its chains, so its reach has been somewhat constrained. The Universal Bridge Adapter (UBA) model addresses this, and it represents a big step forward in the development of Across. This is what the team is hard at work on at the moment, and I’m sure everyone is looking forward to its rollout.
Beyond the UBA, one thing that sticks out to me is to understand how the relayer network can be further decentralized without degrading the experience for the individual relayer. There is a coordination challenge in the relay network, because at the moment the relayers are all simultaneously monitoring for eligible deposits and are implicitly racing against each other to complete the transfer. When that happens, one will win, and the others who were not successful will lose the gas on their failed transaction.
The more competition there is, the worse the experience can be for the individual relayer.
If we can address that so that the system can fairly select a relayer for each fill, or alternatively neutralise the cost of having a “failed” fill, then a significant barrier to entry for third third-parties will have been removed. This would then allow more relayers to operate, supplying Across with more “elastic capital” when it needs it, thereby giving a better experience for users. This sticks out to me as an interesting challenge to solve, in part because we have a small but vibrant community of relayers who are similarly passionate about solving this.
Do you know who the mysterious relayer is who has been really impressing the team with their speed and how they are clocking those speeds?
I don’t know who it is, but this particular relayer has been hotly discussed in the community recently. I was really surprised to hear how much effort some of our other community operators have put into understanding the behavior of this particular bot, and they made some really interesting observations.
One of the key takeaways for this particular relayer is that they’re employing some mempool inspection techniques to modify their behavior based on what the other relayers are doing. This is a natural evolution of the recognition that each relay bot is implicitly competing against the others in order to successfully complete a bridge transfer. That some of the operators of these bots are now engaging in PvP behaviour is obviously a negative externality on the system, and we’d like to minimise or even eliminate that if possible. I have to admit though, I am also excited to see this dynamic response from the relayer community, because it indicates that we’re building something that’s worthwhile for others to get involved in.
The mystery continues on who is running one of our fastest relayers yet!
We love a good mystery, so I guess we’ll have to wait and see if they reveal themselves! To finish up this interview, could you tell us what your hobbies are outside of Across?
I have a house and a young family, so there’s always plenty to do when I’m not at the computer!
I’m a bit of a nerd and I’ve always liked messing with computers. My home network is a bit more advanced than most and I like building out my infrastructure.
If I had more time then I’d probably try to spend it on my bike, exploring the trails in my local area.
Actual last question, what’s your favourite bridge?
I don’t necessarily have a favourite bridge in the physical world, but I’m an engineer, so I really appreciate seeing constructions that defy what people think should be achievable.
Across Protocol is an intents-based interoperability protocol, capable of filling and settling cross-chain intents. It is made up of the Across Bridge, a powerfully efficient cross-chain transfer tool for end users, Across+, a chain abstraction tool that utilizes cross-chain bridge hooks to fulfill user intents and Across Settlement, a settlement layer for all cross-chain intent order flow. As the multichain economy continues to evolve, intents-based settlement is the key to solving interoperability and Across is at the core of its execution.
