Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. At the end of each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. Today, I'm joined by Jonah Ehrlich and Itai Spidler, co-founders of DEN. Building on their experience coordinating multi-sig transaction signing in ConstitutionDAO, Jonah and Itai are creating a suite of tools for operational multi-sig teams to create, track, and execute Gnosis safe transactions. At the time of recording, DEN comprises a web app interface for building and annotating multi-sig transactions. DEN also maintains Discord, Telegram, and SMS bots that can notify teams of pending transactions at regular intervals. In this episode, we talk about the past, present, and future of on-chain coordination. I hope you enjoy the show. Jonah, Itai, welcome.

Jonah Erlich: Glad to be here. Thanks for having us.

Nicholas: Yeah, absolutely. I'm excited to talk about DEN. I guess we might as well start with the question I always ask, which is, what were you doing before crypto?

Jonah Erlich: Yeah, it's a great question. Actually, funny enough, both Itai and I have been in and out of crypto for years and for years together. During the 2017 cycle, which is around the time we met, we used to hang out in the basement of this coffee shop with four others and just spend all day talking about crypto. At the time, I was doing some stuff with Blockstaff, some decentralized storage with SIA Network. And then immediately before DEN, I was working at this startup called Bubble, which is a no-code startup. And I was working on the infrastructure of things, but spending a lot of time working in DApps, hackathons, side projects in the space leading up to DEN.

Nicholas: Awesome. I've played with Bubble, but what were you working on before in the earliest period? What year did you say you got started?

Jonah Erlich: So I personally first read the Bitcoin white paper in 2012, but it was really a lot of fiddling with things like Blockstaff. I think Itai's story actually in 2017 might be a little more interesting.

Ittai Svidler: Yeah, well, I guess where it all started was in the summer of 2017, actually, maybe summer of 2016, I was interning at a VC early stage. And at the time, you know, everything was so new, we actually didn't know what we were looking at. But something called Ethereum crossed our desk. Being the analyst that was a CS major in college at the time, I was asked to look into it. And when I looked into it, I quickly realized this was not a startup. It's not a classic thing that a VC would look at. It was something a lot broader. I saw this new thing that was basically the way I think of it is this distributed cloud computer. And that really got the ball rolling. So that next summer, still in college, going back to my computer science classes, I partnered up with one other student that was a good friend at the time. And we started doing what we called blockchain consulting, which was really this fancy terminology for freelance smart contract development. At the time, it was really simple smart contracts people were building, we were fully capable of it. And that's how we dove in. And that also included running our own validator becoming an Ethereum miner. Because at the time, you know, you didn't have all these services that would host your note for you that easily. So you had to do it yourself. But that's really how we kind of got in. After that, did a short stint at Deloitte, not in tax and audit or classic management consulting, but really on the tech side, because I had a phenomenal blockchain program, and got to see the inner workings of some of those blockchain initiatives and some of those projects firsthand.

Nicholas: Very cool. And then I know you were involved in Constitution DAO later on, right?

Jonah Erlich: Exactly. So Constitution DAO was really the inspiration or the straw that broke the camel's back for Dan. So he and I had both personally been on a few multi six, and had felt a lot of the pains of being on multi six, it's really hard to coordinate with the other signers. So folks actually know there's a transaction to sign what's happening in that transaction, why there's a transaction, things like understanding the input data to the contract calls. And we faced this in a number of organizations. But really, when we were doing Constitution DAO, and we were moving so quickly and sprinting to raise the money to bid at Sotheby's, this was one of the primary points of friction, which was, can we move fast enough with our multi sig to raise funds to get everything to Sotheby's in time for the auction?

Nicholas: Because I guess the major friction here is that sometimes so for people who don't have context for a multi sig, you need multiple people to sign the transaction before it can be put onto the blockchain. So sometimes you're stuck waiting for some of the requisite signatures before the transaction can take place, which slows down whatever it is you're doing and whatever kind of not necessarily a DAO, but multi party project on the blockchain. So Dan came out of this need to have some kind of off chain communication about what needed signing next. Is that right?

Ittai Svidler: Yeah, really, what was happening internally with Constitution DAO, because I think it illustrates it pretty well, is what most people don't know was on the inside, there was the stressful 48 hour time period where we had to just get a single transaction executed, we had a nine of 13 multi sig. And it's like 48 hours and two of us running around trying to get ahold of anyone, any way we can Instagram DMS, whoever the signers were to get them to actually execute the transaction. And once we could even get ahold of them, there was this other problem. So getting ahold of them was this whole huge nightmare of coordination, it was tough. But there was this other problem where once we actually did get ahold of everyone, and they had assigned a transaction, there was this reluctance and it was completely understandable because the data wasn't understandable. You didn't know what transaction you were signing, where you're going to sign away all of the funds that we had just raised, make a mistake, send it to the wrong address, whatever could go wrong was really a fear. It was really those two twin problems that we faced immediately.

