Welcome to Coruscant Technologies, home of the digital executive podcast. Do you work in emerging tech, working on something innovative, maybe an entrepreneur? Apply to be a guest at www.coruscant.com forward slash brand. Welcome to the digital executive. Today's guest is Jeff Mahoney. Jeff Mahoney is a serial entrepreneur investor and the founder and chief architect of WRIGHT, a purpose-built Layer 1 blockchain designed for institutional-grade performance and compliance. With more than two decades of experience leading innovation across fintech, data infrastructure and emerging technologies, Jeff Mahoney has founded and invested in over 30 companies spanning financial technology, digital identity and decentralized systems. For WRIGHT, Jeff built Save Daily, one of the earliest fintech platforms enabling micro-investing through white-labeled cloud-based solutions years before the concept became mainstream. His work consistently bridges traditional finance and cutting-edge technology, guided by a belief that complex systems should empower not burden their users. Well good afternoon Jeff, welcome to the show. I appreciate you having me, Ryan. Thank you. Absolutely, my friend. I appreciate it. And taking the time. I'm in LA, Los Angeles, California. I'm in Kansas City and we're just a couple hours apart. But again, I appreciate you making the calendars work. So Jeff, you founded and invested in more than 30 companies across fintech, digital identity and decentralized systems. What patterns have you seen that consistently separate successful innovation from hype-driven failure in emerging tech? That's a great question. I think what most people are doing is they're solving some future problem. They're not solving today's problem. They're looking to create behavioral changes rather than work in concert with existing behaviors. So when you see that, you know that it's mostly hype. Because the ones that see changing people's behaviors is tremendously difficult and incredibly cost inefficient. So when you're looking at solutions, particularly the way that I do, I'm trying to see if there's a real-world setting today that doesn't require the participants in that solution to change their behaviors. If it does, then I know it's mostly going to be high. There might be some abundance behind it that will increase that hype, but ultimately that solution will fail. So those are the main things that I'm looking for when I'm investing in different companies. I'm also looking for something that's coming out in sort of a narrow path. Does it look like it's actually going to solve a specific lane or is it trying to be a solution for all problems? What we find is there's always a series of solutions out there that are created usually by the under folks who have this grandiose vision about all the possible problems that they're going to solve at this instead of staying in one lane. And when you find a seasoned veteran, they're usually solving a singular problem. They're looking at something that has meaning to the concisorist that they're serving and trying to solve that particular problem, not at the symptom level, but at the core level. So the difference for me when I look at different companies to determine the height versus reality is those are the key factors. If you're trying to switch behaviors, it's a no go. If you're looking at too expansive, it's a no go. If you're trying to solve a future problem instead of today's problem, it's a no go. So there's a lot of different ways that we can evaluate those companies, but those are the primary ways that we're looking at it. Thank you. I appreciate that. It certainly helps. It really helps my audience here understand, but as you mentioned, I just highlighted a few things people tend to solve. Future problems versus today problems is more of a hype. And the other big thing that I took away is, as you know, it's hard to change people's behavior. So you look for real problems today that you're able to solve and maybe influence people's behavior. And there's, I would say I'm paraphrasing the difference between solving those hype problems or a real world problem today. So thank you. And Jeff Wright is positioned as a purpose-built layer one for institutional grade performance and compliance. What gaps did you see in existing blockchain infrastructure that made building a new layer one the one only viable path forward? Building a new layer one is required in my opinion simply because the existing blockchain world was more academic in nature than it was real world utility. So it's out to prove attack vectoring managing scalability when it comes to cryptocurrencies or tokenization as you'd like to refer to. None of those things actually work in a real world setting because they're academic in nature. They're not actually addressing what would be the requirements of the business sector that they'd ultimately have to serve. What are those requirements in general? Those requirements are speed. When you look at the Visa, Master and Card Network, you're looking at 2,700 transactions per second on a worldwide basis. When you look at most blockchains out there, whether it be Bitcoin or Ethereum, you're looking at 2,727 transactions a second. They don't operate nearly fast enough. You're looking into banking industry which would have to be an edge portion of any real world utility solution. You're looking at small M-Bakes, something that the blockchain world refers to as to determine finality in a record set. What is the current truth, if you will, on that blockchain as a distributed lender? Those existing layer ones like Bitcoin and Ethereum, they're M-Bakes or are too long You need something in the 100 millisecond range to satisfy banking operation. When you're looking at Bitcoin, you're looking at 10 minutes. If you are creating a real world utility around spending and you're sitting at a Walmart and you're trying to swipe your car that's attached to your Bitcoin blockchain, Walmart's not going to wait 10 minutes for finality on that. You have to have a much smaller app bit if you go for finality. You have footprint issues. You actually have heavy network traffic and heavy clients or nodes sitting on hardware out there. This is why you're looking at $20 million rigs that are actually the ones that are contributing to the Bitcoin consensus model as validators most often. You can't afford to have those types of machines out there. Most people have a machine at the phone level, something that might be a smartphone, doesn't have that kind of capacity nor bandwidth nor processing power. They are not real world solutions because it can't be run on real world hardware. Nobody's running $20 million rigs in their backyards. There's issues with that, not only does the footprint too big, processing power requirements of some of these consensus models are too large for real world utility. You have to change that significantly. Then you're looking at security issues, ranking and other types of edge processing is going to have a tremendous amount of regulatory issues that they need to comply with. If you're looking at a layer-one chain that isn't built from the ground up to comply with those same regulations, you're going to have some very serious challenges later. You're not going to be able to pass their security protocols. It's not just pen testing. It's not just making sure that your smart contracts are working, it has to work in their entire compliance chain. If we don't have any blockchains out there that have been built from the ground up specifically to manage the regulatory environments. The security tends to be an afterthought. Once they get greased, then they'll start to add layers on them for security purposes. Building on security is never ultimately the proper full-size solution or approach. You should be building that from the ground up inside of your actual designs. It should be an initial part of your architecture, not a secondary part of an afterthought. You have a variety of blockchains out there that have made some very serious promises. You have those that are even promising governmental level deployments, but how come they haven't? The reason is because every time a government actually does a deep dive into those existing blockchains, they find that, sure, you'll pass some basic pen testing, but you're not actually designed for the ground up to manage what would be a real-world setting. You're not managed or built from the ground up to actually manage what would be the true attack vectors that are coming from what might be other governmental agencies from around the world that might have heavy resources available to them. This isn't somebody in their dorm room that they're trying to ensure isn't attacking. Their system, they're looking at other governments who have almost unlimited resources, who can mount surprisingly large attack vectors. This is something that they are looking at. Then you'll see most of those blockchains fall by the race side. We had them build something from the ground with our 40 years of experience in the banking industry and in work at the government side to say there's a certain number of requirements here that just are musts and are currently being missed by all existing blockchains. Thank you. Really appreciate that. Just to highlight some things, again, Jeff, you knew Layer 1 was required a whole change because what you saw was more theory or academic, not real-world. You knew that infrastructure would need to be reliable with high throughput as you talked about. A few examples are transactions need to be in the within milliseconds. Also, platform needs to run on real-world infrastructure hardware that you talked about. Of course, compliance and security are key. They're critical. These must be built in from the ground up as you mentioned. I appreciate that. Jeff, many blockchains claim scalability and security. But few deliver both at institutional levels. What technical breakthroughs or design decisions with right enable high throughput without compromising trust? That's a great question. It's very difficult to actually manage those in parallel. We've managed to do it, though, through redesign. Some of the things that are important in there is to get rid of the gas auction. All blockchains right now, particularly those that are value-driven, will process transactions based on an auction. Essentially, who has the most fees or gas attached to a transaction? That's the one that we're going to handle first. That does end more in a governmental setting. I need to know that all transactions are being managed. They're being managed in order, and they're being managed across the distributed ledger in that manner. When you create an environment where you have a single entity or node at any given moment, which is what a proof of work or a proof of stay consensus model dictates, then you create a built-in bias to what transactions should be processed. That will immediately disrupt trust because I am not sure as an operator or a user of that system that my transactions guarantee to be processed in order. We have to change that as a fundamental piece. We did do that. You have to have native zero-none support within your protocols. Whilst blockchains fail to manage the overwhelming amount of data that they will ultimately create in that block chain, that chain of blocks. We have to be able to manage that. Mechanisms for managing that don't include reading the entire chain every time. That's the indexing model. There has to be a mechanism for zero-knowledge proof to determine that the information that you're getting is true and accurate without having to go through an entire history of a block chain. New mechanisms had to be designed to actually support that. We use those words as part of our normal nomenclature. Most blockchains, if any, are actually delivering on those types of indexers and zero-knowledge base proofs to actually get through what would be an overwhelming amount of data. We're also doing something truly parallel. We're actually getting multi-state execution. This would have got an execution in guys as parallelism. A way that is truly round in multiple lanes. The way that we're doing that is each node in our network actually participates. We call our consensus model proof of majority, not proof of work and not proof of stake, not where a node is selected because they could do the most work or because they put up the most capital. But instead, a truly democratic solution where all nodes are participating in defining what is the true state of the block chain. The effect of that is that all nodes are actually at any given time participating in parallel. True parallelism is what we need for multi-state execution to occur. This is where you get that speed. You already have a tech factor management. You have an understanding that transactions are being processed properly and you know that you don't have to manage the entirety of a block chain data set all at once. You have speed, that parallelism, and that voting solution will give you the trust part of this. Now, as an operator with a layer on top of our block chain, the right block chain, you can have both. You can have the speed of parallelism. You can have the understanding that multiple sources are validating the truth, not a single source at any given moment. And you can have the comfort that you will have not to deal with the entirety of a block chain's data set. Those are important things at a government level. They're important things to the banking industry or any seriously regulated industry. We need to know with certainty that transactions are being processed, that they are actually immutable, that the truth is not being compromised because I have multiple parallel lanes determining that truth and coming up with a consensus, which is the word that we use, instead of proof of stake or proof of war, which is not a consensus. That's a misnomer. You have a single node in a network creating that. A proof of majority consensus is a true consensus. It is the entirety of the network determining what is the true state of that block chain and thus in the light data set. We can affect high throughput, but create confidence that everything that we think is happening is actually happening. That's where you get both of those pieces in a governmental or institutional deployment. Thank you. Just to highlight something I think it's pretty neat how you impacted all that, but the two things sent around the question was managing scalability and security, which is very hard to do, but you were able to do that with your design. And some other things you talked about, that guarantee processing transactions and the order they received, zero knowledge truth. What's really interesting is that proof of work, proof of stake, which we all familiar with, you talked about proof of majority, which in your words is really the true state or consensus on the blockchain, which I thought was interesting. So thank you for sharing. And Jeff, last question of the day, if you could briefly share looking ahead, what does the future of compliant enterprise grade blockchain infrastructure look like? How will it reshape digital services, global markets, and the role of digital identity in the next decade? Well, that's a kind of a loaded question, right? You're asking us to look 10 years into this future. I would say that you're going to see blocks of changes, right? We're going to start to see a set of pilots that have been embraced at the governmental level, move into actual production. That's going to take a few years in and of itself. You're going to find citizen-wide deployments across an entire country. Remember when you're talking about countries, you're talking about millions or billions of people. And I'm talking about a few hundred thousand users coming on to some kind of a dating app or something along those lines. We're talking about real-world, very large-scale deployments. It's going to take time to move from pilot to production. I think that'll be sort of phase one. Then you're going to need to see a crossing in the regulatory issues, some kind of melding of those regulatory clients frameworks from country to country. Right now, the biggest challenge that I think we're going to face that nobody's really talking about is they're going to have a blockchain requirements that differ from country to country. And what are you going to do with your blockchain that is cross-border employed, that's actually deployed in multiple borders with completely different regulatory frameworks? How will that be addressed? And that's something that's going to come next. After we go from pilot to production, we're going to figure out ways that are going to create cross-border compliance, not just cross-border usage. And that's something huge that's going to require something outside of a technology addressing. It's going to require us to address governments at the policy level. That's something where you're going to need some bigger routes to come in and lobby and make those changes. That's going to be a nest. That's going to be a requirement. It's going to have to happen. But it's a big task a little happen later. Then I think that's going to be true interoperability. I've already had this semblance of interoperability because we're creating bridges and we are basically saying, okay, here's how I convert back to why. And that is what we're facially calling in bridge in our technology space. The bridges are where your own rule. If I were hacking a system, I wait for you to put value onto a bridge and then I would corrupt that value before I got to the next chain. So moving value from one chain to another interoperability is something that it doesn't actually happen today. It's a bridge that's making that and affecting that. We see that as interoperability, but that's not true interoperability. So we're going to need to see that happen where we actually have protocols that can scheme or free without the use of a bridge where they can actually manage what would be attack vectors because that's a scene. That's the place to arrive and attack a fighter. And we're going to have to see smart contracts and another virtual machine. If you wrote the interoperable is going to have to be a common language. So that I know that if I have a contract on this chain, if I were to move it to another chain, it will operate there. So true interoperability, not just for transfer of value or data, but also smart contracting out of these virtual machine. That makes sense. Yeah, that's great. I love that. And I love to get again, usually my last question on the podcast is to ask the guests what their insights or their crystal ball is. I thought it was really interesting, but you know, these you talk about the next few years will be changes or pilots that will actually move into production later on several years down the road. But production will be very large, very, very scalable. Obviously you talk about real deployment of millions of people in terms of entire countries. And then you got to manage that cross-border compliance, right? And security. But in the end, the goal is to have that true interoperability where smart contracts can work on the various networks. So I appreciate that. And Jeff, it was such a pleasure having you on today. And I look forward to speaking with you real soon. Me too, Brian. I hope that I'll hear sooner rather than later. Bye for now.
