DAPPCON 2025: Mistakes made and Lessons Learned While Building PWN - Josef J

Transcript

Thank you, John. One, two. Um, hey everybody. So, I'm going to talk about mistakes made and lessons learned building pawn. Um, essentially is a reflection of what we what we did so far and what we've learned from that. So, 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, um, and talk about a concept of optionality versus a comeser. Uh and then finally mention a couple conclusions and what are what are the actual lessons that we learned and that I wish we kind of knew um back then. So my name is Joseph. Um um I would say um the way I got here follows the traditional cryptonative

cryptonative 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 uh EF's office. I started hosting my own meetups in Prague in 2016. um and uh got involved in Ethereum first as a community organizer, solidity developer, organized bunch of workshops. So kind of got the technical skills um back in like 201617. Um and then I spent four years at Ethereum Foundation working on like various things. Uh and then finally in 2021 2022 I decided to join the the dark side and and start a D5 protocol. Um and the motivation for that was actually

being rejected by Trefi. So I spent my 32 now. I spent majority of my professional career in crypto. Uh considering myself a cryptonative and uh when I was about um 29 28 um I I wanted to get a mortgage. Um so I went to the bank. I was paid in back then and I got rejected. it got me triggered and that's essentially uh why I started working on uh more DeFi um like additional D5 protocol or D5 lending protocol uh that works slightly differently than uh Maker or or AV at the time. Um and uh since then kind of started defaulting into into building within the D5 space. Um and one one concept the first concept

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

through. Um and one clever person back at EF um has kind of like triggered this line of thinking of okay like if you if you want to build a protocol, if you want to build something um something that you kind of feel is useful, but you don't actually exactly know how useful it is. um optimize for optionality uh because uh you don't know which which uh one of those use cases uh will actually being uh end up being the one that people kind of go for. 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, couple years after we just talk about EVM, we don't talk about swarm, we don't talk about whisper uh and all of these other things and all of these other use cases. And it's mostly DeFi. Um and um I would say was one one of the benefits of the protocol, right? Like it was there was high optionality. Uh it was a universal universal usage. So uh you kind of could figure things out on on the go. And that's how we start a pawn as well. Um, is anyone in the room familiar with pawn one, two people? Okay. So, um, pawn, we call pawn the universal lending protocol for the tokenized economy. Um, it works slightly differently than a or um, morpho. It's peer-to-peer ground up. Uh, there are no pools. We actually tap into

a morpho oiler compounded like other pools uh, for liquidity. Um and uh we have this intentbased structure where um like people can fully customize the loan terms uh and can create different loan types. The nice part here is is uh largely permissionless. So you can use any token any funible nonfgeible asset. If it has a ERC20 721 1155 interface then you can you can use it you can pawn it. Um and uh we started building the protocol universally and um started creating uh products on top of it. But the holy grail uh of the protocol should be longlasting DeFi mortgages which was also like my initial uh initial motivation for starting the protocol in

the first place. But truth be told there is no defy mortgage market as of now. Uh I hope there will be at some point. Uh so pawn was designed in a way where it should be able to service that market. Uh but it it should also be able to service the markets that are um that are here now uh that don't actually require a lot of uh lot of like new conviction to enter the space. Um uh pawn as a protocol is managed by Pondo and Pondo is a cryptonative credit collective. Um it's it's a DAO that governs a protocol, upgrades it. Um pawn is like append only upgradeable. So there's no way to

actually influence anything that happened um um any loans that happened like prior to an upgrade. And then upgrade in our sense means that there's a new loan type, new functionality that can be used from one day on but doesn't affect like any of the past uh loans that were created. Um and the credit collective um it's it's not just like a Dow that governs the protocol and gets the fees. It actually has this like circle uh treasury utilization um system inbound which is closely tied to the protocol and the whole case is that with uh pond 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 to other

cryptonatives at at better rates. Um so uh which mistakes did we make um building building this up when by the way we started um with the proof of concept in 2021 and 2022 2023 we were kind of uh alpha testing beta testing and then uh finally in 2024 we launched the uh the version one and uh the current version was deployed around September last year. Uh and there was a lot of learning um learning in the process. I think we passed roughly 8 to 8 to nine audits uh with the different versions until until now. So, the first mistake, the the big one, obviously, I assume everybody knows it, but people

don't say it uh often enough. Uh we did not do quite enough user testing. And I say it I say it with the guilt that I feel for this, but uh if you if you work with a product person that doesn't appreciate your users, uh and doesn't talk to them like weekly, uh then, um you shouldn't be working with them. Um, I don't mean it in a bad way, but it's like it's it's crucial and I think if we actually had this as part of our DNA from the day one, we would be way way better off. Um, so we've created on the way we've 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, uh, the cool factor here doesn't actually count all that much. Um, we also being the true cryptonatives, we cared a lot about things that, well, people said they care about, but nobody actually cared about. Like we 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 the privacy preserving ones. Um and then finally we kind of like through multiple hooks ended up with um something called hot jar where you can actually get a lot of data which is anonymized still uh and we had this like opt-in opt out system from it but uh truth be told like I was my mistake uh I was kind of fighting adding