Nicholas: Because really everyone on the multi sig is supposed to diligence the transaction before they go ahead and sign it. It's not just a formality, they're really taking responsibility for confirming that they agree that the transaction makes sense. So I can understand that reluctance. And it is true that if anyone hasn't played with Gnosis safe, it is quite difficult to understand what the transaction is that you're signing in the interface that they provide and in all the tooling surrounding Gnosis aside from DEN. So there really was a need.

Jonah Erlich: Definitely. And I think what really made this need clear was the amount of multi sig signers that we spoke to. that had a very clear set of problems. That was really how we drove a lot of the early development with DEN and really how we drive all of our development today. We find that in web three, there's really two kinds of ways of building products. There's the way of building products of, hey, we're going to try something super experimental, see what hits, see what doesn't hit and see what we learn. And the other mechanism, which is what we do at DEN is, hey, we're going to focus really concretely on what pains are people experiencing right now and build tools to make it super easy for them to move faster.

Nicholas: So for people who haven't used the product yet, maybe you can describe a little bit what the experience is. I guess the first thing you need to do is create a Gnosis safe, most likely on Gnosis's either app or web app. And then once you have that, how do you get to start using DEN?

Ittai Svidler: Yeah, I guess for context, really, we see our goal is helping teams that are doing things on chain move 10 times faster without compromising on security. And so the way we do it now and the customer experience is today is we started off by asking what are the biggest problems these multisigs have with moving fast and being secure. The first one was that coordination problem we mentioned. And so we tackled that with the first iteration of our product being the simple notification service for Gnosis safes. So those that already were using Gnosis safe as their team multisig to manage funds, they could use DEN by signing in with the wallet that was also an owner on that safe or those safes. And the DEN bot would follow up in their Discord, Telegram or SMS wherever their teams live, and send automatic follow-ups, reminders, tagging people that need to sign and decoding a little bit of data in those notifications trying to tackle that coordination problem in the lightest way possible as directly as possible. The second iteration where we are today is helping teams sign really quickly by helping them really understand the data. Once people signed up for the DEN notification bot, now the links that they get in those notifications direct you to the DEN signing page where you can sign right then and there that transaction. So there's very little steps in the middle. And one of the important things we do is we help teams really understand what that transaction does. We do that in three different ways. The first one is letting someone that's also a verified owner on the safe, we verify that they actually are an owner on the safe, add what we call a context message, which lets them describe exactly what this transaction is for in human-readable language, maybe attach a link to something that's relevant. The second way that we do it is by actually decoding the transaction data, the inputs. This is especially useful for complex smart contract interactions. We decode the data, we parse the variable names that look so technical and make them human-readable with proper spaces and capitalization. We parse addresses so it's easy to copy and paste and view an ether scan. Numbers especially are a major pain point. A lot of people are probably familiar with having to copy and paste a number, then do divided by 10 to the 18th power or 10 to the 6th power, which is a major pain and making all those things really convenient and really human-readable. And then the third way is via transaction simulation. So you can simulate your transaction, see how much gas was used and see if it'll be successful or if it reverts and if there's a revert string. So that's the current customer experience. It's that notification service, then that sign-in page that makes it really easy to sign really quickly and makes it clear to you what you understand.

Nicholas: And who's using it right now? I know from my experience in Juicebox, that Juicebox dial makes use of DEN. Are there any other teams you can tell us about that are making use of the software?

Jonah Erlich: Yes, there's a lot of really great teams using the software right now. We haven't gotten permission from folks expressly to name names, but I can say it's a lot of teams just like Juicebox. And we actually love Juicebox because we think Juicebox is the perfect example of the type of organization we're targeting, where really the types of teams that we like to work with are what we call operational DAOs or operational on-chain organizations. What we mean by operational is teams that are doing transactions more complicated than simple token transfers. We really see this as where the on-chain world is trending. There's kind of two things happening right now. One is that the nature of on-chain transactions are becoming more complex. And two is the average on-chain actor is becoming less technically sophisticated. So we're really focused on as this gap widens, how do we make it easier and easier for teams to understand some of these complex transactions? And we put those teams into one word by calling them operational.

Nicholas: Yeah, I think that's something we also see at Juicebox where there's a temptation to talk about things exclusively in terms of DAOs. But actually, there's lots of other kinds of social coordination, where multiple people are managing some kind of project, but it's not expressly large scale DAO or what we might think of as a DAO. And definitely we do come across a lot of or have to execute a lot of transactions that are more complex. So if I'm, let's say, one of the 14 signers on the Juicebox multi-sig, I guess the flow for people who haven't used the software themselves will be getting a telegram message or a discord or an SMS that notifies them of what exactly?

Ittai Svidler: Yeah, so it notifies them when there's a new transaction. So someone queued up a transaction and their notes are safe, and notifies them when they need to be reminded to actually sign it. And of course, that's customizable. It notifies them when a transaction has been rejected by the safe. And it notifies them when a transaction has been executed. And in those notifications, it also will send that context message that I mentioned before, if one was added, it'll indicate what that transaction is actually for. If it's a smart contract interaction, it'll mention which contract it's interacting with and what function and some basic details like that. Or if it's a native token send, it'll give those pieces of information to.

