Hello everyone, nice to be here in New York. I hope, I hope, the Knicks win today. If so, New York will become even more energetic and exciting than usual. Well, if not, good luck to you today in Manhattan. Today I will talk about creating a data layer for the institutional era of Ethereum.
How we provide data for smart contracts— whether from off-chain institutional portfolios or secure on-chain secure on-chain events. Space and Time is an on-chain database for smart contracts that allows you to make complex queries. When we started building Space and Time in late 2021, we aimed to develop the first verified SQL database with ZKP proofs. This means only zero- disclosure proofs, cryptographic confirmations for on-chain requests sent by smart contracts. Initially, the idea was this: the on-chain lender knows nothing about the borrower's wallet.
Why not let the loan smart contract ask a simple question: how much credit has this borrower already repaid? It’s striking that DeFi repaid? It’s striking that DeFi protocols and decentralized applications know almost nothing about wallets know almost nothing about wallets that interact with smart contracts, is n’t it? Smart contracts do not have a database. They cannot query past activity and aggregate information.
Space and Time solves this. We provide an on-chain database that allows smart contracts to query information about wallets that have connected and are making transactions. They can summarize and aggregate the history of transactions, events—everything that has happened on the network before, and we can quickly confirm that to a smart contract. Next block. This creates a kind of verified data pipeline for smart contracts.
Think back to the era of oracles and price feeds that kicked off the DeFi summer of 2020 by essentially providing smart contracts with some price data. They can make better decisions. Take it a step further and allow the smart contract to execute SQL queries with aggregation. This is what Space and Time offers. This will become an extremely important and powerful tool for institutions coming on-chain, especially in the lending and storage space in the future.
So, Space and Time as a technology is a decentralized database that works alongside the EVM. It works alongside Ethereum, Base, etc. Essentially, it is a blockchain that allows you to create tables, add data, and run queries. This is a blockchain that allows for SQL database-style operations. You spend your SXT token—a few tokens per action.
For example, I spend some SXT to create a table called " table called " treasury bill volumes". And then I spend SXT to enter my treasury bill portfolio data, and I spend SXT to request a smart SXT to request a smart contract to issue stablecoins backed by my over-the-counter bills, as an example bills, as an example . We've seen this continuously this year, and with the passage of the Clarity Act, banks have started to get more involved more involved . Last year, it was led by fintech led by fintech companies. Um, Stripe, PayPal, etc.
Circle to some extent with ARC. Fintechs came into this space came into this space , started issuing their own stablecoins backed by their cash reserves, and showed the big banks how to do it. And now large banks are starting to hire contractors to write smart write smart contracts, deploy them on large networks, and wait for the law to be passed. But we will see a massive influx of big banks that want to tokenize and capitalize on all these securities that they have outside the blockchain. Think about all these portfolios of stablecoins, cash reserves, treasury bills that they want to issue as a stablecoin.
Sorry. Also, the benefit of moving this capital to blockchain, as you all know, is programmable finance programmable finance , not just 24/7 liquidity or access to a broader market. globally, namely programmable finance. So banks are realizing: oh my god, if we can take our cash reserves from this over-the-counter portfolio and move them into a smart contract, issue something like a stablecoin for our bank, sell it to a wider audience. But we have this smart contract where we can program the business logic.
We can codify rules for how this token is traded, you know, thresholds for volumes that we can sell. Make sure it always matches and corresponds to the market value of our over-the-counter portfolio. This opens up a whole new world of programmable finance where we can go far beyond stablecoins and start codifying rules for secured credit obligations, over-the-counter stocks, commercial real estate to some extent, right? These old traditional processes of revaluing at market value or, say, monthly, can now be programmed to revalue as often as you wish using SQL via Space and Time on Ethereum or other EVM networks. So let's think about all this data about securities in traditional portfolios, stored in traditional transactional databases on cloud hypervisors run by big banks.
Think about where all their treasury and bond positions are held. Think about where bank balances are stored, where CLOs are compiled into a PDF file each month, valued, and sold on the market. And we're thinking about how we can move this to the blockchain. Well, you need a kind of mediator who stands in the middle. You need a middleman between these, you know, very strict off-chain portfolios that meet regulatory requirements, and on-chain contracts where the securities are tokenized and sold in a broader liquid market.
The intermediary should be a solution that securely accesses banks' off-chain accesses banks' off-chain portfolios and, using ZK-proofs, confirms to the smart confirms to the smart contract the accuracy of the transmitted data, as well as the correctness of the execution of queries and aggregations for business aggregations for business logic, ensuring that they have not been changed by bank engineers, external hackers, or anyone else. So what we are offering in Space and Time is not just a key underlying technology for the future of Ethereum that allows institutions to query, aggregate data, and ask questions about market changes via a smart contract, but more importantly, securely connect off-chain connect off-chain data, and we are not talking about price streams right now. We are not talking about oracles for price streams. We are talking about queries executed against a number of portfolios. For example, my bank has bonds, there is a treasury with treasury bills.
They are in 17 different portfolios in two different clouds, different databases from different bank teams that developed these systems, and I want to combine this into one stablecoin that I issue for my bank. You need to ask a question. Aggregation is required to collect all this data. What is our total volume? What is our overall available provision?
How much collateral do we have off-chain that we can withdraw on-chain and sell right now? And we have to be sure that these numbers match. I need to be sure that I don't issue more stablecoins than I have cash reserves to back them . And it can't be a monthly report. This cannot be work that accounting or interns do once a month.
It has to happen in real time, or, you know, every few minutes, or every few hours at worst. So we access these transactional databases and allow the smart allow the smart contract to query: “What is the total volume or what is my total collateral volume in these 17 portfolios?” Space and Time passes this to a smart and Time passes this to a smart contract where stablecoins are minted, and the business logic can ensure that the collateral matches what is issued and sold. Now let's move on. Banks understand that stablecoins are a great start.
Perfectly. Let's take the next step. We have all these other assets and securities that we want to move on-chain. portfolios of stocks, bonds, loans, credit obligations and CDPs. So, what we're talking about now is first taking the business logic for these securities, reducing it to SQL, and then letting a smart contract execute that SQL.
This is an important tool that every engineer in every financial institution already works with confidently and is well familiar with. They already use SQL for all their processes, and when they come to blockchain, they say, "Wow, we can't do this on-chain without space and time." Okay, great. Well, now we have a solution. Without this, you have no way to perform historical aggregation.
So think about it. Not only do you not know the wallet that interacts with your smart contract, what that wallet has been doing on the network, its volumes, the events it has generated, or its history, you also cannot do historical aggregations of your own data from your own smart own smart contract. For example, something simple like showing the total volume of a particular RWA, showing all its outflows from that contract over the last seven days. A very simple business question that any business analyst at any bank would want to ask. You really can't do this on-chain without a network-verifiable SQL database with a ZK proof that provides the smart contract with confidence that the question was answered accurately .
There is no origin of assets, right? I can't say, "Hey, show me the total amount of loans that this particular wallet has already repaid so I can offer them a better interest rate." And you can't derive any business metrics. You know, I can't say, "Hey, if I sell a certain amount of this stablecoin over a 24- hour limit, stop the sales and check the collateral." These very simple rules that we want to add to the smart contract cannot be implemented without an on-chain database capable of executing simple SQL queries—either based on completely on-chain data, as in the historical aggregation example, or based on completely off-chain data, such as the total amount of monetary reserves.
Now let's take another step forward. Right now in institutional lending, especially in the EVM world, everyone is talking about vaults: everyone is creating them, everyone is managing them, and borrowers are coming in and starting to take out larger and larger amounts. However, we will not see large financial institutions, particularly banks, come in and bring, for example, $80 million in capital in Treasury bills into storage without understanding what the borrowers already have as collateral and how they are going to use those funds after receiving the loan. So, there has to be a data room. There needs to be much more transparency for the lender about what borrowers have online today and how they intend to use those funds after borrowing.
Now, despite all the talk about transparency, audience, and verifiability of storage smart contracts, we actually live in an opaque world of Ethereum storage. For example, lenders really have no idea who the borrowers are, what their capital base is, and what collateral they have available. It's just, you know, PDFs sent via email and then approvals are done online. Let's take it a step further by using this powerful new primitive with space and time. What we call virtual vaults is when you create your own vault at your discretion on the banking platform of your choice.
We don't really care, but we'll show you as much data as possible about who these borrowers are, how much capital they've already invested in market invested in market making on centralized exchanges, on DEX exchanges, in, you know, complex DeFi you know, complex DeFi strategies, cyclical lending on the network. So, we provide lenders with an overview of what a borrower's capital looks like, taking into account the capital placed on centralized exchanges and DEX exchanges and DEX platforms. And this gives the borrower more options, more lenders willing to provide them with funds, and of course, the lender a lot more confidence before they put larger amounts of cash, USDC, and USDT into storage. It's time to update the world of online lending. And I'm not talking about overcollateralized lending through Aave.
I'm talking about vaults that are generally completely unsecured. So we need to, at a minimum, show this collateral. So, we start, for example, with an investor panel. We start with something like a data room that we provide to lenders, where it says: this is what the borrower's world looks like. That's all their available collateral.
Here are all the deals they make. This is how they are going to use your money after the loan. And then, of course, continue to do so during the loan itself. But let's take it one step further. What if we could provide this same data to the storage contract itself?
So, I'm talking about a talking about a storage smart contract programmed to execute SQL queries that ask simple questions, like: how much collateral does this borrower have left right now? And if the borrower exceeds the collateral threshold, let's say, make what is essentially a margin call. Essentially, take your deposit, return your funds. Um, codify more complex business more complex business rules in these repositories, make them a little smarter, give them the ability to ask questions about the borrower before, during, and after the loan is made. So you can start building much more compliant offchain repositories that adhere to your risk management and compliance rules that you are already used to codifying offchain using this powerful new primitive.
Let's look at this from start to finish on the left or on your left side. Yes. You have all these exchanges where, for example, a borrower who is a market maker gives out money. They are doing market are doing market making on Binance, Coinbase, and five other exchanges where they have $40 million in the market that they don't really want to touch. This is active touch.
This is active . It's traded, and they need, they need additional capital. They want to borrow another 40 million. First, they prove to the lender that they are using this money wisely, showing their capital base, and, hey, in the worst case scenario, we could withdraw the money from these deals and repay the loan if we had to loan if we had to . This gives the lender much more confidence.
The lender then deposits 40 million USDT into an Ethereum vault. They choose a borrower, approve them, and the money starts to be issued on-chain. And now their smart now their smart contract can manage continuous redemption. They can stop further lending. They can return anything they want, right on the blockchain.
This can codify those business rules, which is an incredible change in how we think about repositories like Morpho, for example, which are really quite generic, very black and generic, very black and white in what you can do. We have already talked a lot about institutions. We talked about how banks are coming to blockchain, bringing stablecoins, even more exotic securities and assets that they are starting to tokenize with these powerful tools that every developer is already familiar with, but don't have them on blockchain without Space and Time. What about DeFi itself? So, back to my example of traditional lending on the blockchain.
I'm going to use Aave, take, well, I'm borrowing against my ETH collateral. Smart contracts have no idea who I am, what wallet I have, how much credit I have already repaid, and everyone gets roughly the same interest rate, right? I get the same rate as someone who takes out a loan for the first time, even though I am a very experienced borrower and have paid off a bunch of loans online. Something as simple as asking, "What is the total amount of loans that Scott's wallet has already repaid?" this question would allow the lender to offer me a better rate for my loyalty.
Offer a better rate because I am a lower- risk borrower. The kinds of questions we want to ask smart want to ask smart contracts could fuel a new wave of DeFi in Ethereum that we are very excited about. I think next year, with the passage of the Transparency Act, a lot of banks will come in and we will see a massive development of DeFi as people get more creative and build more interesting credit markets around it. Consider space and time as the underlying technology we brought to Ethereum, but we provide these important use cases for wealth management wealth management . Thank you all for your time today, and I hope the Knicks win today.
Take care of yourself.
Automatic transcript — names and jargon may be misspelled.