How did you first learn about Across? It seems like a bit of a strange question, since you were with UMA before Across was born, but it’s interesting to hear the back story.
I was an early Engineer at UMA, hired to be a Smart Contract Engineer working on the original DVM (Data Verification Mechanism). We had this thesis at the time that to get people to use UMA’s oracle we would have to first build apps that were secured by it, to present as use cases. So we were building a lot of financial contracts, since a lot of us on the team, including myself have financial backgrounds. So, we were trying to build something to showcase the power of UMA and I think Across just happened to be one of the many, many iterations, years after I was first hired. Across has since become the most successful way to demonstrate the ingenuity of the UMA optimistic oracle, to the point where Across has its own brand, its own team, and feels more separate compared to previous projects we’ve built.
What’s funny is that a lot of people don’t even know that UMA secures Across, that’s how separate I guess it’s become.
So how I ended up at Across was that, as the project’s demands grew, we realized it had to have its own dedicated team. Being that I was one of the Engineers that helped to build Across, I naturally was one of the developers at UMA that came over to the Across side and became the Lead Dev.
Did you know that Across was secured by UMA’s optimistic oracle? It’s one of the many reasons why Across is one of the safest cross-chain bridges available and greatly improves transfer speeds.
Since you left the UMA team to focus on Across, is there anything you miss about working on the oracle and if so, what do you miss about it?
Having not focused on the oracle for some time helps me appreciate it a lot, because, at Across, we’re building something that, from a security standpoint, totally relies on UMA’s tokenomics being sound. So it makes me appreciate that UMA is an optimistic oracle and not just a price feed Oracle, like Chain Link, since we’re able to verify bundles of information and secure protocols in a more interesting way than you ever could be able to by just building a price feed. Witnessing the power of UMA from the outside has been really interesting.
One thing that I do miss about working with UMA is trying to solve the oracle problem, by building a sort of Schelling point oracle and really thinking about game theory to come up with solution. Then again, I’m also very fascinated by the challenge of trying to build the optimal bridge, since the bridging space has a problem that needs solving of its own.
So, going a bit more back in time, how did you get connected with the UMA team?
I got my start in the crypto space in 2018 when Bitcoin was going up to like 10K. Back then, I was a corporate bond trader at Barclays. I was in the finance space already, with a background in computer science, and I had wanted to work on something leading edge, which made me curious to learn more about Bitcoin. That led me down the road to Ethereum, but I wasn’t a maxi by any means. I dabbled with EOS, I dabbled with Tron a bit, I wasn’t too fussed about which chain to interact with. Ethereum, however, was my starting point and I fell in love with the idea of working on this virtual computer and thought that Finance was a really cool application of it (Ethereum). So, wherever it was, and whatever chain it was connected to, I knew that I wanted to get a seat at the crypto table.
I wanted to land somewhere in Programming, but even though I had a Programming background, I wasn’t actually a good Programmer. So, I took a position at a crypto company, where I could more or less learn on the job. At this time the only stablecoin available was Tether, and since the sentiment around USDT was a bit negative, people really wanted a decentralized alternative. Like many others back then, my first crypto company was trying to build algorithmic stablecoins, but, unfortunately, we got absolutely destroyed with the launch of USDC, since they had a big bank backing them. We did try to pivot to a fiat on-ramp service, but due to a combination of lack of product-market fit and poor management, the company eventually ran out of money.
The headline of 2018 Nick’s nightmares.
I was looking for another opportunity in the space and I read through UMA’s whitepaper and I thought it was a pretty cool concept with a challenging problem to tackle within the oracle space. I was looking for a project with a leader that had strong integrity and that would do right by his or her team and after meeting Hart, I felt that this team was what I was looking for. After meeting with UMA’s group of Engineers, Matt (Risk Labs’ CTO — Risk Labs is the parent foundation of Across) and Chris (UMA Engineer), my faith was immediately reinforced and I liked that we had the freedom to build really valuable tech in a methodical way, which is well thought out, focuses on security and can stand the test of time.
I think many people who are familiar with UMA and familiar with Across, might not know that Risk Labs has a third product called Outcome Finance. With your background in Finance, what are your thoughts around Outcome and would you like to see the team place more focus on that again?
Outcome products, like KPI options, are what DAOs need but don’t realize that they need, and currently they might be irrationally scared of them because all of the smart contract hacks and bear market crises are too close to memory.
I’m still very much a believer in KPI options and I imagine these will become very popular in a few years when on-chain governance becomes more normalized.
Several major DAOs like BarnBridge and BadgerDAO have taken advantage of the KPI option tools provided by Outcome Finance.
What is your job title at Across and what does your daily work life look like?
I am the Engineering Lead at Across and I lead a team of five Engineers. I start my day with a 15 minute sync with the team to talk about our product roadmap and where we’re at in terms of its progress. We usually split our work up into two week sprints, which have high-level, defined goals.
The goals of the current sprint are to finish the UBA fee model implementation and finish up the ETL project. The UBA code is a rethinking of how we do fees across our different spoke pools and the ETL project is an internal data science pipeline so that we can easily get data about all the different bridges, to discover points where we can improve.
Moreso than when I was an individual contributor, since I’ve transitioned to a managerial role, more of my days are dedicated to meetings. Whether that be one-on-ones with the Engineers on our team or more of a traditional whiteboard meeting, it does take up more of my time in this type of role, along with code review. Whereas in the past I would have been working on many more coding-related tasks, I’m working deeply on one or two larger coding projects and I’m spending a lot of time reviewing code, trying to make sure that no individual Engineers are blocked by reviews.
Since every Engineer has their own coding style, and “good” code could be partisan, what is good code to you and when you are reviewing code, what would stand out to you as something you’d need to edit?
That’s a great question. When you hire an Engineer you assume that they’re going to bring their individual style with them, which is natural and near impossible to change.
It’s kind of like reviewing a manuscript or essay, you wouldn’t be grading someone on their style of writing, but you’d be looking out for spelling mistakes, right?
Usually Engineers aren’t making mistakes that would include coded bugs, so you’re more so checking the code at a high level and seeing if the way it is written is the correct way to solve the problem. Whether it’s adding a new feature or debugging something that exists in the code, there are many ways to solve any problem with code. So regardless of an individual style, you’re checking if they are approaching the solution in the correct way.
I’ll give one more example that I think a lot of people who are non-technical could understand. Let’s say that we noticed that a ship wasn’t turning correctly and we had to “debug” the gears of the ship. So the Engineers would tweak the gears in one way or another and my job is to review their work. To see if their work has resulted in a correct fix, it should pass a test. In this case, the test should be that if you turn the ship’s steering wheel, the whole ship should turn, right?
Oh, that’s a great example and, yes, makes total sense from a non-technical point of view! As you mentioned, each Engineer has their own style, so how would you describe yours?
I try to write very succinct code with very explanatory variables. I am of the opinion that well written code doesn’t actually need code comments to explain what they do: because the logic is explained so clearly and efficiently that the code explains itself. This also requires variables to be named intuitively.
That being said, a lot of my code doesn’t look like this ideal form, but if you track it over the years on GitHub you can see a clear evolution and I owe a lot to my teammates for the progression over the years.
Regarding specifics:
I think that test-driven development is a great way to write code. That means that you explain the properties that you want to test and then write code and check periodically if that code passes the tests
Each code function should solve one problem. This makes testing simple and also future maintenance easier on that code
Don’t forget to follow Nick on Twitter where you can also access his Github!
The next question is from our Product Manager at Across, Ryan, who asked: How do you use your Finance in your work at Across?
I think my finance background just has taught me to think about risk. There are a lot of emotions about taking on risk. Taking “real” money and buying crypto, for example, can feel like a loss somehow and there’s a lot of emotion behind it.
A finance background helps value risk correctly and helps to keep some of those emotions in line.
In my day-to-day work with Across, it can help me correctly value my time as well. As an Engineer, we basically have infinite things that we can work on at Across. There are so many tokens we can add, or so many chains, but each of those have costs in terms of time units and of personnel. We have five engineers on the team and each has maybe four hours a day of programming. Those are time units where you want their focus to best allocated to result in an upside. With that mentality we decided that the UBA, for instance, was the most attractive return for the time unit and I think that’s a result of a financial way of thinking.
To answer the burning question on the community’s mind, how would you explain to someone the importance of the UBA over deploying on zkSync Era, for example? What would you say in terms of opportunity cost compared to focusing on adding more tokens or chains?
The main value of the UBA is that it allows us to get to chains that do not have canonical bridges, meaning that we can deploy to chains like Avalanche and BSC, which have a lot of volume and which the community care about. There will be many more chains that grow in importance, but lack canonical bridges in the future, so without the UBA we cannot get to them, full stop.
Now, we could have added zkSync before finishing up the UBA, however, the UBA is a system-wide change, which means that any routes that we currently are deployed to will need to connect to it eventually. Prioritizing new chain deployments would have meant more work retroactively connecting them to the UBA, which does not make sense.
The UBA also allows our network effects to lower our fees longer term. I would argue that Across has network effects in that it brings in more volume and more LPS, which lowers fees, but the addition of the UBA will have an even stronger effect. Once the UBA helps us connect to more chains, we will inevitably see more volume, its optimization will allow us to shoulder more volume, and our bridge fees will be even lower.
A little alpha drop.. Despite the priority on the UBA, don’t fret, because it will be a BIG ZK SUMMER over at Across 🍹
I want to reiterate that the number one goal is to get to as many chains as possible and increase the number of supported tokens, but in order to support all the extra volume, we’re gonna want the bridging optimization from the UBA.
As mentioned, this tool has so many compounding benefits, that although it may seem that we want to get in as early as possible on new chains, looking back we’ll be glad that we got in as early as possible to take advantage of the compounding returns.
You had also previously mentioned that one of the draws of working with Across is trying to solve the bridging problem? How would you describe what the bridging problem is?
My thesis is that all bridges will compete on fees in the long term and there will be a world where there is going to be many different roll-ups, many different app chains and users are going to demand to interact with these without having to switch their RPCs. They’re not going to want to know which bridge they’re on or which chain they’re on, they’re just going to want to use all these different apps. Which means that all bridging is going to be done behind the scenes, and most likely that will all be taken care of by aggregators.
For the most part the aggregators are going to pick routes based on speed and fees, so bridges ultimately have to be super cutthroat and compete on fees which will eventually go to near zero but not quite zero. The fees will just be enough to eke by and be somewhat profitable. The bridging space is going to be a winner-takes-most space and the reason is because a lot of bridges today, including Across, can lower their fees as their scale gets bigger. So, like in any industry where network effects are the dominating factor, there are going to be very few winners.
Check out Nick’s thesis on the future of bridging here!
I like to think that we will live in a world where we will have chains that are dedicated to certain use cases. For example, a chain that is optimized for gaming or gambling. We could also continue in the direction that we’re going in now, where we have many different chains that have 1 or 2 major dapps that draw in users. In either scenario the future is heavily influenced by cross-chain bridges.
With the growth of roll-up infrastructure and dapps on each RPC that draw in users, I’m very bullish on bridges.
In that world where bridges play such an important role, do you see bridge fees going to zero like a Blur vs. OpenSea situation?
I don’t see how that’s possible. I don’t think service providers can provide anything for zero fees. They have to demand some payment for their services provided and I think those can get to near zero, but at zero all the bridges would disappear.
What are your hobbies outside of Across?
I play a lot of sports like soccer, tennis, and I do jujitsu 4 times per week. it helps me say disciplined and I also think that by starting off your mornings with jujitsu is a really good way to start the day, because nothing is really harder after that. Why it’s so challenging is due to this technique we do called grappling. It’s submission grappling where you’re trying to get people into positions where you have to submit to them. The act of trying to defend myself in physically challenging positions is an intense but energizing way to get the day started.
Other than that, I’m watching a lot of anime right now. I’m watching the new season of Demon Slayer now, but my recent favorite has been Jujutsu Kaisen. My all time favorite is Death Note, though. Lastly, I can’t say no to reading some good Sci-Fi.
What’s your favorite bridge? I just realized that you’re in a great spot for bridges, being that you live in New York City.
Yeah, I like the Williamsburg Bridge in New York. I walk over that when it’s nice in the Summer. I think it’s a great bridge for both people watching and to get to and from Manhattan and Brooklyn. It’s my favourite and my home bridge.
The Williamsburg Bridge in New York City 🍎
As a New Yorker, I have to ask: What’s the best pizza in New York?
Prince Street Pizza. It has a very thick crust and just a very good dough overall. It’s one of the top three pizza places you’ll see that come up as must visit spots in New York. The other two are okay, but Prince Street has them beat in my opinion.
Hmmm Prince Street Pizza does look pretty incredible.. Nick might be right about New York’s best pizza spot.
Thank you for reading! Stay tuned for more team interviews bi-weekly.
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.