Nicholas: one thing that I saw when playing with the app is these kind of periodic reminders. So if there are transactions that remain unsigned, I can be reminded every eight hours or 24 hours or something like that. So none of these multi-sig transactions go undealt with and the project continue to move forward. I'm curious, do you think that have gnosis safe as the definitive future solution for multi-sigs on EVM chains? Or do you think there's opportunity for other kinds of multi-sig technology at the contract level to emerge?

Jonah Erlich: This is a really great question. I think in terms of the multi-sig itself, we're in this place where we're figuring out a little bit more broadly, what it means to have a programmable wallet. If you look at some of the things Vitalik has talked about over the years, for example, account abstraction, what a lot of folks don't realize is the multi-sig is just one form of account abstraction of a smart contract wallet paradigm. And we think that the gnosis team, along with the gnosis safe guild is working on some really interesting things to make this a great piece of public infrastructure for the long run. We work pretty closely with the safe team, we're actually guardians for the safe DAO. So we feel pretty strongly that it's a core piece of infrastructure that's here to stay. And one thing a lot of folks don't realize about this infrastructure is it is primarily used today for the multi-sig paradigm, but it is fully extensible with the module system for arbitrary logic. That's a little bit of what's in our future personally at then, but also for the broader safe ecosystem of what it means to have a smart contract wallet, where right now we're really using a ton, the subset, the multi-sig subset, but that's going to expand very broadly, very quickly.

Nicholas: What does that mean? I know yesterday, I think it was Etai and I were looking, interacting with somebody who was saying that trying to onboard musicians to catalog, they were having trouble because often the musician doesn't really want to deal with crypto at all. And that's okay, because they wouldn't deal with any kind of merchandising or other aspect of the business, except for the music. They usually hand that off to an agent who could be like a responsible person to handle the technical administrative details of their professional life. But this is really difficult to do in crypto right now, where you can't easily give someone access to your EOA without just giving them your private key. And if you have a multi-sig, I guess you can do it in some ways, but even being involved at all in the multi-sig is a little bit complex. Certainly not something that's got like a clean front end yet. So I know that the Gnosis safe extension paradigm was maybe an interesting future path here. Could you describe a little bit how that might be used to create a simpler front end for such a use case?

Jonah Erlich: Yeah, let me give a simple example that I think a lot of folks here would relate to. We have one customer, they're a large DeFi protocol, and they are regularly claiming farming rewards. And they have 18 farming rewards that they're claiming twice a month. And because it's on the multi-sig, the executives of this team have to spend the time to verify this transaction is correct, that it is what they are saying it's doing, and actually execute those signatures. And not only is it a hassle for this executive, but also for the people that are managing the multi-sig, it's a hassle to try and use their social capital to get these people to constantly sign these transactions that are both low risk and low impact, but need to be done. So a super simple example is you could set up some sort of role-based access control, where the treasury manager, without the permission of any of the other signers, is able to execute a transaction, where the only permission they have is to call the specific claim function on the specific contracts that they're interacting with. That's a super simple example where, because you can verify, hey, this claim function is safe to call, because it has no outflows, it has no approvals on things that we wouldn't want, then you can just give that individual key the permission to call it whenever it wants.

Nicholas: So the multi-sig would essentially approve the use of this one function on this one contract forever after, or for a period of time for any member of the multi-sig? Could it even be somebody who I guess is not even on the multi-sig could have that permission, or it could be made accessible to anybody at all on Ethereum?

Ittai Svidler: I think the goal really with this role-based access control is similar to AWS's IAM policy, or maybe Discord roles, more people are familiar with. It can be arbitrary. You can really define your own logic using graphic user interface so that someone non-technical can just set the rules. And the real goal is for it to be arbitrary, so you could define it in any of the ways that you just described.

Nicholas: Can you imagine like games or something even more fun than just this simple permission system we're imagining, but even, I don't know, novel interactive experiences on top of the safe?

Jonah Erlich: You know, anything's possible. I think one thing that we like to think about with these sorts of paradigms is we want to give folks tools that give them the broadest ability to choose to do whatever they want in a safe way. And I think as people that are building infrastructure, we can't predict how people are going to use that infrastructure. I could definitely see a ton of games having really interesting mechanics here. I think someone was just tweeting about the idea of essentially a Gnosis-safe squid game, where you put a bunch of people on signers as a multi-sig, and it's essentially a battle for whoever can drain it to whatever wallet they want first.

Nicholas: That sounds great.

Jonah Erlich: Yeah, it sounded super fun. I saw that Lucas from the safe team retweeted that. And it sounds like an interesting experiment. So I could definitely see a ton of different use cases, and games being a great one, specifically.

Nicholas: Can you tell me what does it mean to be a safe guardian?

