Ishan Pandey: Hi Piers. Welcome to our series “Behind the Startup.” Please tell us about your background and the inspiration behind ? Radix Piers Ridyard: My journey to becoming CEO of RDX Works, the core software company building the Radix protocol today, has been diverse. My academic career spans aerospace engineering, business and Chinese, through to chartered finance and legal qualifications. Professionally, I worked in investment banking and law, then founded my own electronics manufacturing company. I draw upon this spectrum of experiences in my role as CEO every single day. My journey into crypto started when a friend encouraged me to mine the genesis block of Ethereum. That led me down the path of founding a decentralized deal-room startup for the insurance industry, taking that through YCombinator, and ultimately acquired by RDX Works. : Vested Interest Disclosure The author is an independent contributor publishing via our . Be it through direct compensation, media partnerships, or networking. The author has a vested interest in the company/ies mentioned in this story. HackerNoon has reviewed the story for quality, but the claims hereon belong to the author. #DYOR brand-as-author program So, what’s the inspiration behind Radix? It’s not uncommon in crypto to hear about people’s “lightbulb moment”, which is when someone first truly understands the far-reaching implications of Bitcoin and blockchain on finance and the internet. Our founder, Dan Hughes, had his revelation in 2012. It hit so hard that he pivoted from playing a key role in building the UK’s critical telecommunications infrastructure and NFC card payment standards to focusing full time on what it would take to make the Bitcoin vision a reality. And that is the Radix origin story. Unwavering 10-year pursuit of what it would take to decentralize the entire global financial system. The journey hasn’t been easy. Our no-compromise approach has meant multiple rounds of throwing away sometimes years of work as we realized a certain path wasn’t up to the task. The project almost died not once but twice. But we persevered. That’s what real R&D looks like. And now we’re confident - nay, absolutely sure - that we have the full stack of technologies in place to propel DeFi through its upcoming hypergrowth stage of adoption. We’re now in total execution mode with all hands-on deck building our “Babylon” release for Q1 2023, which brings an entirely novel approach to tokens and smart contracts that we think will be a game-changer for the industry. Ishan Pandey: What are the major challenges for Web3 adoption currently and how does Radix address scalability issues face by blockchain applications Piers Ridyard: If your vision is to decentralize the $400 trillion of global finance, you’ve got to take a very methodical approach to product development. Over the course of the last three years, we have spoken to almost 1,000 Web3 developers, around 5% of the global total. This taught us that contrary to popular belief. The biggest challenge developers are facing is not scalability. It’s the developer experience and it truly sucks. Why? It’s probably best explained through analogy. Building a DeFi or Web3 smart contract today is kind of like building a spreadsheet. To create a token, you build a table that records who has what balances. To add functionality and logic, you build rules that say when those balances can change. Ethereum and nearly all other smart contract platforms look like thousands of these spreadsheets sending messages to one another - updating their balances as they go. While this model is incredibly flexible, it also means that every developer is building what amounts to their own custom spreadsheet from scratch - entirely responsible for ensuring that every piece of logic and all the tokens within are secure. If you stop to think about it, this is madness. The slightest mistake can result in millions of dollars lost. This is why we‘ve seen over $3 billion (yes, that’s with a B) lost to hacks in DeFi over the last two years. And this is why when we surveyed those 1,000 developers, they said they spend up to 90% of their time on securing their code, and only 10% actually build anything useful. DeFi today is a cottage industry with every developer improvising their own logic of assets and tokens in their own custom smart contracts. DeFi needs its industrial revolution, and that means it needs an engine. That’s precisely what we’ve built—the world’s first programmable DeFi Engine, Radix Engine. Instead of developers coding up the logic of tokens and assets - from nothing - inside their smart contracts, on Radix, the engine does it for you. The engine gives developers the full suite of tools to guarantee secure custody and sending of assets. Just as game engines took the burden of physics and graphics away from game developers, Radix Engine does the equivalent for DeFi. Developers can now focus almost entirely on features and functionality, freeing up 90% of the time they currently squander. From a user perspective, this should finally put an end to so many of the hacks that have plagued the industry. If you’re curious to learn how we’ve got an entire content series called Rekt Retweet that goes into depth on how various DeFi hacks would have been stopped if the dApp was on Radix. On the scalability front, we know it’s important. It’s what we spent most of 2013 to 2020 researching; culminating in our groundbreaking Cerberus consensus algorithm, which does away with the notion of a blockchain, and allows Radix to scale like no other network. But there’s no point in having a scalable network before you have a useful one, which is why we’re so focused on delivering Babylon right now. If you are curious and want to dive into the detail of how Cerberus works, you can check out our Whitepaper or Infographic Series. Ishan Pandey: What is asset-oriented programming and how does it solve the problem faced by Defi? Piers Ridyard: Before asset-oriented programming, as explained above, tokens were just lists of accounts and balances created from scratch by developers inside their smart contracts. Programming languages like Solidity do not know what a token is. They have no features to help developers with tokens. They’re not asset-oriented. After asset-oriented programming, the language knows what a token is. Assets are a native first-class feature. If you’re developing in Scrypto, Radix’s programming language, you’ll see first-hand how easy and intuitive this makes Web3 and DeFi development. Creating a token is as easy as saying “create me a token with a supply of 1,000, divisible by 18 digits, and put the starting supply in this vault here”. The equivalent in a legacy programming language means coding all of the above yourself from the ground up. Below is a simple comparison. https://twitter.com/0xOmarA/status/1558194543253721094 On the left, we have the example code for creating a token in the Near blockchain’s implementation of Rust. With comments, it runs to 191 lines. On the right, Scrypto, with only 16 lines of code. You’re no longer building all token logic yourself, you just specify the parameters you want and Scrypto does it for you. We think this is incredibly powerful and also really exciting if you’re a developer looking to get into Web3 and DeFi. The feedback from our burgeoning developer community has been nothing short of incredible. Ishan Pandey: What is the fundamental and technical difference between Radix and Ethereum? Piers Ridyard: Let’s start with Ethereum. You can think of Ethereum as a platform, and on top of that platform sit the thousands and thousands of smart contracts (like spreadsheets) that make up DeFi today. Each has its own list of accounts and balances (tokens), and each sends and receives messages to users and one another in order to update those balances. For Radix’s Babylon mainnet, you can also think of it as a platform with smart contracts on top of it. But instead of these contracts sending messages to one another and updating their internal lists of balances, the Radix platform has an entirely new layer - you can think of it like a shuttle service - that ferries the actual “physical” assets between the contracts. The shuttle service provides guarantees that the assets can’t be lost or stolen during transit. That shuttle service is Radix Engine. Scrypto is the programming language used to build logic that interacts with it. And this is what we mean by asset-oriented programming and the world’s first programmable DeFi Engine. Then for our Xi’an mainnet (to be specified after Babylon launch), we take that single Radix platform and carve it into many small islands. We shard the network. But the beauty of Radix’s consensus algorithm Cerberus is that it allows multiple shuttles to ferry many assets to/from multiple islands simultaneously. In technical terms, this means that the Radix network will be able to scale linearly - adding more computers increases throughput and because the shuttle services can traverse islands, transactions on Radix retain an all-important property of DeFi - atomic composability. So what is atomic composability? Atomic composability is to software as compounding interest is to finance, as they say. It’s the property that ensures that each and every  step of a transaction has to succeed, or the entire transaction fails safely; allowing users to compose complex multi-application transactions with the full confidence that every step will complete or else the whole transaction rolls back and the user is protected. For example, the risk associated with an arbitrage opportunity is much higher without atomic composability. After all, you don’t want to be stuck with a token you don’t want, which is what can happen in DeFi today. But wait, as they say, there’s more. With atomic composability, any arbitrary number of dApps can be seamlessly combined to form products and services that behave as if they were a single fully integrated application. DeFi’s massive edge in capital efficiency as compared to traditional finance is borne from atomic composability. And every single other blockchain and crypto sharding solutions, at least that we’re aware of, break it. Ishan Pandey: According to you, how can cybersecurity issues related to smart contracts be minimized? Piers Ridyard: This is a great question. Ultimately the cybersecurity of smart contracts is something that will always be the responsibility of the developer and project teams. If a developer rushes to market and builds a sloppy application that could be prone to a hack, no one is stopping them from doing so. DeFi is permission-minimized. No platform can protect a project team from social engineering or other threats. However, what we can do is give builders the tools that make their developer experience far easier, safer, and more intuitive. If you can cut through complexity, you lessen the risk that something goes wrong. Some of the fundamental solutions we are giving developers include: ●	Radix’s smart contracts start life as template “Blueprints” that are then instantiated into live “Components”. This will make the process of copying and forking others’ code on-ledger, automated and safer. ●	Scrypto and Radix Engine’s native asset-oriented features abstract the complexity of tokens away from the developer, meaning there’s far less to go wrong. ●	Radix’s native form of authorization, “Badges” (like physical NFTs to prove authority), will make programming complex authentication and authorization models far more intuitive and simple than today. The problem of DeFi hacks won’t go away entirely. But you can bet we are providing the best tools to Web3 and DeFi project teams to mitigate the risk of smart contract hack, exploit and failure. Ishan Pandey: What are your views on regulating DeFi? Should DeFi startups comply with AML, KYC and Sanctions regulations? Piers Ridyard: We take the view that DeFi and traditional finance will be complementary financial systems that operate in parallel with one another. There will be a need and place for each, depending on the user, use case, and context. We think that over time, DeFi’s share of the market will eventually eclipse that of traditional finance, as its inherent advantages of financial efficiency, openness, and innovation will ultimately draw the most capital and users. But for the largest banks and pension funds to be comfortable putting significant sums into DeFi platforms, they must be certain that they are entirely compliant with the law. So how do we balance the need for trust and permission-minimization on the one hand so that DeFi can continue to be truly open and innovative against the compliance needs of most of the finance? The answer is that you provide the tools for regulated entities to be able to be fully compliant, allowing them to build their own permissioned apps and liquidity pools on top of public decentralized ledgers yet still accrue the benefits of security, programmability, and instant settlement that public ledgers bring. This is why we are building Instapass, a one-stop compliance service for users and developers of the Radix network. Entirely opt-in will allow DeFi developers to draw upon a common resource to meet their KYC and compliance needs without having to rebuild their own compliance stack from nothing. Ishan Pandey: Can you provide your views on the recent Celsius multibillion-dollar collapse and its effect on the future of the crypto market? Piers Ridyard: There is a great irony to some of the reporting on “DeFi’s” recent market turmoil, with some proclaiming that DeFi has an existential problem. The irony stems from the fact that despite seeing asset prices drop 50-90%, DeFi (for the most part) has ticked away like clockwork, without a hitch. It’s not DeFi that’s failed. Overcollateralized lending dApps such as Compound, Maker, and Aave continue to liquidate positions. DEXs such as Uniswap or SushiSwap continue to process swaps. Oracles such as Chainlink continue to publish data on the ledger. These protocols were designed to be overcollateralized and trust-minimized; automated machines do their job no matter the market conditions. Contrast this to the suite of centralized crypto institutions that were engaging in undercollateralized lending and leveraged borrowing and consequently faced contagion and cascade liquidations when faced with default. These players are not DeFi. In the future, there will, of course, be a need for centralized institutions that interface with DeFi infrastructure. Not everyone wants to have the responsibility of managing their own private key. Centralized institutions still have a massively important role to play in DeFi’s march to mainstream adoption. But if an organization faces the same risks, it should be subject to the same regulation. The regulatory perimeter needs to encompass these types of institutions just as banks are today, with the same regulatory oversight and guarantees around deposit and other consumer protections. Don’t forget to like and share the story!

Chainlink

Uniswap

Aave

Maker

Scaling Blockchain and DeFi with Piers Ridyard

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

$2M Backing and a Vision: How GAM3S.GG is Reshaping Web3 Gaming

06/09/2018: Biggest Stories in the Cryptosphere

07/09/2018: Biggest Stories in the Cryptosphere

0x Protocol, Waves, and EtherDelta: Solutions and Limitations of Distrust

03/09/2018: Biggest Stories in the Cryptosphere

$2M Backing and a Vision: How GAM3S.GG is Reshaping Web3 Gaming

06/09/2018: Biggest Stories in the Cryptosphere

07/09/2018: Biggest Stories in the Cryptosphere

0x Protocol, Waves, and EtherDelta: Solutions and Limitations of Distrust

03/09/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps