Mistakes made and Lessons Learned While Building PWN

Thank you, John. One, two. Hey, everybody. I'm going to talk about mistakes made and lessons learned building Pawn, essentially the reflection of what we did so far and what we've learned from that. I'm going to start with a short intro about my background, then talk a bit about what's Pawn, and then finally get into concrete mistakes and talk about a concept of optionality versus outcomes tracer, and then finally mention a couple of conclusions and what are the actual lessons that we learned and that I wish we kind of knew back then.

My name is Joseph. I would say the way I got here follows the traditional crypto-native story. I've been in the Ethereum space mostly for almost 10 years now. I actually attended my first meetup here in Berlin at the old EF's office. I started hosting my own meetup in Prague in 2016 and got involved in Ethereum first as a community organizer, so it would be developer, organized a bunch of workshops, so kind of got the technical skills back in like 2016, 17.

And then I spent four years at Ethereum Foundation working on like various things. And then finally in 2021, 2022, I decided to join the dark side and start a DeFi protocol. And the motivation for that was actually being rejected by TriFi. So I spent my 32 now, I spent the majority of my professional career in crypto, considering myself a crypto-native. And when I was about 29, 28, I wanted to get a mortgage.

So I went to the bank. I was paying the need back then, and I got rejected. It got me triggered. And that's essentially why I started working on more DeFi, like additional DeFi protocols or DeFi lending protocol that works slightly differently than Maker or Ava at the time. And since then, kind of started defaulting into building within the DeFi space.

And one concept, the first concept that I want to kick things off with is the concept of optionality or optionality principle, if you want. I'm sure a whole bunch of you have seen this. Oh, there's no presenter here. But a whole bunch of you have seen this life journey of, well, you start at one point, and then you have all of these paths open, and then time passes, and you kind of pick one of the options, and boom, 30 years later, there is, again, like a space of opportunities, and you kind of pick one life path that's ahead of you. And obviously, like a trivial case of the optionality are all the paths that are actually open to you, all the doors that you can walk through.

And one clever person back at EF has kind of, like, triggered this line of thinking of, okay, like, if you want to build a protocol, if you want to build something that you kind of feel is useful, but you don't actually exactly know how useful it is, optimize for optionality because you don't know which one of those use cases will actually end up being the one that people kind of go for. And it's kind of the same story with Ethereum. Like, Ethereum started with these, like, three pillars of, you know, decentralized storage, execution, and messaging system. Boom, all of a sudden, a couple of years after, we just talk about EVM. We don't talk about Swarm.

We don't talk about Whisper and all of these other things and all of these other use cases, and it's mostly DeFi. And I would say it was one of the benefits of the protocol, right? Like, it was high optionality. It was a universal usage, so you kind of could figure things out on the go. And that's how we started Pawn as well.

Is anyone in the room familiar with Pawn? One, two people. Okay, so Pawn, we call Pawn the universal lending protocol for the tokenized economy. It works slightly differently than Aave or Morpho. It's peer-to-peer, crowned up.

There are no pools. We actually tap into Aave, Morpho, Euler, Compound, and, like, other pools for liquidity. And we have this intent-based structure where, like, people can fully customize the loan terms and can create different loan types. The nice part here is it's largely permissionless, so you can use any token, any fungible or non-fungible asset. If it has a ERC-2721 LN55 interface, then you can use it.

You can Pawn it. And we started building the protocol universally and started creating a product on top of it. But the holy grail of the protocol should be long-lasting DeFi mortgages, which was also, like, my initial motivation for starting the protocol in the first place. But truth be told, there is no DeFi mortgage market as of now. I hope there will be at some point.

So Pawn was designed in a way where it should be able to service that market, but it should also be able to service the markets that are here now, that don't actually require a lot of, like, new convictions to enter the space. Pawn as a protocol is managed by PawnDAO, and PawnDAO is a crypto-native credit collective. It's a DAO that governs the protocol, upgrades it. Pawn is, like, append-only upgradable, so there's no way to actually influence anything that happened, any loans that happened, like, prior to an upgrade. And an upgrade, in our sense, means that there's a new loan site, new functionality that can be used from one day on, but doesn't affect, like, any of the past loans that were created.

And the credit collective, it's not just like a DAO that governs the protocol and gets the fees. It actually has this, like, circle treasury utilization system inbound, which is closely tied to the protocol. And the whole case is that with PawnDAO, we are kind of trying to recreate this credit union type of setup where people can actually leverage the treasury of the DAO to use it on Pawn itself and fund loans out of crypto-natives at better rates. So, which mistakes did we make building this up? When, by the way, we started with the proof of concept in 2021.

In 2022, 2023, we were kind of alpha testing, beta testing. And then, finally, in 2024, we launched the version 1, and the current version was deployed around September last year. And there was a lot of learning in the process. I think we passed roughly eight to nine audits with the different versions until then. So, the first mistake, the big one, obviously, I assume everybody knows it, but people don't say it often enough.

We did not do quite enough user testing. And I say it with the guilt that I feel for it, but if you work with a product person that doesn't appreciate your users and doesn't talk to them, like, weekly, then you shouldn't be working with them. I don't mean it in a bad way, but it's, like, it's crucial. And I think if we actually had this as part of our DNA from day one, we'd be way, way better off. So, on the way, we created a lot of tools that people said were cool, but nobody actually used them.

I'm going to dig into those a bit later. One of the lessons learned here, well, if people tell you that's super cool, it actually means a lot less than if they tell you they're going to use it. So, the cool factor here doesn't actually count all that much. We also, being the true crypto natives, we cared a lot about things that, well, people said they care about, but nobody actually cared about. Like, we did not use any analytics tools for the first, like, year and a half.

And then we only picked the ones, like, plausible, the privacy-preserving ones. And then, finally, we kind of, like, through multiple poofs, ended up with something called Hotjar, where you can actually get a lot of data, which is anonymized still. And we had this, like, opt-in, opt-out system from it. But, truth be told, like, that was my mistake. I was kind of fighting adding the analytics tool for a long time.

We added it. Nobody cared. We should have done this from day one. We also started with multi-chain support, essentially, from day one and started supporting all the tokens. It created a huge mess.

I'm going to talk about this in a bit. And, again, it's a nice thing that we thought people would care about, this, like, multi-chain experience. But, in fact, like, people are fine using their assets on one chain and, like, even having different wallets for different chains. And then we built things that, again, were cool, like PawnSafe, and created, like, a custom flow. We spent three months on that, and we figured it's, like, completely off because we didn't talk to a single user while doing that.

And, again, coming back to we did not do enough use testing, we wasted resources, time, and money. So here's one example. So the first interface looks something like this, and it's actually still in the platform. This is the universal market where you can lend and borrow against any ERC-2721-1155 token against any ERC-20, and you can fully customize your terms. It's nice, right?

It gives you a lot of optionality. The thing is it's very hard for users, to DeFi users, to actually set the rates. So this was off. This is basically overload with actions. So we had – let me see if I can step out here – we had a bunch of call-to-actions, people being able to fully customize their setups.

It was a bit clunky. It was, like, very hard to actually find the match and the fit. So we went on, and we started with a curation system that you kind of know from Morpho. We started onboarding curators, started, like, curating our thesises with community members, and then got slightly better. It actually led to increased deal flow, but we, again, kind of messed up with fill, providing, like, too many options.

So finally, two weeks ago, we ended up with this. It's like a sub-product based on the same protocol. It's called Hatch Notes, where we simply picked a basket of collateral assets, wrapped ETH, wrapped Bitcoin, and, like, set the rates for users. Now there's just two buttons, lend or borrow, kind of the AVA style. And it seems like, well, both AVA and Morpho have actually proved it's kind of a better way to handle things.

The other thing, multi-chain experience. So Pawn is deployed to, I don't know, like, 10, 12, 13 different chains. It's very easy for us to do this. Like, right now, it's actually just about adding a config file and deploying the protocol, and that's it. It works out of the box.