Jonah Erlich: Yeah, that's a great question. So for folks that are unfamiliar, Gnosis-safe has been rebranded to the safe protocol. And safe is spinning out of the Gnosis organization. And they're launching a DAO specifically for stewarding the safe as a public good. The safe guardians were selected based on folks who have contributed to the safe ecosystem to help steward this organization. The safe guardians get a percentage of the airdrop of the safe token. that's going out. And for us particularly, what it means is we plan on being active participants in safe ecosystem to help contribute to being a stronger ecosystem and a stronger public good. That should be coming shortly. And we're super excited to get involved.

Nicholas: And could you maybe talk a little bit about because I feel a lot of people have interacted with what was Gnosis-safe, safe protocol in the future. But it's a little bit difficult to understand what all Gnosis does, because there's a lot of different projects. And I know there's this Zodiac brand. Could you describe a little bit about what the layout of the Gnosis scape is as it relates to safe in particular?

Jonah Erlich: Yeah, as it relates to safe in particular, the scope is a little smaller. Fortunately, Gnosis as an organization does a lot of different things. The history is really interesting. That's a much longer and kind of separate conversation. But for the safe specifically, you have this safe DAO that's coming into being, you have the team from Gnosis that's spinning out and starting the safe foundation, and they're going to be dedicating to help stewarding the DAO. And then you also have Zodiac slash Gnosis Guild. The Gnosis Guild is kind of dedicated to a few different things, but it's kind of around permitting the ecosystem around the safe. Specifically, there's a few things that the Guild really does well. One of the things is a lot of content and discussion around what it means to be a DAO, very philosophical, as well as kind of handbooks and guides for folks that are starting new DAOs. They recently launched a project called Zodiac.wiki that I highly recommend folks check out. The other aspect is, they were the first team to start building some of these modules that we spoke about. These modules are open source, publicly accessible, would encourage folks to check them out. They're also available in the safe app store within the safe web app. Really, it was actually spun out of Gnosis as well, before the safe DAO and the safe foundation were spun out with the goal of starting to develop this ecosystem around modules. They've done a really great job of kind of setting the initial examples, both with the actual implementation, but also starting to create some EIPs and other public goods around account abstraction.

Nicholas: Is the idea that there will be some fee model for Gnosis Safe, where it's more like fee switch hyper structure or not even a fee switch, just the token sort of manage the protocol and there's no particular financial motive?

Jonah Erlich: It's really unclear at this point. There is no fee switch structure currently in the safe contracts that can be turned on where people cannot avoid it. The safes are proxy contracts that could be upgraded to have a fee, but they cannot force you to upgrade. So it's going to be a really interesting structure to see, all right, what is the revenue model for the safe DAO, if there is one at all, or if it's a public good that they kind of will lobby for support from organizations like the Ethereum Foundation, from the Optimism DAO, from other ecosystems that benefit from having safe. Basically, it's this wide open, interesting question. I think it's going to be one of the first questions that we're going to have to answer as participants in the safe DAO.

Nicholas: How many guardians are there?

Jonah Erlich: I don't know the exact number. But there's a tweet from the safe team that lays out all the guardians. I think it was somewhere like five to eight pages of teams and users being tagged. It's a really large community. And I think what's really exciting and empowering is how many folks have contributed to the safe ecosystem over time, and how many folks are excited to keep contributing.

Nicholas: Yeah, it's super cool. I mean, it's one of the most relied upon and trusted pieces of infrastructure that really crosses all boundaries between NFTs, DeFi, DAOs, protocol development. Everybody uses Gnosis Safe. as far as I know.

Jonah Erlich: To give a sense of the scale, they're actually 5% of all cryptocurrencies are stored in Gnosis Safe.

Nicholas: Crazy, crazy. I mean, there really is no other trusted tool quite like that. Is there a second player in multi-sig tech on top of EVM?

Jonah Erlich: There are a few nascent players, but none of them have the traction that Gnosis Safe has. I'd say one of the things about safe that attracts so many people is essentially the Lindy effect, which is however long something has been around, it will likely be around just as long. I think that's especially important for a lot of folks with smart contract security, which is basically, hey, this smart contract has been safe for X amount of time. Therefore, it is probably safe, which is another kind of layer of security reassurance added on to testing audits, everything else that needs to happen. So I think folks are really nervous to using a new multi-sig, especially if it's a lot of their assets that are being stored in that safe.

Ittai Svidler: I was going to add on, on top of that Lindy effect, which Jonah mentioned, which is strong, there's. maybe it's overlapping, but there's also the social proof effect. As everyone is using it, you feel a lot of safety in the consensus. A lot of times we prefer to give credence to the non-consensus right view. But sometimes in security, the feeling of consensus makes people feel a lot more secure, especially when you have names like Vitalik referencing their own usages of certain protocols or tools. That social proof really adds to it too.

Nicholas: Yeah, definitely. Sort of shifting back to the dense, you mentioned that the average user is less technical than they used to be as the blockchain tech proliferates, basically. I'm curious, do you think that multi-sigs are something that if you're focusing on these operational teams, do you think it's more something that's for still a relatively technical user within the scheme of things? Or do you see kind of regular people using some den version of safe in the future?