the analytics tool for a long time uh we added it nobody cared we should have done that from the day one we also started with multi-chain support essentially from day one uh 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 it's a nice thing that we thought people care about this like multi-chain experience. Uh but in fact, like people are fine using their assets on one chain and like even having different wallets for different chains. Uh and then we built things that again were cool uh like pawn safe uh and created like a custom custom flow. Uh 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. Um and again coming back to we did not do enough user testing. We've

wasted resources the time and and money. So here's one example. Um so the first interface looks something like this. Uh it's actually still in the platform. Uh this is the universal market where you can lend and borrow against any ERC2721 1155 token against any ERC20 and you can fully customize your terms. Um it's nice, right? It gives you a lot of optionality. The thing is it's very hard for users to defy users to actually set the rates. Uh so this was off. This is basically overload with actions. So we had not sure if I can step out here. Uh we had uh oops uh we had bunch of call to actions people people being able to fully customize their their setups. It it was

bit clunky. It was like very hard to actually find the match end of it. So we went on and we started with curation system that you kind of know from from Morpho. We started onboarding curators, started like curating our thesises uh with community members. Uh and that got slightly better. It actually led to increased um deal flow. Uh but uh we again kind of messed up with still providing like too many options. So finally two weeks ago uh we've uh ended up with this. It's like a sub product based on the same protocol. It's called patch notes where we simply picked basket of collateral assets u wrap e wrap bitcoin and like set the rates for the users. Now there's just two buttons uh blend and borrow uh kind of the the a

style and it seems like well both av and morph have actually proved uh it's kind of a better 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. Um and we had this huge system of filtering out assets on different chains. You can or you could have picked like three different chains and filter the entire platform based on the chain selection.

Uh but again it showed a lot of clutter and uh we had this for almost two years and um um now finally we defaulted again into into single chain because well the users that actually have the money to to be used um they um they prefer to basically view just this segment of what they can do immediately. They don't want to think about well they have to bridge all of this somewhere else in order to access a different market. So lot of lot of effort uh wasted. Uh one of the biggest mistakes was actually in 2022 developing um um libraries for safe. Uh it was called pawn safe. It was actually this beautiful functionality which allowed

you to use the collateral while it was in the escrow. Uh it was based on uh safeguarded module. Uh we enabled creating for any asset we enabled creating these tokens called ATRs asset transfer. Right? It was essentially a tokenized transfer to a token which would be used as a deed as collateral. Uh and we spent like three months integrating into whole flow and I think we had total of 10 users actually ever using it. Uh everybody said this was cool and they never seen this before. Uh and hopefully this may become handy at some point. Um but the point is uh we heard a lot of the this is cool not I would actually use it. uh and wasted a lot of resources on this and we had an

entire dev console just about the setup of the wallet. Um another mistake here we were duplicating the job of a wallet. So we created this uh rich uh asset explorer dashboard where we list all of the tokens including the ones that are kind of the spam tokens. Uh, so we had it 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 all of the asset holdings, all of your ERC20s, all of your NFTts uh in one setup and get appraisals for them, and it was a lot of data, but uh well, that's a wallet's job, not really a platform job. Um and then um finally was kind of the underlying um the 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. Um but um we did not have the right mindset of actually having a con convinced product person that would just dig into a particle market niche and we kind of wanted to serve everybody on the platform side. Uh we even had these cases with uh where uh one of my co-founders would go on stage and call people uh when he was talking about like user research. Uh that's that's not good right that's not the right mindset. 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. Uh you should really pick your user and

really work on the stuff that will help them. Um and yeah, one of like kind of bridging into the lessons learned. uh not all D5 users are actually savvy enough in the terminology and the mechanisms of the D5 apps. So even though we thought like we are going to bring something universal for communities to be to use uh we did not actually find too many people who were able to adjust the rates and like even had a had a conviction or have an idea about how the rates should be set up. Uh that's why the curators can kind of bridge that and uh and help with that.

Um talking about not mistakes like uh is any any of you a product manager or founder of a project? There's a guy. Um so there's like couple couple of the mistakes that I think we did again like mentally uh was uh being too clinched on not pivoting for for some moment. Um, and I think it's um, it's kind of generally useful to be open to making small mistakes and being open to making a roll back, 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 it's especially difficult for coders, not so