And we have this huge system of filtering out assets on different chains. You can, or you could have picked, like, three different chains and filtered the entire platform based on the chain selection. But, again, it showed a lot of clutter, and we had this for almost two years. And now, finally, we defaulted, again, into single chain because, well, the users that actually have the money to be used, they prefer to basically view just this segment of what they can do immediately. They don't want to think about, well, I have to bridge all of this somewhere else in order to access a different market.

So a lot of effort wasted. One of the biggest mistakes was actually, in 2022, developing libraries for SAFe. It was called PawnSAFe. It was actually this beautiful functionality which allowed you to use the collateral while it was in the escrow. It was based on a safeguarded module.

We enabled creating, for any asset, we enabled creating these tokens called ATRs, asset transfer rights. It was essentially a tokenized transfer right to a token, which would be used as a DS collateral. And we spent, like, three months integrating into whole flow, and I think we had a total of 10 users actually ever using it. Everybody said this was cool, and they'd never seen this before. And hopefully this may become handy at some point, but the point is we heard a lot of the, this is cool, I would actually use it, and based it on a lot of resources on this.

And we had an entire dev console just about the setup of the wallet. Another mistake here, we were duplicating the job of a wallet. So we created this rich asset explorer dashboard where we list all of the tokens, including the ones that are kind of the spam tokens. So we had to add, like, filtering for those tokens. But it was a multi-chain explorer where you would, like, just log in with your wallet, connect your wallet, and we would crawl all of the asset holdings, all of your ERC-20s, all of your NFTs in one setup and get the prices for them.

And it was a lot of data, but, well, that's a wallet job, not really a platform job. And then finally, just kind of the underlying, the biggest mistake early on was not picking the user niche. So, like, we provided a lot of functionality, a lot of optionality in the platform part, but we did not have the right mindset of actually having a convinced product person that would just dig into a particular market niche, and we kind of wanted to serve everybody on the platform side. We even had these cases where one of my co-founders would go on stage and call people retarded when he was talking about, like, user research. That's not right-minded.

Like, if you're talking to users and you think, like, this guy doesn't know what he's talking about, you're talking to the wrong person. You should really pick your user and really work on the stuff that will help them. And, yeah, kind of bridging into the lessons learned, not all DeFi users are actually savvy enough in the terminology and the mechanisms of the DeFi apps. So, even though we thought, like, we are going to bring something universal for communities to use, we did not actually find too many people who were able to adjust the rates and, like, even had a conviction or have an idea about how the rates should be set up. That's why the curators can kind of bridge that and help with that.

Talking about not mistakes. Like, is any of you a product manager or a founder of a project? There's a guy. So, there's, like, a couple of the mistakes that I think we did, again, like, mentally was being too clinched on not pivoting for some moment. And I think it's kind of generally useful to be open to making small mistakes and being open to making a rollback, especially if you're a developer.

I think it's mentally very hard to say, okay, I'm going to work on this, I'm going to code this up for 14 days, and we might just throw it away. And I think it's especially difficult for coders, not so much for, like, designers, not so much for product folks. But I think there is this, like, mental blocker on the developer side when it comes to code things that might not end up being used. But, again, like, that's kind of the reality of building a new product. And the kind of relates to just being open to trying things without leaning fully in and kind of being open to change later on.

One of the cases, we created these pawn spaces, essentially just a filter of the assets on a slightly different interface, slightly different colors for the interface for things like Abagochis, where we had organic fraction. It was, like, a very, very trivial setup, very useful for just BD showcasing and so on. I'm glad we did this. And we also created this, like, robust asset explorer, which, well, you could say, it's, again, not part of the core product, but it has compounding effects. So we crawl and we cache a lot of the data, so we actually now have this rich database of different assets on different chains, and we become less and less dependent on third-party providers.

We also have some useful smart contract tooling. So early on, we decided to support all of the tokens and created a wrapper called the multi-token library, which essentially wraps interfaces of ERC-2721s and 1155s. That ended up being very useful for just, like, building different toolings, such as token bundlers, which kind of ended up having organic traction as well. The token bundler is just a small, small contract that lets you wrap any multi-token into an NFT. So, again, people could have created these, like, gaming bundles with a wider class of assets in those and get better terms.