Ittai Svidler: We see really, even as the average user becomes less and less technical, we still see them using a piece of software like Gnosis, or really something that's built on top of a multi-sig. And one of the reasons why we have this thesis is because we see players like ourselves whose mission it is to make sure that that's the case. Right now, it's pretty clear that a smart contract wallet, a multi-sig, assuming it has the Lindy effect of the social proof, is sort of the gold standard for teams that are doing things on chain. Now, it's just a matter of making it as user friendly and sort of redefining that user experience so that even really non-technical people can use it. So the short answer is yes, we do still see, even as the trend towards non-technical users increasing, we do still see it as the dominant tool. And part of it is because it's only going to get more and more user friendly, to the point where you really don't have to be technical at all. A lot's going to be abstracted away from you.

Nicholas: Are you interested in other chains as well? Or are you really focused primarily on Ethereum mainnet?

Jonah Erlich: We currently support mainnet, polygon, arbitrum, and optimism. It's pretty easy for us to add on any other chains where Gnosis Safe is deployed. So we really let this be driven by our customers and what their needs are. And if we start seeing a ton of customers move on to Solana or maybe a Cosmos chain, we're going to have to evaluate, hey, is there open source infrastructure on these chains that we also want to support through Denton? But right now, what we're really seeing is a ton of our users are mostly on EVM chains. And there's really a kind of concentration on a specific number of chains. We see a ton, for example, on mainnet and polygon, and a growing amount on those other two. We're likely going to add a few more EVM chains in the near future as well.

Nicholas: And do you have any thoughts on like other contract wallets like Argent or other schemes for, I don't know, dealing with assets on the blockchain?

Jonah Erlich: I think Argent's a good one, because we're really focused on a different customer base than Argent, where Argent is much more focused on individual users, where we're focused on organizations, which are very interesting. And that's part of why we want to move into doing a lot with this module system with the role-based access control. So we can work directly with teams and understand, all right, what works best for your team? Is it a role-based access control approach? Is it a optimistic execution approach where one person has to sign it and the rest of the signers can veto over a certain period of time? There's a broad design space that is pretty much unexplored at this point. So that's something we're really excited to dive into directly.

Nicholas: Yeah, tell me more. I want to hear more about what you think about the future of wallet UX or in other ways, just interacting on chain. Is multiplayer essential to Den? Or is that just how it works to start?

Ittai Svidler: Den's really focused on multiplayers. And specifically, I guess we like to call them teams. And that's really what we're going to be focused on for the long term. Really, the way we like to think about building a good product is similar to how Jonah alluded earlier on, we really like to work backwards from the customer. So we don't like thinking in terms of what technology could be cool, and then find someone who might find it useful. We really want to find someone that we know and understand very well, and can use that growing understanding to serve them. So we really started off by really precisely defining who our target customer is, as teams that are organizing on chain that are doing interesting transactions in addition to simple token transfers, but interesting transactions is in interacting with dApps or smart contracts. In our vision, in our roadmap, at least for the medium or long term, as it stands now, is really just focusing on those teams, just because that's our core philosophy.

Nicholas: That makes sense. It seems like Den is the kind of product that you would use if you were to do Constitution DAO over again, right?

Jonah Erlich: Exactly. One of the things that we said a group of us gathered together, actually, while the auction was taking place in a co working space in New York. And one of the things that was said at that event is, we may have lost the battle, but we will win the war. And I think a lot of what's really exciting about Den is we're building a tool that would have made us a lot faster, and we'll make teams like Constitution DAO in the future a lot faster, and a lot more effective as organization.

Nicholas: I know there's a lot of products out there that are creating front end experiences that they pitch in different ways, like squad wealth approaches, or things that are competitive with products like party bid that are more oriented around a multi sig like based on gnosis safe. How do you perceive of the space in general?

Ittai Svidler: We see a few different categories of companies or products that are building on top of safe, and they're somewhat mutually exclusive. You see some of these that are building specifically for the use case of payroll, and HR compliance for maybe DAOs or on chain organizations that are paying out contributors or employees and want to be compliant with regulations. And they want to make just those payments really easy or sending invoices really easy. That's one category. There's this other category of treasury management, maybe accounting, checking inflows and outflows of your safe for your organization. There's also our space, where really we're trying to be this tool specifically for teams that are very specifically trying to do these smart contract interactions and DAP interactions. And I would sort of bucket the entire space into those three categories.

Jonah Erlich: To add on to that, you can think of a lot of these other players as special purpose tools, which to be fair, there's a lot of needs for those specific purposes, right? There's a ton of teams that are doing payroll. There are a ton of teams that are doing treasury management, where we're building a much more general purpose tool, because we know that the growth of the general purpose programming on EVM chains is explosive right now. And there's going to need to be a tool for those general purpose interactions.

Nicholas: Make sense. Make sense. If anyone in the audience has a question, feel free to request and I'll bring you up, we can hash it out. The DEN product is pretty straightforward right now. I'm curious if you can share any more specifics on what you are interested in working on as problems in the future.