much for like designers, not so much for product folks. Um but um I think there is this like mental blocker on on the developer side to code things that that might not be end up being using used. Uh but again like that's that's kind of the reality of of building a new product. Um and the kind of relates to the just being open to um to trying things without leaning fully in and kind of being open to change later on. Uh one of the cases we created these pawn spaces uh essentially just a filter of the assets slightly different interface slightly different colors for the interface for things like avagotis uh where we had organic traction it was like a very very trivial setup uh very

useful for just BD showcasing and so on uh I'm glad we did this uh and we also created this like robust um 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 thirdparty providers. Um we also have some useful smart contract tooling. So early on we decided to support all of the tokens and created u wrapper called the multi-token library which essentially wraps interfaces of ERC20721s and 1155s that end up ended up being very useful for just like building different toolings such as token bundlers uh 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. Um so again people could have created these like gaming bundles with um um wider um um wider class of assets in those and get better better terms. Um now, uh before I jump to the lessons learned, um is is someone who isn't familiar with the concept of Okam's razor?

Thank you for always raising your hand, man. You help. Um so, uh there are few few ways to look at this. So the the 101 kind of the definition that perplexity threw at me was okams razor is uh a phenomenon when faced with multiple explanation for uh uh for something and the simplest explanation is likely the correct one. Uh now when I was at at my university like our um um uh one of our teachers uh has been of classical logic has been pushing this concept of like logical outcomes razor which is kind of simplified definition as when you're trying to prove a theorem

uh and some arguments are necessary for the proving process just leave those arguments out um you don't need them they will just distract you um and now um I know it's it's kind of like bending uh bending the rule a bit. Uh but um I kind of like the the concept of UX orams razor um which is which is like a very simple simple idea of when an element in the 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 keep on using the the razor principle. uh when an element doesn't serve a unique purpose, um just kill it.

Like don't 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. And goes as far as like devs just randomly adding like three dots to a description somewhere. It's just uh it's just distracting. It doesn't have to be there. Uh but sometimes mentally it's like very hard for people to leave the unnecessary parts out. uh and continuously we're trying to apply this rule in in the product building flow. Um and it actually has some benefits like things get clearer clear clearer we we have like better feedback now with um uh while we user test these things um so uh before I jump into the conclusion like early on early on or it's actually part of a conclusion early

on I mentioned that pawn was built with this optionality principle um but then the whole talk was was actually about saying you should do less than more so saying like you should actually close these doors uh as you build. Um and I think it's like both true like it's it's true on the protocol level. I think that the fact that we had this huge optionality on the protocol level en enabled us to survive all of these like market hypes and market market cycles uh because we were able to simply pivot into a different market niche from NFT collectibles to gamefy uh to LP tokens as collateral uh to RWAS u the protocol supports it all from from day one uh and

it's and it's good because it cost a lot of money to audit on a protocol it cost a lot of money to develop and deploy deploy a new version. That's kind of the longest uh longest development cycle. Um but the optionality on the product and interface side is bad. That's where you should heavily apply the razor kind of with the and it's it's natural, right? But I kind of wish somebody has told me told me this uh a while ago because I still took the optionality principle as a as a way to go and we we created a lot of interfaces uh with the optionality.

Um although all of the UX designers were telling us well just keep things simple yada yada yada. Um so these two kind of go against each other u but we are in this unique space where oh you have to distinguish the protocols and the products built on on top of those protocols. Another lesson learned is that value very often especially in DeFi financial value uh means a lot more than values than kind of the things that people say they wish the the projects look like and so on like our our saying no to analytics tools uh and kind of being blind towards what we are actually building. Um and um yeah, I actually until now I I did not hear a single

negative feedback on us adding an analytics tool or or us kind of cutting corners somewhere and not having a fully decentralized front end so far. Um 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 uh you you kind of have to focus on the user itself. Um and um if you if you succeed and you actually create something sustainable then you can start thinking about decentralizing it and uh providing like multiple different front ends and so on. Um the cases where where you care too much and optimizing too much for values alignment early on uh you may as well fail and never actually live to the moment uh where people care enough uh about this

um kind of related overoptimization suboptimal. So if you overoptimize during the flow um it cost you resources but also motivation uh especially the developer motivation um uh because people just like lose track on uh having progress having momentum and I think like in this very competitive space having momentum is is super important. Um so if it if it works if something works like don't worry about it just leave it there. If it doesn't work just remove it and figure things out on the way. Um, and one last kind of lesson learned, um, especially when trying to build, uh, build a a new app, uh, with a complete like custom front end, um,

there's always the question of like, should we now optimize, should we refactor the codebase or should we just build this new feature? Um, I came to realize that refactoring, um, is kind of like therapy for developers. So if you're if you're working with the developer team, uh let them refactor at times like give them one sprint throughout the month where they can just focus on refactoring otherwise they're just going to go nuts and yeah my time is actually up and um if there's time for questions um this is it for me and happy to answer them. Thank you Ysef.

Any any questions? Any questions? All right.