Now, before I jump to the lessons learned, is here someone who isn't familiar with the concept of Occam's Razor? Thank you for always raising your hand, man. Help. So there are a few ways to look at this. So the one-on-one kind of definition that Perplexity threw at me was Occam's Razor is a phenomenon when faced with multiple explanations for something, and the simplest explanation is likely the correct one.

Now, when I was at my university, one of our teachers of classical logic has been pushing this concept of, like, logical Occam's Razor, which is kind of a simplified definition that when you're trying to prove a theorem and some arguments are necessary for the proving process, just leave those arguments out. You don't need them, they will just distract you. And now, I know it's kind of like bending the rule a bit, but I kind of like the concept of UX Occam's Razor, which is like a very simple idea of when an element in the interface, and it's kind of what we've been trying to apply over and over, and we are still kind of fighting with setting up the mindset to just keep on using the Occam's Razor principle. When an element doesn't serve a unique purpose, just kill it. Like, don't have it in the interface.

If it's just like a gimmick, it doesn't have to be there. Don't worry about it. It goes as far as, like, devs just randomly adding, like, 3.2 descriptions somewhere. It's just distracting.

It doesn't have to be there. But sometimes, mentally, it's, like, very hard for people to leave the unnecessary parts out, and continuously we're trying to apply this rule in the product building flow, and it actually has some benefits. Like, things get clearer. We have, like, better feedback now while we use it as these things. So, before I jump into the conclusion, like, early on, or it's actually part of the conclusion, early on I mentioned that Pond was built with this optionality principle, but then the whole talk was actually about saying you should do less than more.

So, saying, like, you should actually close these doors as you build, and I think it's, like, both true. Like, it's true on the protocol level. I think that the fact that we had this huge optionality on the protocol level, and it enabled us to survive all of these, like, market hypes and market cycles because we were able to simply pivot into a different market niche from NFT collectibles to GameFi to LP tokens, Escalado, to RWAs. The protocol supports it all from day one, and it's good because it costs a lot of money to audit a protocol. It costs a lot of money to develop and deploy a new version.

It's kind of the longest development cycle. But the optionality on the product and interface side is that. That's where you should heavily apply the Occum's race. And it's natural, right? But I kind of wish somebody had told me this a while ago because I still took the optionality principle as a way to go, and we created a lot of interfaces with the optionality, although all of the UX designers were telling us, well, just keep things simple, yada, yada, yada.

So, these two kind of go against each other, but we are in this unique space where, oh, you have to distinguish the protocols and the products built on top of those protocols. Another lesson learned is that value, very often, especially in DeFi, financial value, means a lot more than values, than kind of the things that people say they wish the projects look like and so on. Like our saying known to analytics tools and kind of being blind towards what we are actually building. And, yeah, I actually, until now, I did not hear a single negative feedback on us at an analytics tool or us kind of cutting corners somewhere and not having a fully decentralized front end so far. And all of those values are nice, but if you're trying to build a product and you're trying to sustain it, well, then sometimes you kind of have to focus on the user itself.

And if you succeed and you actually create something sustainable, then you can start thinking about decentralizing it and providing multiple different front ends and so on. The cases where you care too much and optimizing too much for the values alignment early on, you may as well fail and never actually live to the moment where people care enough about this. Kind of related, over-optimization is suboptimal. So if you over-optimize during the flow, it costs you resources but also motivation, especially the developer motivation, because people just lose track on having progress, having momentum. And I think in this very competitive space, having momentum is super important.

So if it works, if something works, don't worry about it, just leave it there. If it doesn't work, just remove it and figure things out on the way. And one last kind of lesson learned, especially when trying to build a new app with a completely custom front end, there's always the question of, like, should we now optimize, should we refactor the code base, or should we just build this new feature? I came to realize that refactoring is kind of like territory for developers. So if you're working with the developer team, let them refactor at times.

Like, give them one sprint throughout the month where they can just focus on refactoring. Otherwise, they are just going to go nuts. And, yeah, my time is actually up. And if there is time for questions, this is from me. I'm happy to answer them.

Thank you, Josef. Any questions? Any questions? All right. If not, then please give another round of applause.