Ittai Svidler: We haven't really publicly announced a lot of the long term vision, but I guess I'll state like a few small alpha leaks. And it's all again, in that context of just helping teams move 10 times faster on chain without compromising on security. The next logical step. So right now we're helping coordinate signers with that notification service. And we're now helping them sign very quickly and understand damn well what they're signing by decoding the data and adding context messages and simulation. But the next logical step is actually going to be tackle the other end of the problem. Before you actually have a transaction to sign and execute and understand, someone actually has to build that transaction, they have to specify what it does. The next logical step for us is to make building just as fast and convenient and abstracted away experience as signing is right now.

Nicholas: This is definitely the obvious next step. As you say, about a month ago, I ran a hackathon along with some other folks at Juicebox and Build Guild. We recently made a proposal to Juicebox DAO that passed to distribute a bunch of JBX to all the teams that submitted projects to the hackathon. So we queued up a transaction from the multi-sig that controls the Juicebox DAO, Juicebox treasury, and also has a bunch of JBX tokens in it. So we queued up a transaction to first of all approve the disperse.app contract to move JBX tokens belonging to the multi-sig and then to transfer 50,000 JBX to each of the nine teams that participated. And in the end, we sent 50,000 weigh units of JBX rather than times 10 to the 18. Definitely the construction of transactions, luckily in that case, wasn't a big problem, but it would be very helpful to be able to have better eyes into what it is that you're building, especially when it's a multi-step transaction like that, but you only want the signers to have to sign one time.

Ittai Svidler: Yeah. And we see, especially with those more complicated transactions, some of the current DEN customers or DEN users, they'll even employ what they call a DevOps person, similar to DevOps, but someone who specifically manages these things, specifically building transactions. We have people that are using DEN right now that have engineers that are dedicated to writing custom scripts, apesafe scripts to be able to run their transactions. We have other teams that are building custom interfaces. They're building, they're taking engineering resources and building custom front ends to actually build these transactions. And that's kind of insane. You shouldn't need to have an engineer on staff full time to build those transactions. It should just be made so easy that anyone could do it.

Nicholas: Yeah, absolutely. I'm curious. outside of DEN, well, actually within DEN, how do you each divide your responsibilities? I know there's three of you on the team right now, right?

Jonah Erlich: Yep. There's three of us on the team. Myself, E-Tai, and our engineer, Nick, who is on the call right now, actually.

Nicholas: So right now...

Jonah Erlich: Hey there, Nick. Yeah, right now, since we're so small, we're pretty much all doing everything. Both E-Tai and I are engineers, which is great, which makes us move a lot faster. We actually, in the very early days, sometimes would ask ourselves, how do people start startups without being technical? Because it's been so hard just being the both of us technical. But yeah, we have some split of responsibilities internally. But right now, we're both doing a lot of the work around engineering, around support, around customer onboarding. The most important thing for us is that we spend as much time with our users as possible to really understand what their problems are, how they're experiencing the product, and just taking in a lot of information. And actually, every week, we go over all of the feedback from the previous week, and we'll quantify and categorize it to decide, all right, what's the most important thing for us to work on to improve the user experience? It is a pretty even split right now. Yeah.

Nicholas: That seems like a great process for keeping track of feedback and prioritizing it intelligently. Is that something that you picked up in a previous workplace?

Jonah Erlich: Not particularly, but I do get to flex my no-code skills coming from the no-code world. So this is actually using Airtable, not Bubble. But I am an automation and process junkie. I really like to figure out ways to really do a good job of organizing information to make the best decisions.

Nicholas: Does that impact the composability mindedness of designs around DEN itself?

Ittai Svidler: I guess, how would you define the composability aspect of that?

Nicholas: I guess, like, to me, I think of things like throughout interfaces I deal with, we're constantly asking for like CSV exports, for instance, just as a very simple baseline, let me get the information out of this interface and pass it into something else.

Ittai Svidler: Well, really, so it's still customer driven. As we ask, what problems do you have when we're first onboarding new users? or as we do our weekly check-in or a month check-in, as we start to see those pieces of feedback, it's really about making things as amazing for the user, the customer. I'd say it probably impacts it positively, just because if that's something that we start to understand is really helpful, it's something that we start to prioritize. We can't even help it because Jonah's ruthless organization skills in the air table, those pieces actually start to bubble up in our backlog.

Jonah Erlich: I'd also want to add on to this that our real ideology at DEN is that everyone on the team should really understand the customer. Nick is on customer calls and he's diving into this feedback. And we are actually dedicated to not telling people what to work on, but rather do their best to understand the customer and then decide what they think is the highest priority thing. Because we know, especially as an organization, as we scale up, we're not going to be able to see everything. But folks that are actually paying attention and listening to the customers are going to be able to know, all right, this is the most pressing problem that needs to be solved. It looks like no one has tackled it yet. Let me grab it.

Nicholas: Makes sense. Do you see DEN as a company more or something in a decentralized orientation?

