In part 2 of Building Stellar Core, Jon Jove guides us deep into the weeds of Core Advancement Proposal #23 (CAP-0023). Learn with me as we take a careful look at the construction of a specific CAP and the many phases of thought, review and consideration a CAP must go through before making it into an official protocol release.
Jon Jove (00:00):
... Tyler logs into his wallet and his wallet is just like, "Hey, do you want to convert this into a trust line?" "Yes." "Hey, do you want to receive this free money?" "Yes." "Done. Awesome."
Tyler van der Hoeven (00:22):
What is up Stellar community. Welcome back to episode 15 of the Stellar podcast, part two of a two part series with Jon Jove talking about CAPs core development, and specifically in this episode CAP 23. The impetus reason behind it, the design of it, and what makes it a useful and exciting CAP to look forward to whenever it makes it into a final state. This CAP is still under active development, so don't consider anything here to be a promise of functionality, but more just a discussion on how the CAP process works in a specific CAP.
Tyler van der Hoeven (00:59):
I really enjoyed this episode. It was a lot of education for me as someone who doesn't spend a whole lot of time in core or the CAP flow. So, I hope it's just as educational for you as it was for me. Fair warning, it is long, but rather than trying to figure out which pieces were the most important, I decided to share the whole thing. So, I hope you'll stick it out, and get as much out of it as I did. So, let's talk about CAP 23, maybe just what's the purpose, what's the design behind it, and then what's the intended implementation?
Jon Jove (01:33):
Yeah, so as I mentioned earlier ... And I'll warn you that it's not fully specified, we're still working out some details. So, CAP 23 started from this question of like, maybe we should be able to add trust lines to other people's accounts. And if you're curious, I can tell you more about why I don't think this is a good idea at all.
Tyler van der Hoeven (01:55):
I would love to know, first of all, so, it's massively confusing already. We just did this hackathon in New York, and like we talk about assets all the time. And you can create your own asset on Stellar. There are no assets in Stellar, like there are trust lines in Stellar. And trust lines equate to the idea of an asset that you can pass back and forth. But the idea, the concept itself of a trust line is confusing. So, maybe talk a little bit about what a trust line is first. And when somebody actually goes, and they say, "I'm issuing an asset." You don't issue an asset, somebody trusts you for the asset before they can issue it to you.
Tyler van der Hoeven (02:31):
Like there's this whole web of complexity around assumptions that are already made around how assets are issues, and that an asset is like a coin, and I should just be able to hand that coin to you, and you accept it. But that whole concept is reversed here because of the security issues that are involved in just giving someone assets. So, maybe talk a little bit about the design around that, and how it's different from what people assume asset issuance should be, or even assume it is, and then realize that it's not in the confusion that revolves, or naturally comes from that.
Jon Jove (03:04):
Sure. So, let's start from the most fundamental aspect of why trust lines? And then let's build up more about, "Well, okay, I see why but why?" So, the fundamental why is an account on the Stellar network stores a balance, but just one. And it's a lumen balance, a native asset balance, I would say, in more general terms. That's the only balance you have if you have just an account. But if you're an EU citizen, you might have some balance in euros, and you might have some balance in British pounds, and you might have some balance in US dollars. And maybe you travel frequently to Nigeria, and you have some balance in Naira too. Where do you put all that stuff on the ledger? So, that's the first thing that trust lines solve.
Jon Jove (04:00):
A trust line is a place to put this information where you can pay or reserve for it because you're storing something on the blockchain, and then we can hash it into the ledger so that we can make sure it's right. So, at its most fundamental level, a trust line is a place where we can store a balance, but that's not all that a trust line is. A trust line has some other stuff associated with it. You might have noticed that there's a limit on a trust line. Why is there a limit on a trust line? You might think, "Well, if I'm happy to hold two dollars, I'd be happier to have three dollars, wouldn't I?" And in general, this is true, but it's not strictly true.
Jon Jove (04:38):
And there are some reasons this is not strictly true. One reason is you might not think that the person who is issuing this asset is that trustworthy. And if that's the case, you probably don't want to hold all your wealth in terms of their assets. And so, if somebody tries to send you, and they're sending you so much and you're like, "Oh man, maybe, I'm in like a credit risk situation." You might want to say like, "No, that's going to fail, and you have to send me something else instead." Or you might be in a situation where you have, like for example, in America there's deposit insurance, FDIC, but deposit insurance has a limit depending on what bank you're working with.
Jon Jove (05:16):
And so, you might say like, "Oh, I don't want to exceed the deposit insurance limit on any given day." And so, then you might have your Chase US dollars, and your Wells Fargo US dollars, and you have limits for both that are equal to the federal deposit insurance limit. So, that's some of the reasons why you might want a line. There are other reasons too that are more about like doing clever things with the protocol, but we don't need to get into that now. That's more of a side effect of the limit existing rather than the impetus were to exist.
Jon Jove (05:47):
There's also on the trust line authorization flags actually, in the protocol just flags. But today, all the flags are related to authorization, perhaps one day otherwise. What are these authorization flags about? These authorization flags are basically saying what you're allowed to do with the asset. So, today you can be in one of two states. You can be authorized or you can be not authorized. This is very simple. If you're authorized, you can do anything you want, and if you're not authorized you can't do anything. But in the next protocol version, there will actually be a new situation.
Jon Jove (06:27):
You can be somewhere in between those two states. You can be authorized to do some things, but not all things. Specifically, you might be authorized to have offers that are open but not send things freely. And there's some useful things about that regarding regulated assets. So, this is the core information that's being stored in a trust line. It's giving you information about the balance, information about the maximum balance you can have, information about what you're allowed to do with that balance. And then there's information about the total liabilities related to your open offers and things like that, but that's more secondary. That's derived data.
Jon Jove (07:08):
You can't go into your trust line and change that data directly. You have to change other things on the ledger to change that. So, this is why we have trust lines. And when you think about adding a trust line, what you're basically saying is, "Yeah, so I want to be configured to hold a certain amount of balance up to a certain limit, with certain rights ideally." And you have to get those rights from the issuer.
Tyler van der Hoeven (07:31):
Let's talk about CAP 23 because the issue as I understand it comes from the idea that for me as an issuer to send my friend a token, the only way that I can accomplish that is for them to already have an account, and already have trusted me to issue that asset. And that's problematic because if I want to incentivize someone, I mean, it could probably be problematic for several reasons, but one of them is to, if I want to incentivize someone to go through this whole process, where's the carrot? I want to ensure that you're actually about to send me some asset.
Tyler van der Hoeven (08:11):
So, wouldn't it be nice if I could just go ahead and send it to them, and then all they have to do is claim it? Or maybe they already have an account, and I just want to send them this token without them as a user having to go through all these hoops to like, "What the heck is the trust line? I just want you to send me the asset. Why do I have to go through all of these functions to create some trust line? Like just send me the asset." It's a usability issue, ultimately, I think. And you've already talked a little bit about some of these CAPs are usability improvements, but it's a very specific, and directed usability improvement.
Tyler van der Hoeven (08:44):
We're not just making something hyper-specific to a particular use case, it has to be universally helpful. So, when you think about like the purpose of CAP 23, what in your mind is the thing the CAP 23 is trying to solve, or the things the CAP 23 is trying to solve for? And then how have you begun to implement those in your thinking, and then also the code ultimately that you've written?
Jon Jove (09:12):
So, at its core, what it's trying to solve is I have an asset, and you want to have that asset. How do I get it from me to you? That's what CAP 23 is all about. It sounds like shouldn't Stellar already [crosstalk 00:09:26]? And I mean, Stellar does do it already. In fact, Stellar gives you tons of power about how to do this. You can do the obvious thing and just send a payment, and hope that they have a trust line for it. Or you can do something more sophisticated, and you can create like an intermediate holding account with pre-authorized transactions. And there's a whole world of what Stellar can do. But all of these solutions have flaws. Take the payment solution for example, this has the flaw that we were already talking about.
Jon Jove (10:00):
What if you don't have a trust line, or what if the account hasn't even been created yet? Then you cannot have a trust line, or take another example where you want to use the intermediate account because you want to get some more features in there. For example, maybe you want to be able to reclaim the payment if it doesn't get completed in seven days or something. This is like a reasonable thing you might want to do. And the intermediate account solution will work pretty well for assets that don't have auth required that aren't authorized required.
Jon Jove (10:36):
But it won't really work well for assets that are authorization required. And the reason it won't work well is if you're the issuer, you can add authorization to that temporary account. But if you're not the issuer, then you're basically asking whoever the issuer is to authorize this second account. But the issuer will say, "Well, hey, wait a second. That's you again. So, I'm not going to do that." So, this fundamentally becomes an issue about using this intermediate account technique with authorization required assets. There are all sorts of ways you can look at these kinds of problems, but at the end of the day, what we are trying to solve in CAP 23 is how do you get a trust line into the state you want it to be in?
Jon Jove (11:24):
How do you get a payment to go out without failing? If that person's account doesn't exist, if that person's trust line doesn't exist, if that person's trust line isn't in the right state. Because if he's too close to the limit, even if it exists, he won't be able to complete the payment. So, that's what we were trying to achieve. This is a huge usability issue, not just for asset issuers. Although, it's very, very important to asset issuers. And they were a huge motivation for what we're trying to do here. But also just for general purpose usage of Stellar, like intermediate temporary accounts are a thing that people are building on Stellar.
Jon Jove (12:01):
I've seen people doing this or proposing these kinds of protocols that have these in them. If people are trying to do this, that means that they are now getting into the land of pre-auth transactions. Pre-auth transactions are complicated. And that gets you back into what I was talking about earlier about these huge flow charts, and state diagrams, and making sure that everything is going to work. We want to make sure that it's just going to work.
Tyler van der Hoeven (12:25):
Yeah, that's great. I mean, that's one of the core pillars, right? Of Stellar that it's usable. We're increasing the usability and stability of Stellar that it works always, and stably, but it also works like we can use it. Developers can get on, and figure it out, and start to utilize the software without being MIT grads. So, that's the impetus that's the design process behind what CAP 23 is, why it's existing. Let's talk a little bit about how you're accomplishing that.
Tyler van der Hoeven (13:02):
So, a little bit more into the nitty gritty of some of the new operations. I've browsed through CAP 23. I think I get the gist of what's going on, which is where we'll get to some of the questions. But ultimately what are the changes? What's the new flow so that you don't have to use these intermediary accounts?
Jon Jove (13:21):
So, CAP 23 to me it has two parts. It has one part that deals with the trust line preparation problem. That part is still in flux. So, let's talk about that part second, and let's start by talking about the improved payment flow, the removing the intermediate accounts, and make that not a thing anymore. So, what did we do? We started from this very simple idea. What if we just said that the thing that people would probably want to do is create a payment that they might be able to revoke at some later time if it's not completed. So, when I talk about these kinds of payments, when I'm talking about them in the CAP, when I'm talking about them to other people, I use this phrase, which is probably not a real phrase. It's something I made up to describe what's happening here, but it's a two part thing.
Jon Jove (14:15):
It's in some ways it's modeling the concept of like, "I am going to agree with you to leave some money in a safe. And all we're going to agree is that safe exists, and you will be able to access it at some later time. And maybe I will too, depending on the circumstances, but you're not going to be there when I put the money in necessarily. I'm not going to be there when you get the money out. And the money's just going to be there, and it's going to be behind lock and key." That's what we're modeling. And so, this is the essence of a claimable balance entry. This is the first new ledger entry that gets created in CAP 23.
Jon Jove (14:54):
So, when I think about a claimable balance entry, I'm thinking about effectively a safe deposit box with multiple people having the keys, and the keys have certain requirements on them, but don't let them be universally usable. With this lock and key example in mind, let's think about what would happen for me to send a payment to Tyler since I'm talking to him right now. And I am busy talking to Tyler. I am not looking at the state of the Stellar network. I don't know if Stellar can receive my Chase dollars, I bank with Chase. Maybe Tyler banks with Wells Fargo. I'm not sure. So, here's what I'm going to do, I'm going to send Tyler some Chase dollars, right now.
Jon Jove (15:39):
Not actually, but theoretically speaking, because protocol 13 hasn't been implemented yet, so I can't actually do this, Tyler. But I know it's a tough break, right? Things are looking good for you. And the thing is, I don't know if Tyler is going to want this money. I mean, he obviously wants the money, but Tyler might be like, "Oh, I bank with Wells Fargo. Sorry, let's redo this later." And we're friends, and so I'd be obviously happy to do that if I find that out at a later time.
Jon Jove (16:08):
And so, what I'm going to do is I'm going to create one of these claimable balance entries, the model of a safe deposit box. And what I'm going to do is I'm going to say like, Tyler has one key, and that key will work for the next seven days. And that's enough time for us to go home from dinner, log into our accounts, and our wallets and see, "Oh, like actually I don't have the right trust lines, and I can't get [KYC 00:16:31] with this bank. So, sorry, we're going to have to redo this." And then, Tyler will either claim this being indication that, "Okay, yeah, I can actually receive these funds." Or Tyler will do nothing because he can't do anything.
Jon Jove (16:47):
He can't take the requisite action. He can't get a trust line into the right state. If that happens, I will hold the other key, but it can only be usable seven days in the future or beyond. So, before the seventh day, Tyler owns it. After the seventh day, I own it. Normally, to achieve something like this, you would need pre-auth transactions, but now you can do this all built into the ledger. This is a huge usability increase. One of the things that's very cool about this is that you can build much more complicated setups than this. You can build a set up where there are many people who can claim it at different times under different conditions.
Jon Jove (17:34):
You can build a setup where you can never reclaim it. So, for example, what if I just said like, "Hey Tyler, this is your money. Like you left it at my house. I'm just going to send this to you, but I don't know if your account can it receive it right now. And I don't want to deal with the error conditions." So, I just send it to him, and it's Tyler's, and he has to figure out what to do with it or the money's gone forever. There are a lot of different ways you can look at something like this. So, it can go from something as simple as like, "Here, take this." To like, "Oh, maybe it's you. Maybe it's me." To a really complicated custodial situation where you need many criteria.
Jon Jove (18:09):
Well, right now we don't implement that many criteria, right now it's time based. But we have ideas about more criteria that people might want. And you could say like, "Oh, you need to be in this time window, and you need to know the pre-image of a [inaudible 00:18:23] hash, for example." So, you basically need some secret information. There's a lot of things you could do.
Tyler van der Hoeven (18:29):
So, what this sounds like to me is just offers that not anyone can take. So, why don't you just create a scenario where I can make an offer on an order book that's only acceptable by a particular public address?
Jon Jove (18:46):
So, this is like that. This was actually one of the ideas that I had like brainstorm about. So, you're right on the right track Tyler, but this is actually quite a bit more powerful than that because an offer doesn't have any conditionality associated with it. An offer is just, you can take this, but a claimable balance entry is built with the notion of like, "Oh, maybe you can take this but maybe not." So, that's the first difference. The second difference is offers are intrinsically revokable. I could wake up this morning and say like, "Hey, I'm willing to sell this thing to Tyler."
Jon Jove (19:31):
And then five minutes later I can be like, "Hey, you know what? Actually, I don't really want to sell it to Tyler. I changed my mind." Then just cancel it. But with the claimable balance entries, if the conditions aren't set up that way, I can change my mind, but I can't take any action.
Tyler van der Hoeven (19:46):
Yeah. The amount of additional functionality you would have to add to offers makes it complex enough to where it's like, "Let's just make something different." Because with offers too, it's an asset for an asset. So, you'd have to set up some counter asset for them to give you in exchange for the item that they have. So, in the case, like they're not payments, they're exchanges, they're trades. And so, that fundamentally undermines a little bit of the whole concept of I just want to give someone something with nothing in exchange. Like it's their item, and I'm trying to make a payment, but it's a payment under condition. And offers they don't support that, their trades or something for something.
Tyler van der Hoeven (20:26):
And so, you could create like an intermediary asset where it's like a worthless garbage asset that they can already get, but then they have to somehow obtain that asset. And then you run into the whole trust line issue already where it's like how do they get that asset to be able to make the trade? The amount of customization you would have to add to an existing offer functionality makes it such that offers would now be harder to understand, and you'd have to make sure you met all the conditions just to use it as you already use the offer book to where it's like, "Let's just make something separate."
Tyler van der Hoeven (20:55):
So, that makes sense to me. What about what happens to the existing trust line flow? Is our existing trust line flows now moot? Nobody's going to use those anymore? Hey, there Stellar community don't mean to interrupt the show, but I wanted to jump in here real quick and call out the Stellar community funds. So, we just entered nomination rounds this week. What that means is we're taking the 18 proposals, and narrowing that down to eight.
Tyler van der Hoeven (21:27):
So, the SCF, every three months we give out three million Lumens, and it's finally time to take part in the voting round. So, if you go to stellarcommunity.fund, you can look through the proposals, read through the different projects, and vote on those which you think really deserve the funding. So, make sure to visit stellarcommunity.fund, and vote. All right, let's go back to the show. Is everything now going to be these claimable balance type trust lines, or does the existing flow of individuals making that proactive effort to create a trust line first, is that something that you still envision people doing?
Jon Jove (22:10):
So, the trust line flow, that's kind of the second part of what CAP 23 conquers. The claimable balance, that's all about committing to do something, putting something behind lock and key, basically. The trust lines, that's more about getting prepared to receive it. So, this is the other end of the problem, and that's why they live in the same proposal. So, the claimable balance entry, let's just focus on that. Like is that going to replace the current payment flow? I'd say no, not in general. And there are a few reasons for this. The first reason is you normally don't need that level of power, and power comes at a cost.
Jon Jove (22:57):
The cost is there's complexity in terms of building your system instead of just using a payment, there's literal cost in terms of paying the reserve for your claimable balance entry, whereas a payment does not have any reserves. So, when you need this functionality, you now have somewhere to turn to, but when you can suffice with a payment, you're probably better off that way. So, that's my stamps about whether the claimable balance will replace the payment flow. Maybe for some people it will. Maybe some people will say like, "This is so much simpler that I'm willing to incur the costs." But maybe not.
Jon Jove (23:42):
Now, there's the trust line aspect of it. And let's actually talk about what the trust line problems are. Because I mean that's again, the root of all of this comes from the trust lines. And so, if you don't have a trust line, how do you get a trust line? Well, you need to have some native assets. You need to have a fee at least, and you need to have some base reserve. But what if you don't have an account, then you don't have any native assets either. Well, then you might go to your local anchor, and say like, "Hey, I need you to create me an account. I expect to have $50 in that account."
Jon Jove (24:21):
And they're like, "Okay, cool." And they go and they create your account, and they have $50 that they haven't sent you yet, because they can't send it to you yet. And so, when they create your account, they also send you some Lumens, I mean, to be clear. And they say like, "Hey, when you receive these Lumens what you have to do is create your trust line, otherwise, I can't send you the money." And the person goes and logs into their wallet, and they're like, "Oh, cool. I have some Lumens above the reserve." And goes and spent them on something other than the trust line. Now, you're back where you started.
Jon Jove (25:00):
And so, even if they did immediately go and create their trust line, now they still have to wait like, "Okay, I created the trust line." Now, you have to wait for the issuer to recognize that the trust line exists, and then send their payment there, and all of this is just a really unpleasant user experience. So, what are we trying to do in CAP 23 to make this better? To try to get the trust line flow to be what people expect it to be. So, we're creating a second new kind of ledger entry. We don't add a lot of ledger entries in general. This is the first time we've done it since I joined SDF, and we're going to do two at once.
Jon Jove (25:42):
So, it's an exciting time to be working on the protocol. But what this other type of ledger entry is, is it's, I call it a prepared trust line. I'm not sure if that's going to be the final name. It might be something else but you can basically ... The reason I call it a prepared trust line is it's a trust line that somebody else created for your account that's associated with your account, but not a sub-entry of your account. Just like a claimable balance entry is associated with your accounts through the claimant relationship, but it's not a sub-entry of your account.
Jon Jove (26:15):
And this is an important distinction. But once you're able to create a prepared trust line for somebody else, this actually gives you a lot of new functionality here for a few reasons. The first reason is you can prepare a trust line into a certain state. So, for example, let's say I'm the issuer for Jon Coin. If there is a real Jon Coin, I'm not actually issuer for it. But let's suppose there wasn't a real Jon Coin. I'm working under that assumption, and I was the issuer or for this hypothetical Jon Coin. And I'm going to send some Jon Coin to Tyler. I'm going to issue it to him. What could I do today to make that happen?
Jon Jove (26:59):
Well, today I'd said like, "Hey Tyler, will you create a trust line please for Jon Coin, and then I'll send you the right amount, blah, blah, blah." It's really boring. It's not a fun way to do things. So, here's what I would do instead in the new world. What I would do is I would say like, "Cool, I'm going to create a prepared trust line for Tyler, and Jon Coin, very important asset auth required." So, I'm going to authorize Tyler right off the bat, but he hasn't even created this trust line yet. He just has this prepared trust line that's prepared into the state that the issuer wants it to be. And then Tyler is going to convert that into a trust line. But the reserve has already been paid. So, he only needs a single fee now to do this.
Jon Jove (27:43):
And so, that's Tyler's part of the flow is the conversion. But I haven't sent him the actual asset yet. Do I have to wait until he does the conversion? No, I don't actually, because I can use the claimable balance entry, which I had just talked about a few minutes ago, to also send him the payment in advance even though his account isn't prepared. So, now my new issue in flow is create a prepared trust line for Tyler. Put it into the authorization state that I desire as the issuer, sending him a claimable balance entry with the amount of asset that he expects to receive, and then I'm done. Now, everything that's left to do is for Tyler. I have no more obligations.
Jon Jove (28:19):
Tyler just has to create the trust line, and receive the funds. This is a way better user experience both for the issuer who can terminate the relationship in terms of like what their immediate obligations are, basically, instantly, and then for Tyler too, because Tyler logs into his wallet and his wallet's just like, "Hey, do you want to convert this into a trust line?" "Yes." "Hey, do you want to receive this free money?" "Yes." "Done. Awesome."
Tyler van der Hoeven (28:43):
That's cool. Next question, why not use ... On the issuer side, on your side create a prepared transaction with all of these points, both of creating their account, creating the trust line, and then sending them X amount of your Jon Coin, pre-signing that transaction, or adding your signature to the part of that operation that's for you. Bundling that up into Sub7 link, and sending that to the user.
Jon Jove (29:25):
Yeah. So, an approach like that would probably work fine for Jon Coin after all Tyler, you're my only client, but it's not going to work great if you have 100,000, a million, 100 million users. These are the kinds of scales that I think about when I think about what the Stellar network could be. And so, when I'm thinking about what we're trying to build, I'm trying to think about things that are going to scale to that, to real huge businesses. You know?
Jon Jove (29:53):
So, what happens when you use that idea on a real huge business? Well, let's suppose if you're getting 1,000 signups a day, 10,000 signups a day, what's going to happen? We started with the idea of I need to sign some transactions. So, here's the problem. I don't know what order these transactions are going to execute it, right? Because I'm sending them off to be executed by somebody else. So, in my ideal world, I'd sign them, number one, number two, number three, number four, et cetera. And then the guys would just execute them. One, two, three, four. I can't guarantee that.
Jon Jove (30:29):
So, the only thing I can do is have a separate sequence number of source for every transaction. But that means that I need to create an account with my signers on it, which all costs reserves for every single transaction. So, this has a ton of overhead because now I need to manage a ton of accounts, and I need to manage updating them into the right states, or creating new ones as necessary. Maybe I need a pool of them that I have ready to go so I don't have high latency. It has a lot of complexity.
Jon Jove (31:02):
It also isn't a nice user experience because imagine that you're a first time user of a product that's built on the Stellar network, and some guy's like, "Hey, I need you to sign this thing." You're like, "Oh wait, is this safe or is this not safe? How do I know? Should I do this or not?" Like Tyler, you, me, we would know whether we should do this or not. I could just like unwrap the XDR of the transaction, and look at what it's doing. But somebody who's never been on the Stellar network before, they're not going to want to do that. They're not going to know how to do that, and they're not going to know what to look for.
Tyler van der Hoeven (31:37):
Yeah, that's a phenomenal explanation because I've done this thing before, and the sequence number will kick you in the pants every single time. And the hoops you have to jump through, particularly, when you ... Because Sub7 has the concept of the replaced parameter where it can replace the signer and the sequence number. But that issue with sending them money, like if you have to attach your signature in that pre-signed transaction, or in that Sub7 link, it's incredibly difficult to get around that. So, this is an incredibly elegant solution, particularly, when you pair it with the second part. So, not the trust line part, the actual claimable balance part.
Tyler van der Hoeven (32:19):
That's amazing. That's going to add so much power, and functionality to a problem that's been around for a long time, and is not easy to solve, but such a common use case for Stellar, and a very like native use case. That should be much easier. So, this is exciting. So, the last real question I have is can we talk about the subentry? How do claimable balances and prepared trust lines affect your subentry account both on the issuers side, and on the claimers side?
Jon Jove (32:54):
Right. So, I mentioned this very important distinction. And it's a totally new distinction in CAP 23, the notion of having something associated with your account that is not a subentry of your account. This didn't exist before. And let's talk about what this means. Like what does it mean to be a subentry? That's a key to understanding here. When we talk about sub-entries, we talked about something that you're paying the reserve for. That's one condition. The other condition about them with a minor caveat is that you can't merge your account if you have a sub-entry.
Jon Jove (33:28):
The only caveat to that is that signers count as subentries but you can merge if you have signers because otherwise that would be a problem. So, basically, you're only allowed a certain number of subentries. There's a limit on the total you can have. And you can't merge if you haven't. So, now let's roll back, and see where this might come into a problem if claimable balance entry is, for example, were sub-entries. So, let's go back into that notion of a business with 10 million or 100 million clients, and you're processing a ton of payments now. So, what do you do when you hit the limit?
Tyler van der Hoeven (34:08):
It's like 102 isn't it?
Jon Jove (34:09):
It's 1,000.
Tyler van der Hoeven (34:11):
It's 1,000.
Jon Jove (34:12):
Yeah. So-
Tyler van der Hoeven (34:13):
Good luck. You just capped your business at 1,000 customers.
Jon Jove (34:16):
Exactly. You're going to hit that limit immediately, in hours, minutes, potentially. What do you do? And then let's say you need to make some changes. Let's say you're not a big business, and you're just some person who thinks that like, "Oh, I don't want to deal with error handling." I'm going to send payments to my friends using climbable balance entries. Well, now if your friends are lazy, and don't claim their money, you can't merge your account when you want it. So, this bites you on both ends no matter what scale you're at.
Jon Jove (34:45):
So, we took this different approach, which is that these claimable balance entries, and prepared trust lines they're not subentries. I think of them as like associated entries. That's the term I use in my brain. It's not written down anywhere. You won't find it if you search for it. But when I think about an associated entry means, it basically means it's something that could exist independent of your account existing. But if your account exists, you can make use of this thing. You might not be the only person who can make use of it, but you are at least one of the people who could under some circumstances make use of it.
Jon Jove (35:26):
So, a claimable balance entry like I described earlier where in the first seven days it's Tyler's, and in the next rest of eternity it's mine, I would say that's an associated entry for both of ours. But if it was a sub-entry, whose account should it be a subentry of? Who should be blocked on merging? If there were three parties, or four parties, or 10 parties, now, who should be blocked on merging? Who should bear the burden? How would you decide? It doesn't make any sense. Especially, because you could merge all your accounts, and the claimable balance can still exist because it could have been created before any of those accounts exist in the first place.
Jon Jove (36:01):
So, what we've done here is we've created this new category of ledger entries. And we've sidestepped the whole sub-entry problem by just saying like, "Okay, if you get merged, you might have some new conditions that come up." For example, if you get merged, and you don't know the private key for your account ID, for your public key, this is possible, then if you had an outstanding claimable balance entry, you won't be able to claim it later because you won't be able to recreate your account, and then use it. But the realistic scenario is your wallet should just warn you if you're trying to do this.
Jon Jove (36:42):
So, that's what the design trade-offs are in this space. But creating this new notion of associated account, it's so powerful that it's worth the other slight trickiness about it. Sorry, I said associated account, but I meant associated entry.
Tyler van der Hoeven (37:00):
Right. So, if it's not consuming a sub-entry, what's the spam prevention? Like, what's to stop me from just spinning up millions, and millions, and millions of these associated ... Because they do take up disk space, I assume, as they're held on the ledger. What's the spam prevention? Is it just transaction fees?
Jon Jove (37:22):
So, they still carry a reserve, but the reserve works a little differently for these guys. For a sub-entry, the reserve stays in your account but it's locked up. For an associated entry, you actually send the reserve off into the world when you create that associated entry. So, for example, if you go and look at the XDR representation of a claimable balance entry, you'll see a field called reserve. And you'll be like, "Oh that's weird. Why is that there?" Well, the reason it's there is that when you created it, you are going to pay the base reserve at the time that you created it. Perhaps a multiple of the base reserve, in fact, for the privilege of creating this.
Jon Jove (38:04):
And so, normally, when you have a sub-entry, if the base reserve changes underneath you, it might liberate or consume more of your balance. This doesn't happen with associated entries. They just are locked in with their creation time reserve, and that's always going to be enough to operate them. So, for a claimable balance entry, it'll be one reserve to create a claimable balance entry with one claimant. You can't do one with zero claimants. It's not permitted because what would that even mean? And then for every additional claimant, you pay an additional reserve.
Jon Jove (38:40):
So, if you have seven claimants, you're going to pay seven reserves. And then when somebody claims your claimable balance entry, if your account exists, and is able to receive the reserves that were stored in it, you will get them refunded to you. But if your account is not able to receive them, they will go to the recipient instead.
Tyler van der Hoeven (39:03):
All right. I mean, that's a great overview of CAP 23. Do you have any ideas around ... I mean, you've mentioned that the trust line part of this is still in flux. Is there any ideas when this is slotted to go out, when this will be live, when you can finally pay me Jon Coin?
Jon Jove (39:19):
Oh, sorry. There's not going to be any Jon Coin. I know, it's a huge bummer. I'm not sure when this will be ready. The main constraint here is that we're still trying to sort out a few issues on the repaired trust line front. The prepared trust lines that I described to you here, that might not be what really ends up happening. We're going to try to achieve the same goals, but we might have to change the mechanism a little bit. There are a few tricky details about what I described. I didn't give you all the details because you would all be asleep, but I assure you there's a few very tricky things that we're still trying to sort out to give the optimal experience to different kinds of users.
Tyler van der Hoeven (40:00):
Cool. Thanks so much for your time. Really appreciate the care, and attention that you put into the work that you do. Looking forward to seeing more work come out of the core team.
Jon Jove (40:09):
Yeah. Thanks for inviting me to do this. I appreciate it. I had a good time, so ...
Tyler van der Hoeven (40:14):
Super. Well, have a great rest of your weekend.
Jon Jove (40:16):
Yeah, have a good weekend too, and I'll catch you later.
Tyler van der Hoeven (40:18):
All right, bye.
Jon Jove (40:19):
Thank you. Bye.
Tyler van der Hoeven (40:27):
For more information about Stellar in the future of decentralized finance, visit stellar.org. Get involved in the discussion in one of our active communities on Keybase at stellar.public or Stellar stock exchange. Until next time, I'm your host Tyler Van Der Hoeven. Catch y'all later.