For tomorrow’s leading dapps to utilize blockchain within their development stack, developers need the tools and information-access that they are used to having when developing for the web. dfuse is speaking with experienced blockchain developers to help share their journey, the tools they use, and the knowledge sources they turn to. This week we spoke with Britt Kim from Patreos.

Could you introduce yourself? 

I’m Britt Kim, founder of Patreos. You can usually find me online operating under the username “okayplanet”. I was born and raised in Louisiana and later transported to Arkansas, so I am a southerner—not only in origin but in heart. I spent my adolescent days in a small, unimposing town, but was lucky enough to get ahold of a computer and start programming. I made simple programs and simple websites.

It wasn’t until my final year in college that I started a serious project with a friend. That experience would lead us to having a profitable company, which was eventually acquired. We started the company around 2011, and if you were a programmer then, you likely heard of Bitcoin. It took me another year before I got interested in blockchain code, but I’ve been hooked ever since.

What is your vision for Patreos?

For years now, I’ve been hyped by crowdfunding and alternative financing tools for artists and entertainers. I have been on both sides of this budding industry, both as a creator and as a fan. As a heavy Patreon user, I started noticing issues with the platform in early 2018. I knew a content platform would be perfect for blockchain, but I wasn’t convinced blockchain was ripe for it. As an old Bitcoin and Ethereum developer myself, I was painfully aware of their limitations. EOS changed my mind. 

What are the main challenges when developing for blockchain? 

The main challenges concern pricing trade-offs around data storage. In every blockchain looms a storage drought—and sometimes a storage famine. The developer fears a day where it is too costly to insert data, or too costly to store data. In most cases, it is cheaper to store something in a local database than in blockchain state memory, and in extreme cases the latter is plain unaffordable. Programmers must develop with this in mind—if not today, then tomorrow. The difficulty comes from determining whether certain data should be stored in the blockchain state, derived manually from previous blocks, partially stored, or fully stored.

I’ve flipped on several implementations mid-project, and these design constraints are rarely encountered in early projects outside of the blockchain space. For instance, I recently had a token rewards contract that let users claim rewards every round, where each round was a data entry in memory. Well, what does that RAM look like after a year? After 5 years? After 10? As you can see, this could be a problem.

You might need some cleanup actions to shift a previous round’s balance to the current round, or you might simply say those rewards not claimed in the last “x” rounds are forfeited. The solutions are many, but the problem is singular and ever-present. Where and how to place data in a blockchain is an intuition you develop with experience—and mostly from the experience of being burned.

Will it be obvious to the Patreos users that they are interacting with a blockchain?

Yes, it will be obvious. But only initially. Once we have the core battle-tested, the goal is to abstract away from the chain and integrate with the best fiat on-ramps. For blockchain apps that are creating a marketplace, handling payments, executing subscriptions, etc., the hardest part continues to be how to gracefully get people onto the crypto rails. In my experience, no one has satisfactorily pulled this off yet. Everyone is still learning. Services are springing up to help with this friction point. Time is our friend here. Today is broken, but tomorrow is golden.

What advice would you give to a developer? 

It’s my nature to instantly feel unqualified when facing questions like this, so if you are harmed from the following advice, my bad. Read open source code from other developers. Message them about specific lines of code. Find them and bug them directly. Admittedly, some will not like it, but to hell with them.

Although I feel unqualified to mentor, I always love sharing what little I do know. And I have learned a lot from others that share my viewpoint. Learn to quickly spin up a local chain, have scripts to deploy your contracts, be able to rapidly develop and update those contracts. Write tests for your contracts. After you accomplish this, the rest are details that you will learn exponentially.

Keep in mind that your app rests in the blockchain but lives in the hands of the user. What I mean is that your smart contracts can do cool stuff; try not to impose too much of that geeky logic on the user.


If you are a developer working on EOSIO and want to share your experience, please feel free to reach out to us. We would love to integrate your interview into our interview series “In the Eyes of a Blockchain Developer.”