Ittai Svidler: We see it as a company. And the reason why is because staying small and keeping that company structure, we see as our competitive advantage for moving as quickly as possible and serving customers. We've had a lot of involvement with DAOs and philosophically, we are extremely well aligned. And we think that they're amazing for different kinds of things. We think they're amazing for things that need consensus. We think they're amazing for things that don't need to move as fast, but are really, really, really valuable and require a lot of trust. With us, that part that requires a lot of trust is actually sort of outsourced to SAFE. Because we build on SAFE, because the actual smart contracts are built by them, we can be a company and move quickly because the parts that need to be super robust are already robust because of the SAFE DAO.

Nicholas: Is it that justifies like enabling a nimbler company to build the front end rather than creating further DAOs to create those pieces of software?

Jonah Erlich: Exactly. And something we have talked about is in the very long run, looking at what it would be like to decentralize and become a DAO. But what we realized very early on is that to succeed at building something that really helps people, we need extreme focus. And we really wanted to focus on specifically the product and solving customers' problems, and not as much as how do we build a product organization super well in DAO form. It's something that we're open to in the long run, but just because we wanted to be able to solve these problems as fast and effectively as possible, it's something we chose not to innovate on. Especially given that we're also in the United States, and for regulatory reasons, we want to see how those things play out a little bit.

Nicholas: Yeah, for sure. I think of it only in terms of as a contributor at a DAO, there is always a bit of a preference amongst the DAO members to choose products where the DAO can become a stakeholder in the product itself. Not necessarily because we want to breathe down the neck of people who are doing good product design and development, but more just because we'd like to be sort of mutually invested in one way or another also. It'll be interesting to see if that models emerge that allow for teams to feel like they have the complete responsibility for the product development, but nevertheless can allow people to, for instance, in the juice box model, like the fees that you pay become a form of stakeholding in the project itself. And so projects that interact with each other, that pay for each other's services become intertwined.

Jonah Erlich: Definitely. I think there's a broad world of experiments that are being figured out right now, and we are paying close attention to what's happening in these experiments. And we're really excited to see what we adopt as the dust settles a little bit. And while we're doing that, what's really great about what we're building with DEN is we get a first-hand look at all of it. Because our job is to make sure that all of these really complicated transactions from these new experiments that all these teams are running are super easy to do and super quick.

Nicholas: I'm curious, you mentioned that your productivity, maybe guru is too much of a reach, but at least inclined towards these no-code automation tools. What are your favorite tools? What would you like to use?

Jonah Erlich: Yeah, that's a great question. So at DEN, we use Airtable and Notion. Airtable we use pretty much mostly for a CRM, just to keep track of customers, keep track of candidates, a few other things. That's what we use that for, Notion for all of our documents. Before this, I was an engineer at Bubble, which I highly, highly recommend as a tool for people that don't have technical experience, but want to build production web applications. A lot of really great options out there. A little bit of the way we actually see DEN, specifically around the transaction building, will be a no-code tool of sorts. A little more on that at a later time, but we've got some exciting ideas.

Nicholas: Yeah, I can definitely imagine at least making it feel something like a WYSIWYG or in any other way, like intelligent interface for creating the transaction seems to make a lot of sense. Have you played with Zapier at all?

Jonah Erlich: Yeah, I have played with Zapier a little bit. Zapier is a great tool. I've heard a lot of great things from folks that have used it a ton. I haven't used it in any sort of production use cases, but have messed around with it.

Nicholas: Cool. Itai, are you interested in similar subjects? What's your passion?

Ittai Svidler: Yeah, I'm definitely quite interested. And I think one of the things we learned, especially with these organizational tools and productivity, and almost as a philosophy, it's certainly one of our company values, which is to focus on the one thing. But we found the same thing with organizational tools, where in just about any situation, anytime you have some sort of goal, there's usually an exponential distribution of things that actually move the needle. There might be one or two things that move the needle 10x more than the next few things.

Nicholas: Absolutely.

Ittai Svidler: And so we like to focus on and try to find what those are. And I think the same is true with productivity tools, where we've really indexed on what those one or two things really, really are, which is that CRM really documenting and quantifying customer feedback. So we can really understand and not let anything slip through the cracks, really understand our customers to drive the product. And we found that you don't need a whole lot outside of that to really move the needle in terms of organizational stuff. And we think that's one place where it really, really helps. But there are certainly other places where it can get in the way and slow you down. In terms of productivity, I think it's still all about finding that one or two things that really moves the needle in terms of the system and focus on that rather than trying to over optimize absolutely everything.

Nicholas: I neglected to ask earlier on in the conversation, but what is the business model for DEN?

Jonah Erlich: Yeah, that's a great question. We have a few ideas on where things are going. The thing that we think about is that if we have the best experience for organizations to manage their assets, manage their multi-sigs, manage their smart contracts, then we'll have distribution in whatever way we choose. A few things we're considering is financial products and services, as well as subscription features for specific premium things. For example, one thing that's really not offered at all for on-chain organizations today is fraud protection. So that's one potential avenue that we can explore. But right now, we're really, really focused on how do we build the best possible. So we're not really focused on the monetization at this point. Just because we know that the most important thing is we need as many organizations as possible using DEN.

Nicholas: Yeah, makes sense. Is there anyone in the audience who'd like to ask a question or make a comment? Or Jonah, Itai, I don't know if either of you would like to cover anything we haven't discussed yet.

Ittai Svidler: Yeah, while we're waiting for questions, I think it'd be interesting to cover sort of the broad overarching philosophy that we have, which is we really believe that the world is moving on-chain in the era of time. I don't know if it's the next year, next two years, but probably certainly the next 10, definitely the next 20, no question. And as the world moves more and more on-chain, you're going to see that a lot of people are going to be organizing as teams on-chain, whether it's traditional companies or more DAOs, or just other types of on-chain organizations that we can't even predict right now. And if you really look forward and you think that that's going to be the state of the world, then you know, you got to build some tools to actually enable it. Someone's got to make that actually possible. That's really sort of what gets us out of bed every morning and gets us to the office. It's knowing that we can be a part of helping the world move on-chain and become more efficient and become more trustless by doing what we do.

Nicholas: Yeah, I definitely agree with you. It seems obvious that many of the problems facing people all over the world today are ones of social coordination and cryptocurrency and blockchain more specifically is the technology, the first technology I've seen that really has something to say to social coordination, enabling all kinds of new forms of social coordination. And so it makes perfect sense, I think, to build the tools that people need informed by what their problems are today. Because as that, as the use of blockchains grows, you're just going to grow with it. So it makes perfect sense to me. All right, looks like we don't have any questions today. Yeah, Jonah, do you want to say something?

Jonah Erlich: I just wanted to add one last thought kind of philosophically there, which I think one thing that's really interesting about this space and kind of what we're enabling is a lot of software for the last, you know, 30 to 50 years has been a wrapper around things in the real world. And I think that's becoming much, much more clear as over time, governments are taking a little bit more people's abilities or big tech platforms are starting to censor where this is our first chance of really, truly digital things

Ittai Svidler: that have

Jonah Erlich: a physicality to them in a way that's difficult to describe. It's a bit of a more of a weight to them where they're not the wrapper over the real thing. And I think as more and more people start to realize that, the more and more adoption we're going to move towards. So that was the philosophical thought. The last thing I do want to share is that if you're an engineer looking to work at an exciting crypto startup, we are hiring. So please reach out.

Nicholas: Awesome. Yeah. I think it's going to be a very fun place to work, particularly because you laser focus on what actually moves the needle. I think most startups fail because not because they don't have the talent or the vision for what's next, but because they fail to focus on what actually matters and end up delivering features, even things that people ask for, but that just are not going to be decisive. And whether or not those people continue using the product or new people choose that product over other products. So I think that laser focus is going to serve you very well. And it's clearly made a product that in a field of many different competitors, to me, stands out as something that really is just the most effective solution for people with this problem, which is going to be a growing set of people. Seems like a great job opportunity.

Jonah Erlich: I appreciate that. Had to show when I had the chance. I think I appreciate also the focus. I think you're right on that. And we talked to a lot of early stage founders that struggle with this. I think particularly with what you said is people building what customers say they want. I think one of the hardest things about really building any sort of product is understanding the difference between stated preference and express preference. And Itai actually pointed out a really great example of this the other day, where everyone on Twitter likes to hate on threads. But the thing is, you see those same people liking and engaging with threads. So the stated preference is I don't like threads, but the express preference is I do like threads.

Nicholas: Definitely same thing with regard to reverse chronological feed over algorithmic feed. I mean, if you take a step back, people don't like relinquishing the control. But if you take a step back, I definitely don't want to see 100% of everything that's posted. I want to see the best 10%. And people claim to want the opposite. But I think in practice, what you really want is just a better algorithm or something that's so good that you don't even think about it anymore. It's very difficult, especially in the space where there's so many things left to build so many basic, basic things to choose where to focus our attention and also to create structures where the stuff that we're building. There are many, many kind of even public good sort of things that people need, but they also need to be sort of collected into organizations or initiatives that can be sustained and maintained as the underlying technologies change. And they need to be updated or made more ergonomic for new form factor devices, etc. Limitations of the platforms that we're building on top of. It's definitely a challenge to choose both what to work on and how to connect it to other projects that will allow it to exist into the future. If that is your goal. Well, E-Tide, Jonah, this was awesome. I'm a big fan of DEN. I'm excited to use it more in future. multi-sigs and whatever else other features you come up with, I'm sure they will be useful based on how you choose to implement them. So thanks so much for coming on today and sharing a little bit of your process.

Ittai Svidler: Thank you for having us. Thank you for having this discussion because it's obviously something we are very passionate about. We really enjoyed it.

Jonah Erlich: Yeah. Thanks so much for having us, Nicholas. This was great.

Nicholas: Absolutely. It's a pleasure and good luck with your future product development. Talk to you soon.

Jonah Erlich: Awesome. Thanks again.

Nicholas: All right. See you around.

Jonah Erlich: I'll see you.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter at Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.