[00:00] All right, Yeah, So we can get started then. So yeah, today I'll be speaking about CAP 80 and then after that demo will follow up with, some updates to CAP 73. So I just pasted the CAP in the chat, So CAP 80 adds some host functions to enable some more OK uses on Stellar. So in Protocol 25 we added G1, add G1. So in Protocol 25 we added G1, add G1. So in Protocol 25 we added G1. Add G1. Multiply and a pairing host functions. Which gave Stellar BN24 feature. Parody with Ethereum. But this CAP proposes some additional host functions. to allow for better performance, So the functions are some: BN254. arithmetic host functions. BN254 G1 multiscale multiplication. And is on curve checks for BLSG1, BLSG2 and BLS. BN254G1.

[01:00] BN254G1. BN254G1. So the know the with arithmetic, Host functions are expensive to implement on the guest side, which is why we're proposing adding these to the to. We're proposing adding these to the host, and the same applies for the on the host and the same applies for the on the host and the same applies for the on curve checks. We're also adding G1 multiscale multiplication. Because the cost of repeatedly converting points, between the external internal, representation can be expensive and these repeated add and multiplication, host function calls, do those conversions? On each call back and forth, which is pretty expensive. So this multiscale multiplication host function will allow a contract to only do this conversion, once at the beginning and the end, and we already have cost types for most, of these host functions. So the only one we need to add, is for BN2, BN254 G1 we need to add, is for BN2, BN254 G1 we need to add is for BN2, BN254 G1, MSM, MSM, MSM. So I don't think there's anything. that controversial about this change, We are. We're taking feedback from they are. We're taking feedback from the ecosystem on what, what they are.

[02:00] Ecosystem on what, what they're asking for. But I, yeah, I wanted to open asking for. But I, yeah, I wanted to open asking for. But I, yeah, I wanted to open this up to any questions. If anyone has any opinions on any other host functions, we should add: yeah, Are there any? questions? If anyone does have any opinions on you, know what else we should add? Or look, into for, for specifically for the into. for specifically for the like OK host functions, You, you can post in this discussion. right here, that I posted in the chat, Yeah, so doesn't, so there's nothing. else. No one has any other questions, or input, Jay, you don't have anything to add, add, add then. then, see, see, see, no, I think it's fairly. straightforward. And these:

[03:00] Straightforward. And these, yeah, these functions, or exist already. for BRS as well. Seems to be useful to have the reasons they didn't. They won't add it in the first place. Is likely, just we were trying to get it on. Likely, just we were trying to get it on likely, just we were trying to get it on par with in the first iteration and get feedback. So these are the second. on which makes sense to be added: AT&T. Yeah, makes sense. I see Mate. Furthermore, I see Mate. Matias is typing something. I can. follow up with the offline. Furthermore, I can. follow up with the offline as well- to. To send the-the discussion as well, to send the, the discussion thread to the people you think should be threaded to the people you think should be here that aren't But other than that. DIMM, if you're interested, if you're ready to present Cap 73.

[04:00] AT&T. Yeah, go ahead, Dina. AT&T. All right, thank you, I, I guess. one thing you could mention for CAP 80. is that it's actually about three. times: improvement in performance for the contracts that actually try to use this, functions and some interesting applications. So yeah, seems like a very application. So yeah, seems like a very cool thing to have, All right visit. Let me mail my link: cat 73 links, cat 73, link, cat 73 and discussion of cat 73. And I'm pretty sure I have presented, it before, but that was a while ago. So it before, but that was a while ago. So it before, but that was a while ago. So I will quickly, go over the summary of the CAP and then go over the summary of the CAP and then go over the summary of the CAP, and then I will move on to the proposed changes. So I just realized that CAP does. not have the most recent PR merged. Let

[05:00] Not have the most recent PR merged. Let me also, link the full request. That actually details the update I'm going to make. So CAP 73, is a CAP that basically closes. One of the gaps between turban and comic, operations, this gap being an operation, this gap being an ability to create new balances, for the G accounts from SAC, As you, may or may not know currently if a May or may not know currently if an account does not exist, you cannot. transfer XLM to it. And if a trust bank does not exist for a classic asset, you cannot use sack to perform an asset. You cannot use sack to perform a transfer to the respective G account, and this is a little bit annoying. because, in order to fix this,

[06:00] Because in order to fix this, behavior, you need to actually go out of Sora ban ecosystem and go back to the classic operations, just generally quite suboptimal developer, Experience, experience, experience. So what's a CAP? Oh, I see CAP has. So what's a CAP? Oh, I see CAP has. So what's a CAP? Oh, I see CAP has just been merged. What the CAP does in the current iteration is just two. small changes to what sack does, First change is when we are dealing. with XLM tag, specifically transferring XLM to a G account. That does not exist yet will result in: creation of that G account, with respective XLM balance. And this part of the CAP has always been there and it- the CAP-has always been there, and it never changed. So it both basically allows creating new accounts, new G.

[07:00] Allows creating new accounts. New G account from Saroyan and, in general, just closes the gap in behavior where now for XLM stack, you can just transfer to any address and if it is a G address, and an entry will just be created, which is a big win for the developer, Experience. The only caveat to be experienced, the only caveat to be aware about, is the transfer has to cover the base reserve for a new account, which is one XLM. So if transfer is below one XLM, it will still fail, as it. Below one XLM, it will still fail as it. Below one XLM, it will still fail as it does today. But there is really nothing you can do about it. It's just the can do about it. Furthermore, it's just the semantics of the accounts. What has been changed is trust and support. Before that, CAP had a couple functions. to deal with the trust lines and since then I just simplified this a lot to add. Then I just simplified this a lot to add. Then I just simplified this a lot to add only single function, and this function is called trust.

[08:00] And this function is called trust. and it takes in an address and maybe creates a trust frame. So if you're dealing with a C address as this, will always be an old because there is, no trust for C addresses for a G. address. If there is an existing trust line, then again it's an OP and only when an address has no trust line. You, will require authorization from this, address. And if there is the proper authorization, provided the trust lane will be treated and the reason for why we are not going for the automated. approach, as we do with XLM is precisely the authorization part, because it is somewhat non-trivial observations, that transfer may sometimes require like, if we may transfer to non-existent trust.

[09:00] We may transfer to non-existent trust. lines to request us from the transfer recipient and create a trust line That would result in a very non-trivial. developer experience. Because suddenly your transfers may sometimes require require additional loss from the recipient. But this behavior is like really an edge case, and it's hard to notice. So instead, CAP opts for a notice. So instead CAP opts for an explicit approach and the idea behind that is that well. If you actually do, want to create trust lines, you'll write: some code on the contract side to do that, and then you can implement your client logic accordingly to request the O from the recipient, And again, because of this OS requirement, I would say you do not expect this to. I would say you do not expect this to. I would say you do not expect this to be used in each and every protocol. because it is like non-trivial and

[10:00] Because it is like non-trivial and may not be desired to actually request, anything from the receiver. So it might be easier to fail. There are some specific protocols where it is expected for new users to be unrammed so to speak, to the asset, and for these protocols, this would be a useful protocol, this would be a useful addition to do things within, within, addition, to do things within the protocol. I guess there is still the protocol. Furthermore, I guess there is still a point of debate for the automated. solution solution solution transfer to a non-existent transplant. would always require us. I'm like not would always require us. Furthermore, I'm like not super settled on the current way, So would be interested in hearing any feedback. And yeah, I guess another thing that is important, important to mention, is that this new allow trust function doesn't allow developers to specify the limit of the new trust line, and the reason for that really is that.

[11:00] And the reason for that really is that. trust line limits are rather feature, that it is like about 2% of trust lines have limits, that are not effectively unlimited and the percentage may be even lower because they look at like one to the power of, they look at like one to the power of, they look at like one to the power of: sorry 10 to the^ of 18 trust lines, Really secure, could maybe even reduce, the threshold. So it is basically advanced functionality. And for what the CAP tries to do? It does not seem the CAP tries to do. It does not seem the CAP tries to do. It does not seem useful in any way. Like doesn't seem like contract developers can make an educated guess on what the new trust plan limit, should be, and a very safe default is and should be, and a very safe default is and should be, and a very safe default is an unlimited trust line. That users that do care about the limits can then manage, But I would expect such users to. actually set up the specialized trust, lines in advance, not being on ramp like some bridge protocol or something. So

[12:00] Some bridge protocol or something. So just trying to keep protocol simple here, and make it straightforward enough for developer to use this, yeah, of the function. Change this will profile. Well it is technically low trust does the same. thing that change trust operation, but with a very specific set of parameters, I think, the fact that it shares semantics, for special use case of change trust, operation should not impact our naming decisions. But of course I'm open to suggestions for a different name, But the change trust comparison is really just to define the semantics u based

[13:00] Just to define the semantics u based. on what we have in classic. It should no on what we have in classic. It should no on what we have in classic. Furthermore, it should no way impact how we name things and so on way impact how we name things and so on. Way impact how we name things and so on. Now for the allow trust name. I do now for the allow trust name. Furthermore, I do know there is such operation. Furthermore, I'm not known there is such operation. Furthermore, I'm not sure. Sure. Sure, if our decisions for bindings should, be impacted by classic names, the two quite separate domains in my opinion, But again, I'm open to propositions of, how this could be mean better. I mean, create trust maybe is an option. I, I mean, create trust maybe is an option. Furthermore, I find it a bit weird, not sure what? AT&T, but I shouldn't AT&T. So allow trust in on classic only Let you change the trust line flags.

[14:00] Let you change the trust line flags. right, like it doesn't actually let you create a new trust line. So it's a creation a new trust line. So it's a little confusing, AT&T- Sure, but does it really matter? AT&T. I think Le's point is just that you like AT&T. I think Le's point is just that you like AT&T. Furthermore, I think Le's point is just that you like, if you're already familiar with allow, trust, you might think like it's not clear what this function does. AT&T. Well, maybe, on this, rather that function. exists in, so I'm not sure if you should exist in, so I'm not sure if you should exist in. so I'm not sure if you should base naming on what we have on classic, and I would prefer to use whatever. name conveys what this exact function does, and all trust may by no means be a perfect name. I'm I'm just saying be a perfect name. Furthermore, I'm I'm just saying that like I wouldn't look back on classic operations, I would just name it classic operations. Furthermore, I would just name it in a way that is clear enough, Create trust is not very clear to me. but I know, maybe, if it's clear to, everyone. I find this is.

[15:00] Yeah, I guess we can. and maybe discuss this. Fine, Yeah, we, can just call it like you know, Trust this, whatever like we can name it. in any way that is appropriate s I'm just not sure like classic is. necessary, necessary, necessary, but but but AT&T. Yeah, I think it's just like, yeah, we can AT&T. Yeah, I think it's just like, yeah, we can AT&T. Yeah, I think it's just like, yeah, we can talk about this offline. Yeah, we can have a completely unique name for sort, of when I'm planning with that. What I'm really interested in is if anyone has any thoughts on automated trust link, Creation versus a separate function, because we still have a separate, function. And I kind of mentioned my motivation around that. But I wonder if anyone disagrees with that motivation. and thinks that you know it's actually fine to just always try to create a trust line unconditionally, And if a developer her cares about the

[16:00] And if a developer her cares about the scenario, just let them handle this on the client side. And if they don't care about the operation would fail in any case, whether we have a function or not. So, yeah, just curious if anyone has any thoughts, AT&T. But you're saying like in, like if, like a transfer, would automatically create a trust line like that scenario. Yeah, I feel like that would be a pretty. Yeah, I feel like that would be a pretty. Yeah, I feel like that would be a pretty big break from what we currently do I. I big break from what we currently do. I. Furthermore, I like I. I wouldn't be surprised if it is like I. I wouldn't be surprised if it is like I. I wouldn't be surprised if it would mess up a lot of like apps in would mess up a lot of like apps in would mess up a lot of like apps in the ecosystem. If suddenly you can create as many trust lines as you want, The other issue is accounts can only hold. AT&T. Sorry I. I must be clear. Like what I'm AT&T. Sorry I. I must be clear. Like what I'm AT&T. Sorry I. I must be clear. Like what I'm saying is allow trust function would be called unconditionally on transfers, so to speak, which means that we will still require authorization from the trust, line owner. It's not like we create trust lines without permission. We are.

[17:00] Trust lines without permission. We are not changing semantics. It's just about not changing semantics. Furthermore, it's just about explicit versus implicit. And here we do this explicitly so that creators of the protocols, put this line into their code, and they kind of know what they are doing versus an implicit approach where we require us from the trust line owner, and if you handle this on the client side, somehow then you can actually create the trust, plane, given the receivers authorization So yeah, it is basically just about being more intentional of being making, this automated and then letting people figure this out on the client side, only on the client side. So yeah, but the authorization requirements do not. change, change, change AT&T. Okay, Yeah, I see what you're saying.

[18:00] Matias? Which one do you think is better? Better than Which case is better than which case? Bit confused, I think. So are you comparing like the current? approach to the previous approach, in the cup, or are you comparing the explicit versus implicit approaches?

[19:00] Somebody ask: could you please expand on? your point? Because I'm a bit lost in which experience do you think is better? in your opinion? Cannot hear you, I guess I can hear you. Furthermore, I guess I can hear you. AT&T. Can you guys hear me now? AT&T. Okay, I can hear you now. Yeah, AT&T. All right. Yeah, Push to talk always. keeps me All right. And now I'm saying: all I'm saying is: it's the CAP makes it. All I'm saying is: it's the CAP makes it. All I'm saying is: it's the CAP makes it easier to work with, there It's. It's an easier to work with there It's. It's a straightforward way to just create a G. account balance-right account balance, right AT&T. Oh yeah, definitely Yeah. AT&T Within the contract. So that that's what I'm saying, Instead of just having to.

[20:00] I'm saying, Instead of just having to, build, you know the, the whole trust, lines on the outside, and then having that ready you have, then you're ready. to payment. This way, you just make your payment and done with AT&T. Oh yeah, of course. Yeah, I see a point. AT&T. Oh yeah, of course. Yeah, I see a point. AT&T. Oh yeah, of course. Yeah, I see a point. Like, if your feedback is generally about the cup. Yeah, totally, that's the idea. behind the cup. Is that we want to make behind the cup? Is that we want to make behind the cup? Is that we want to make it simpler to create trust lines in Saroyan or possible. And yeah, we only have some small technical things to work, out. But, yeah, thanks AT&T, thanks anyway. Yeah, AT&T okay, AT&T. It makes it very easy to interrupt with AT&T. It makes it very easy to interrupt with AT&T. It makes it very easy to interrupt with the classic site, the with the classic site. Yeah, Yeah, Yeah, AT&T, especially if you want to, transfer, if you're, if you have, if transferred, if you're, if you have is transferred, if you're, if you have, if you're set up on the server side, and then by any chance you have with a G, then by any chance you have with a G, then by any chance you have with a G account or create a G account to push forward payment, to say, or.

[21:00] To push forward payment to say, or something this way, you AT&T, I, had a lot of interruptions, but, but I, you had a lot of interruptions, but, but I, you had a lot of interruptions, but I think I kind of got your, u idea. Yeah, definitely creating G accounts, like specifically creating G accounts, is definitely going to be very simple and yes, there's no friction there, So that's like the most simple thing to. do. Okay, Lee has left some feedback, as well. Yeah, exactly So, basically this point. is pretty much what I've been, thinking as well, that it is surprising if transfer requires more. signatures, signatures, signatures, and u yeah, there is a risk of users just.

[22:00] And u? Yeah, there is a risk of users just and u? Yeah, there is a risk of users just not noticing it, whereas we allow trust, we only leave this functionality to the. protocols that can actually support this, meaningfully, which, as I've already mentioned, is probably just a fraction of the protocols. It's not something that everyone will be able to do, And of course, if ever, yeah, if in. the future, somehow trust domain, requirements are relaxed, then of course we'll revisit this, But for today, if we'll revisit this, But for today, it. seems like explicit is better than implicit. That's my opinion as well. So you folks are typing. Yeah, 8 to 20 rule. Yeah, I think I. Yeah, 8 to 20 rule. Yeah, I think I. Yeah, 8 to 20 rule. Yeah, I think it may be applied here. Yeah, I don't think everyone will need the trans, functionality. But for the excellent transfers: yeah, they'll work for everyone. So, yeah.

[23:00] Yeah, exactly, We can always do this in. automated fashion, if it proves to be more useful, All right, If you have any feedback, the link to. the description has been posted above. and yeah, please feel free to leave. any additional feedback suggestions or concerns there. And thanks everyone I do not think we have anything else. Furthermore, I do not think we have anything else. Oh, actually, one small thing. Let me just drop a link. There is no CAP for this one. It's more of an announcement there is this get wedge host function. That no one on chain is actually using. So

[24:00] No one on chain is actually using. So you may not even know about it and if you did not use it before, please do. If you did not use it before, please do. If you did not use it before, please do not start using it again, because what we want to do is to deprecate it and make want to do is to deprecate it and make want to do is to deprecate it and make it no longer work. Basically, just freeze it at some protocol version and the motivation is listed in the discussion itself, but basically the idea is that you cannot write a. contract that will benefit from this function. Like yeah, there is just really no way to use this function in really no way to. To use this function in really no way to. To use this function in a meaningful fashion and using it is likely a foot gun, which is why we decided that we want to clean this, up- there is no CAP for this yet, but up, there is no CAP for this yet, but up, there is no CAP for this yet. But you can imagine this will be a super. simple CAP, And yeah, we just open discussion a go to see if there is anyone that actually thinks that this is.

[25:00] Actually thinks that this is actually thinking that this is something useful. But we are pretty sure yeah, there is no way to use it. appropriately. So we just deprecated it. And yeah again if you have any, comments for this one. Please feel free to leave on the discussion just an. announcement, basically to bring everyone's attention to this and now, I think that's pretty much it for today's meeting, So thanks everyone, and the next part.

[00:00] Hello and welcome to this week's Stella. developer meeting Today. We have we developer meeting Today. we have the open Rubin team here or at least a part of it, to go through some least a part of it to go through some least a part of it. To go through some of the releases, the library releases from Q4. 2025 was a really exciting year for, for 2025 was a really exciting year for the-the open see and stellar, collaboration. A lot of new great tooling a lot of great libraries and we even had the opportunity to. participate in in in some events with with you two guys, Meridian. And Istanbul Blockchain Week. It was Istanbul Blockchain Week. Furthermore, it was great to see you and have your support. at our events. So, yeah, lets at our events. So, yeah, let's, let's get into it. Maybe, Brian, you can start telling us a bit about what, was released in Q4 and have a look back was released in Q4 and have a look back was released in Q4 and have a look back at, at, at the initiatives, Yeah, thank you, Kirsten. Yeah, it's, always a pleasure to participate at. those dev calls. Yeah, 25 was a busy.

[01:00] Those dev calls. Yeah, 25 was a busy year. Like we shipped a lot of a busy year. Like we shipped a lot of a busy year. Like we shipped a lot of features, to the. features. A lot of features to the library. Yeah, expect that we keep the same, momentum in 26. And, yeah, we're going to present you today three new features that three, three new modules that we added to the library that is the, W A W, the W addition to the M fix W A W, the W addition to the M fix point M, library That will be presented in a short by. Os gun and fee abstraction, the fee abstraction, module, which is something also very important and the beginning of the governance package. That is for the time lock. So, yeah, I am going to pass it time lock. So, yeah, I am going to pass it time lock. So, yeah, I am going to pass it to Os gun.

[02:00] To Os gun, AT&T. Thank you, I'm going to immediately start, So let's say entire screen, and, and, and. I think it is visible right. Furthermore, I think it is visible right. AT&T. Yep, it is AT&T, Great, Great, So today it's the first topic is w a. So today it's the first topic is w a. So today it's the first topic is w a. it's a high precision decimal arithmetic. For Saroyan smart contracts: The reason for or the need for it is like: why for? Or the need for it is like why for? Or the need for. It is like: why are we not going with integers? Or floating points for integers? we're floating points for integers. We don't have decimals. So, for example, this doesn't have decimals. So, for example, this computation will result in zero. Instead, of 0.5 and for plotting floating points there are quite reasonable. things that we are not using them in blockchain, because in blockchain it needs to run on every computer, right.

[03:00] Needs to run on every computer right, like, and some people have macOS, some people have Linux, some people have Windows and across platform, the behavior for floating points is changing. and we need something deterministic in, blockchain setting for safety, and and and, yeah, general blockchain. So, what is what it is a fixed point decimal? What is what it is a fixed point decimal? What is what it is a fixed point decimal system that uses 18 decimals? So for example, one will be represented as this like there are 18 amounts of 18 zeros. here. Similarly, you can see the other representations, representations, representations. So the need for this is this. decimal point system, so that financial systems or whatever your use case that will utilize decimals, can work in.

[04:00] That will utilize decimals can work in, blockchain system, with a deterministic behavior: behavior, behavior. I'm going to dive a little bit, only little bit, into technical details, a little bit into technical details. Since this representation can fit in I, 128 in Rust type, we could use it for 128 in Rust type. We could use it for 128 in Rust type. We could use it for type allies, but we prefer, preferred to go with the new type pattern instead. So we wrapped this internal native type. into our custom type. This allowed us to have the following, For example: we could do custom operator overload for, this type, and we could do conversions from into a from and into other, from into an from and into other types. And we could also write some custom functions for this custom type, So if you went with type allies it. would just be the methods available on, I 128, which would be limiting and in fact,

[05:00] 128, which would be limiting, and in fact maybe misleading, So let's go with operator overloading. first. So if you, say this price and fee are w a you can just do price and fee are w a you can just do. Price and fee are w a you can just do multiplication, multiplication, multiplication or multi- sorry yeah, addition multiplication and division on them. So you don't need to call specific, functions. This is like for your developer experience. You can just write regular Ra's code and it will work. And we also have operator overloading for cross types, like you can multiply a regular number with w a and vice, versa. And you can also do division. So, since this is a fixed point math, library, there is a limit for the precision. And if you go beyond this precision, as in every fixed point math,

[06:00] Precision. As in every fixed point math library, we need to do either truncation or rounding, So we went with truncation, And the reason for that is to be, predictable. So what? Whatever method you are going to use, it will truncate, And this will be conservative in terms, of the smart contract. So the benefit will be on the smart contract end, not on, will be on the smart contract end, not on, will be on the smart contract end, not on the user end, which is what we want in the user end, which is what we want in the user end, which is what we want in blockchain setting, and there is no further additional logic going on It, is fast, So this is how we did the operator, overloading for some cases, For example. for addition, this is just regular. in addition. This is just regular for addition. This is just regular addition. So we didn't do much, But for multiplication, multiplication, multiplication. We need to divide the result by what. scale? So we need to scale it down The scale. So we need to scale it down The scale. So we need to scale it down. The reason is the first and the second multiplicands, like the left-hand side.

[07:00] Multiplicands like the left-hand side, and the right-hand side, both have these. 10 to the power of 18, kind of decimals. So when you multiply them, you actually have 10 to the power of 36. So need to, you need to scale it of 36. So need to, you need to scale it of 36. So need to. You need to scale it down, down, down. And for division, the same goes, we. need to scale it properly. So you don't have to think about this library already has it, and you can just do multiplication and division and you don't have to think about scaling, They don't have to think about scaling. The reason I'm explaining it is to explain this is already handled, so you don't. have to think about it. We also covered. Exponential for it. This is basic, exponent, So the exponent part needs to be integer, So the base part can be decimal and w, So the base part can be decimal and w, So the base part can be decimal and w. this is fine, And let me also type in this is fine, And let me also type in: this is fine. And let me also type in here: in Sloan SDK. You can already have Sorry, you already have this, So you

[08:00] Sorry, you already have this. So you are sorry, you already have this. So you can take power: integer to integer. This is working already. What we achieved by what representation and power function, is. you can do decimal to the power of is. you can do decimal to the power of is. you can do decimal to the power of integer. Right now. We didn't do decimal to the power of decimal. This is for later milestones, but right now, this is achieved and this covers from what I research more than 90% of the use cases, even for financial setting, And we can also touch a little bit on, and we can also touch a little bit on, and we can also touch a little bit on phantom overflow. So you remember from here we are multiplication two wads. together And there can be a potential scenario. This multiplication will overflow out of I 128 type, So it will overflow out of I 128 type. So it will overflow out of I 128 type, So it will be larger than I 128. In these cases we be larger than I 128. In these cases, we be larger than I 128. In these cases, we automatically scale up to I 256.

[09:00] Automatically scale up to I 256. Then we do the division. Then, if it's, fitting, we convert it back to I 128. If fitting, we convert it back to I 128. If fitting, we convert it back to I 128. If not, we result with an overflow. So this, phantom overflow is also handled for both power and multiplication. And you won't see confusing, conversions, conversions, conversions like, for example, let's say you want to convert five to what, but what should this representation mean? Is it the row value five? Like you will get this. The smaller it's the smallest amount, possible. Possible. Possible five. Or you should get the scaled version five. Like this is unclear from this representation right. So that's why we didn't do ambiguous from and into. default conversions. Because the intention is not clear here. Instead,

[10:00] Intention is not clear here. Instead, we have from integer and from row and we also have from token amount and to token amount. So I'm going to go with this amount. So I'm going to go with these examples right now. So let's say you have a token, you have an USDA amount of that much and this corresponds to 1.5 because in USDA you have six decimal, points. So this part is on the decimal part. So if you say from token amount and you provide this amount and you also, provide the decimal point. It will correctly, correctly, correctly scale your version to W A and you will scale your version to W A and you will scale your version to W A and you will get an accurate representation in W A, and similarly the vice versa conversion. is also safe and accurate. You will. If it is also safe and accurate, You will. If it is also safe and accurate, You will. If you convert WAD to token amount, you will. get the corresponding token amount, correctly, correctly, correctly. So I'm going to shortly touch base on. the API reference. Here are the. constructors we have from integer, from ratio, from token amount, from price and

[11:00] Ratio from token amount from price and from row. So let's say you convert a from row. So let's say you convert an integer five, then you will get five sad like full, Pi five, not.0000 five. But you will get the actual five, But if you go from row u, then what you. But if you go from row u, then what you. But if you go from row u, then what you provide will be the scaled down. So in order to get one, you need to provide 10 order. To get one, you need to provide 10 order. To get one, you need to provide 10 to the^ of 18 for the row Representation, representation, representation- We have also converters to integer to. token, amount and row. We have arithmetic operators, like addition, subtraction, multiplication, what by what? And multiplication, what by integer? And multiplication, integer by what are all covered in operator, Overloading: We also have division and division by integer, and we have negation, negation, negation. Ah, one point to say about this: these

[12:00] Ah, one point to say about this. These, are behaving exactly as in the rust, operators. So if you get an overflow, you will get an overflow, and it will panic, as in base rust operations. So we try to, as in base rust operations, So we try to as in base rust operations. So we try to follow the rust convention com, Conventions here to eliminate confusion. If you want to be safe, these are the. If you want to be safe, these are the If you want to be safe. These are the checked variants. Again, as in native rust, rust, rust. We also have utility methods, the. Furthermore, we also have utility methods: the absolute minimum maximum and power. And for these checked versions, and errors, you have the following errors, defined which is overflow, or division by zero, zero, zero. So, if there are any questions, I can. take them, but right now, since I take them. But right now, since I'm sharing the screen, I can't see the screen. So I'm going to wait for a minute, minute, minute. And yeah, based on the input, I can stop. And yeah, based on the input, I can stop. And yeah, based on the input, I can stop. Sharing, sharing, sharing, AT&T. Yeah, it doesn't seem like we have any AT&T. Yeah, it doesn't seem like we have any AT&T. Yeah, it doesn't seem like we have any questions at this point.

[13:00] Questions at this point. AT&T. Okay, thank you, and I can hand it over to boy. Thank you, and I can hand it over to boy. Then was good, yeah, yeah, yeah. So yeah, I'm going to present you the. fee abstraction module. First, what is fee abstraction? This is a mechanism that enables users to pay for, transactions with some tokens, that are are are instead of native XLM. So for, transactions you pay in XLM, which is the regular way of doing it, and this module fee abstraction is allowing users to pay. for transaction cost with other, tokens, tokens, tokens. What are the benefits for? We can see it from different. perspectives depending on who is.

[14:00] Perspectives, depending on who is transacting. So for classic accounts this provides another option to paying fees. So it's just a better user experience for classic accounts. But for smart accounts. This is something like a. a game changing The missing piece. So smart accounts, Maybe, if you are not familiar with smart, accounts, we, at the beginning of November, when we attended another dev call, we presented smart accounts. So I invite you to watch this. presentation if you want to get familiar with smart accounts and the framework we are proposing So framework we, we are proposing So, basically, smart accounts are smart, are contracts and contracts. They cannot initiate,

[15:00] Initiate. They cannot initiate, transactions. Right, they need assistance of another account to do so, And if we call this account a relayed, So smart accounts, they and delayers, they need somehow to understand each other, They, they need a protocol, some framework through which they framework through, through which they, they communicate and settle on, paying fees, and yeah, this is what u the fee Abstraction provides here in this case. What are the core elements of this? module, module, or of the abstraction as a like a general like mental model. So we generally like mental model. So we have a user here behind user. I mean both. Have a user here behind user. I mean both have a user here behind user. I mean both. Any kind of u accounts. It could be smart accounts or a classic account, the user that has some USDA in their

[16:00] User that has some USDA in their holding, some USDA, and they want to hold some USDA, and they want to call a function on a target contract. We call a function on a target contract. Furthermore, we have the relayed that holds XLM, There are some a component of off chain. interaction between them. So the user request makes a request and the relayed responds with some quotes and if they respond with some quotes and if they agree, so the settlement happens. Unchain on a contract that we are going to call fee forwarder contract, What is, the user flow? So, first the user. This is the unchain. component of the of this, model, The user sends to the relayed, assuming there is sending to the relayed, assuming there is an API that relayed uses the relay. The user sends to this,

[17:00] Relay. The user sends to this, relayed request. containing the address they want to, invoke the target function. The arguments and the token that they, in which they are willing to pay the transaction, are willing to pay the, the transaction fee, fee, fee. Then the relayed returns back. Then the relayed returns some max amount that they are meaning the, the price they are willing to pay for this transaction and the two to pay for this transaction, and the XDR to that that needs to be sent by XDR, to that that needs to be sent by XDR to that that needs to be sent by the user, Then the user receives this and if they're, if they are okay, they sign they are. If they are okay, they sign this invocation, but also they, they, they, sign an approval, the fungible approval. that we are going to see in a moment how this play out. So they sign it and return it to the relayed And now we go on the unchain.

[18:00] Relayed. And now we go on the unchain on unchain flow with this signed XDR. The relayed also signs it as a source. account submits to, submits unchain to the fee forwarder contract. And we'll pay the, the, the native XLM as a transaction fee, within the fee forwarder contract. We, transfer the token, is a fee from the user to the token is a fee from the user to the token is a fee from the user to the relayed. This is the that, this fee that will cover the transaction fee, but it might also contain some profit for to contain, some profit for the relayed that are like doing some useful that is doing some useful job, Then, after this is paid the fee,

[19:00] Then, after this is paid, the fee, forwarder contract. Invoke the target contract with the signed authorization, and this produces the the desired effect for the, end user, This part is like the a single. transaction. So it happens in an atomic way, way, way, Then in the library, we propose two flavors of this fee, forwarder contract, Of course, like anyone can write their own fee forwarder, contract. But like we are proposing two two versions of it- permissionless and permissioned. Permissioned, permissioned. The permissionless, is a trustless contract. Meaning that once we deploy it there is no owner. That once we deploy it there is no owner. That once we deploy it there is no owner. That can change some. Some settings Anyone can be a relayed, meaning

[20:00] This can create some dynamic, some interesting dynamics for some secondary market for u delayers, And the permissioned fee forwarder is, on the contrary, a node contract. Meaning, that there is a clear owner that can, Can specify what are the allowed tokens that users can use to pay for, transaction fees, who can act as a relayed. So it is, of course, like a depending on, it, I can see it very well for some it I can see it very well for some it I can see it very well for some applications for some dabs. That are willing to have more control, on who can who. Who can serve. Who cans on. Who can who. Who can serve. Who cans on. Who can who, who can serve, who can be a relay and what tokens they are being a relay and what tokens they are allowing they to are willing to take.

[21:00] Allowing, they are willing to take, as a payment, So what are the key takeaways? for classic accounts, this model is just another option. So maybe we can call it also a better. User experience: But for smart accounts it's a very important addition because it defines how the relayed and the smart account, should interact with each other in order, to, to make transaction happen, And u something that we'll see later this year. This, this model, will integrate with our relayed service. So yeah, this is about the Fe. abstraction module. If there are any abstraction modules, If there are any questions, questions, questions, I can take them.

[22:00] I can take them. It doesn't seem like there's any. Furthermore, it doesn't seem like there are any questions at this point. AT&T. Okay, then I will go then to the next AT&T. Okay, then I will go then to the next AT&T. Okay, then I will go then to the next module, which is the first, module from the governance package. What is a time lock? This is a. smart contract that enforces time, delays on transaction, execute ex execution with the goal to allow for safe exit. If there's some disagreement with a certain governance, decision, decision, decision How this works. Maybe I mean there are different use cases for using, time lock, but the most obvious is in a time lock. But the most obvious is in a time lock, but the most obvious is in a like a very simple setup on owner, Owner based setup meaning we have an owner based setup, meaning we have a contract that many users interact, with and there is an owner that can change certain settings on this contract.

[23:00] Change certain settings on this contract, and usually this is some account right, and if the owner wants to make some change on the contract, they just call the, the functions that are permission that they are callable, only by this owner, and they change it immediately. And the users don't have time to react to this. Okay, So they trust the owner like the. The good fate of the owner, but also like the This, this bear, this bears many risks. I mean not only the good faith of the I mean not only the good faith of the I mean not only the good faith of the owner. But if what? What if the keys' owner? But if what, what if the, the keys of the owner get compromised and some hacker takes control over the, the, contract. So to minimize those risks, we are introducing the time lock, which is a contract, and we designate this.

[24:00] Is a contract, and we designate this time lock contract as the owner of our initial contract, And so, in order, like for, this to work, we need also another layer. of u of accounts that are serving different roles. Here we have a proposer and an executor, and we'll see how like how this, works, So yeah to. To recap in the: classical in the left-hand side: we have the. The setup where account they have the. The setup where account. The account is directly the owner and the. The intent, the intention to do a. change and the execution of this intention through a transaction is like tied is very close, it's tied. together. So they happen immediately and

[25:00] Together, So they happen immediately. And in with the time lock. There is the intention to make a change. That is expressed by the proposer, This happens at some moment. There's some time that elapses some. period, and then we execute the intention. So we the time Between the intention and the execution, is split is get separated, So the unit of this whole flow is an. So the unit of this whole flow is an. So the unit of this whole flow is an operation that is simply a target, the target address. So the contract that we want to act upon a function, the arguments for this function and the predecessor meaning that we are chaining operations, one to each other and imposing some sequence.

[26:00] Some sequence, on the sequentially on the EXE, execution. Meaning the newer operation cannot be executed before we execute the predecessor, to execute the predecessor, the previous one, What is the life cycle of this? operation? So first the sh, the proposer schedules such operation, meaning they, they invoke a proposed function on the time contract, Then there is some delay that we wait for. it to, to pass The executor once the operation, this is The executor, once the operation. This, this time passes. The operation is marked. as ready and the executor will call an execute function on the time block and which will provoke the, the desired Effect on the target contract and we are done, the operation is done.

[27:00] We are done, the operation is done. What are the benefits? So, first, as we mentioned in the classical like the, the most obvious benefit is that it allows investors to exit in time if, if necessary. It also exits in time if, if necessary. It also forces the admins of the contracts to be, more transparent with the other, users. Meaning they need to communicate in advance about what, change they. They mean to, to change them. They mean to, to, to do on the target contract: U. so it is does on the target contract: U. so it. It does on the target contract U. so it is. It promotes transparency. Also in the past we've seen in how. Besides in the past we've seen in how, for example, this separation between the intention and the execution provides some time to react on errors, because it is transparent. So everyone from the community can spot, can.

[28:00] Community can spot, if their errors and prevent them. from happening And, as we mentioned, this also prevents some malicious. takeover of the, the owners or the, the owner's accounts on at the end, this is this whole system provides more. guarantees to the community, So, as I mentioned, this is the first. module from the governance in the next milestone, which is in Q1, we are going to ship the. fungible and the non fungible vault extensions. These are extensions that will allow counting to to to will allow counting to. To attribute some voting power to tokens and the. The governor with all the features about quorum, about counting.

[29:00] Features about quorum, about counting votes and so on, So that's it for the time lock. AT&T. It's fascinating, it doesn't? seem like we have any questions. AT&T. Yeah, if I mean we, if there are. AT&T. Yeah, if I mean we. If there are any questions, we also are presenting. in discord. So, yeah, feel free to ping us in discord. So, yeah, feel free to ping us in discord. So, yeah, feel free to ping us. If you want to learn more, there is. also the documentation. docsopenscom. opening, opening, opening, where these modules and their, functioning is explained in more details. So, yeah, looking forward to see people using those modules and tweaking them and making them for like, useful for their use cases.

[30:00] Like useful for their use cases. AT&T- Great Well, thank you so much for presenting these, these great new. additions and these new concepts, I think the governance is going to be thought the governance is going to be, think the governance is going to be fascinating to see how that develops this year. I think there's a develops this year. Furthermore, I think there's a lot of very interesting, interesting, u things lined up here. Yeah, AT&T. Thank you both for joining. And yeah, it's actually been its last year. Was itbeen actually been its last year? Was it's actually been its last year was AT&T. It was fascinating because I think that's where we really started to see, especially towards the. The last half of last year, where we really saw at half of last year, where we really saw at half of last year, where we really saw at hackathons and builders around the world. started to include and use the The open seven libraries and really started to to to implement it and it's been. great to see how much value this is bringing to, the community and and and how excited the community is about all the work. the great work you're doing So. so thank you, so much for joining and AT&T, thank you. for hosting us once, again, Looking forward to the next time.

[31:00] Again, Looking forward to the next time. AT&T. Yeah, we definitely do another one when. AT&T. Yeah, we definitely do another one when-when we have more updates. So thank when we have more updates. So thank you for joining everyone and u glad to be here. AT&T. See you later. Bye, bye, All right.

[00:00] Another case is just a bit better. extension strategy for general purpose. contract, so that you can spread out the extension feeds among users, more evenly by limiting max extension, And the way we achieve this is, described in the gap. We provide a new interface for the tail extension, function. Or rather, two functions, One for the contract data, another is for contract instance in code And instead of the old threshold parameters, that defined min extension, we define just the range of min extension and max extension. That tells that extension will be only performed if it is at least, will be only performed if it is at least, will be only performed if it is at least minion, and then it will be clamped by max extension. So can set up more.

[01:00] Max extension. So can set up more complex detail management strategies, I don't think there is a need to go. I don't think there is a need to go. Furthermore, I don't think there is a need to go into into into math more deeply, Basically, there is some edge case there. There is some edge case handling. But the gist of it is really that, besides limiting the minimum, extension necessary to actually extend to DL, you can now have the max extension as well, Please take a look at the cup for more. Please take a look at the cup for more. Please take a look at the cup for more details and if there are any questions regarding, this cup right now. Please feel free to ask someone. I guess the only kind of tricky part, Okay, So the question is, for example: current detail is 10 extend to 20 mean.

[02:00] Current detail is 10. Extend to 20 mean. Five max 8. extend would work with current. Okay, so it is important to distinguish. between TTL and leave until ledger TTL, is basically how long will entry live? from this moment, For example, we are on ledger n and even till ledger. We are on ledger n and even till ledger. We are on ledger n and even till ledger is like n plus th00and that means that GPL is a thousand lectures. Because the entry will live for a thousand lectures. from now. So let's say your current TTL, not wedder is 1,000 wedges. and then you can say I want to extend. And then you can say I want to extend, and then you can say I want to extend the TTL to be 10,000 wedges, but only allow extending by. Let's say,

[03:00] but only allow extending by, let's say, 500 wedges at a time. So, for example, if you're on thousand welders now your, target is 10,000. Every user that calls it will extend the entry just by 500. wedges. And that's limiting the fees Every individual color between, and, on the other hand, again the same. scenario: you want your TL to be 10,000. but it's already 9,999, You know the extension will be just one. additional ledger. And if your main extension is, for example, 100 ledgers and you want to pass the check and TL, extension will not happen at all. Which is basically similar to what threshold does, but just is a like the math is a bit different, but the end result is exactly the same, I believe.

[04:00] I think is a topic that is easier to. I think is a topic that is easier to digest like a piece of paper than trying to digest like a piece of paper, than trying to digest like a piece of paper, than trying to clean it but yeah, yeah, yeah, has all the equations, so can plug in. some numbers and see what comes out of it. It. Yeah. So the other consideration I wanted, to add-is that for temporary entries to add, is that, for temporary entries, max extension will work in the same way. Which may or may not be a bit of a foot, which may or may not be a bit of a foot, which may or may not be a bit of a foot, gun because, if you miss the extension of a temporary, entry, it will be gone forever. And this may not be desirable for a lot of use, may not be desirable for a lot of use, may not be desirable for a lot of use. Cases of temporary entries. So generally speaking, this min extension.

[05:00] Generally speaking, this min extension, parameters, So the threshold parameter in the existing functions is really more for the fee management, for the, persistent entries and for the temples you generally want the extension to. always happen and to always happen in precise fashion. Or else you're risking to just lose your temporary entry, because hasn't happened. And yeah, protocol allows that, but probably at this DK level. We'll try to make sure this the default is reasonable and this is the default is reasonable and this, the default, is reasonable, and it is hard to do something weird. For you with extension, because we, misconfigured your Mina extension, Okay, wait for like few more moments if I want. Wait for like few more moments if I want to type in.

[06:00] A second. Well, I apologize for that, but not sure. if I can do anything. Okay, yeah, it may be discord acting up on. Okay, yeah, it may be discord acting up on people. Yeah, sure, what can you do about it? Right, if you have any further. questions or suggestions regarding this? CAP. The discussion has been linked. above. So please feel free to comment asynchronously, asynchronously, asynchronously and visit. Let's proceed to cat 79. Let me link it. Okay, LY, this one is a simple CAP as well, and

[07:00] this one is a simple CAP as well. And this one is a simple CAP as well, and it just adds host functions for the max. address string to conversions, and it basically closes a bit of, feature gap or an oversight. We've introduced in Protocol 23. In per code 23, we've introduced a new type of address: max address, which allows users to specify an additional it to 64bit, 64bit, 64bit. I am sorry, 3 to 64 bits doesn't really. I am sorry, 3 to 64 bits doesn't really. I am sorry, 3 to 64 bits doesn't really matter. But basically it allows users to specify an additional, memo, together with their click key, and then this memo can be consumed by the exchanges, to distinguish between multiple users, that

[08:00] distinguish between multiple users, that have the same address on chain. So that we can have a federal account. that has multiple users but only a single sure entry. Holding the balance on chain. Okay, okay, try to actually disable noise. Suppression: I, I know that did introduce some artifacts before hope. It's better now. So, yeah, anyway, coming back to zap u m addresses has have been added in Protocol 23. You can pass them in as contract, arguments, but what has been missed is the St key format conversions, that exist for regular addresses and sorry use cases for keys.

[09:00] And sorry use cases for keys Mainly, mainly, mainly, bridge protocols, protocols that generally do anything. Cross chain and ST key is common format to use for. messaging, like if you need to specify storage destination from desert chain store key is a preferred format and not being able to handle key for max, addresses kind of limits, the protocols, I guess. the C is very straightforward. It just does the conversions. The only thing about it is that well potentially, not potentially, but we we have already implemented this, functionality in the SDK. So there is potentially an argument of: well, why do we even have it in host? And I think in we even have it in host and I think in we even have it in host and I think in this case it is mostly for the sake.

[10:00] This case it is mostly for the sake. of the, full feature set, like we already have the key conversions which was possible, to get away without the host functions, before, and, of course, doing things on the old side is just cheaper and with more future-proof, hopefully because the implementation can be for, example, fixed without updating any contract, in case there are some set issues which we hope won't be the case, case, case, so, so, so, yeah, that's the CAP and I guess in this, yeah, that's the CAP. And I guess in this, yeah, that's the CAP. And I guess in this case, yeah, it's just cheap enough to implement to have it have a consistent host function coverage for all the address kind, instead of this weird feature gaps that we have right now.

[11:00] Exactly NS feature part. I think is an Exactly NS feature part. I think is a main driver here, Okay again, I will not okay. Keep max address. no, the CAP. Okay, Maybe I'm not the CAP. Okay, Maybe I should have answered the cup Specification. Specification: specification: the gap returns either address object. for the regular keys, or or or. well, yeah, I guess it's a semantics. Question, what? What do we even call address? Because we have this two different object types address object. max address object. And the function can return either one.

[12:00] And the function can return either one of them. So I guess it's kind very philosophical question. It should be philosophical question. Furthermore, it should be called too much to address or just to address, address, address. Yeah, I'll give it a thought, probably. but doesn't seem very important in the end. I think I guess my intention end. Furthermore, I think I guess my intention here is that V2 would be used. Going forward for all the use cases. So that you don't, you can just safely stop using V1 in the SDK and won't be any semantic V1 in the SDK and won't be any semantic V1 in the SDK and won't be any semantic weirdness. All right, we'll spend a few more. moments before typing.

[13:00] That's a good question. Yeah, I think. If address is using the old one, then you can name this more specifically for max, services. Because like, yeah, you could use a new function, but then you will need to a new function, but then you will need to a new function, but then you will need to distinguish between different object, types and fail, and that's unnecessary work. I agree that old function is still work. Furthermore, I agree that old function is still useful for the case of like normal address, conversions. Actually, you kind of do care if it is an M or G address, because some addresses are like bit gain. We try to limit the scope, for where you can use them, For example, you cannot require an m address. You need, you cannot require an m address. Furthermore, you need to convert it to a normal address first, And, yeah, not every contract can deal.

[14:00] And, yeah, not every contract can deal with M address correctly, which is why it's completely its own thing. So, basically, max address is a super set. of address. If you can deal with max address, you can deal with address but not vice versa, Yeah, I think that's a good. suggestion. Yeah, I think, after reconsidering this. Yeah, I agree, that two maxed address and max, address. 230 sounds more in line with how we use them, Thank you for the suggestion. I will thank you for the suggestion. Furthermore, I will update the accordingly.

[15:00] Right as usual. Any questions or comments can be left on the discussion. thread. And let us move to CAP 77 Right Boston, And this CAP is much more. straightforward than the previous two, And to give a bit of background of why this came up, as some, all of you, why this came up, as some, all of you, why this came up, as some, all of you may know, we had an incident in Protocol 23, caused by data corruption bug, And the initial response when the incident has been discovered, was to make it so the corrupted data.

[16:00] Was to make it so. The corrupted data cannot be accessed to prevent and for their corruption before we understand better, better, better. And that was especially relevant for, the entries that have been corrupted, but not yet restored. So like for these entries, we definitely have prevented further breakages and corruption, And the way this has been achieved was, via an emergency release of tower core, that basically just hardcoded some, hardcoded, they affected contract, data keys and rejected any transaction that accessed any of this Bad keys in the footprint.

[17:00] Yes and yeah, I will. talk about this. Yes, and this has been achieved without, any protocol changes, right, yeah, this, Captors will have to agree. I'm just captors will have to agree. Furthermore, I'm just talking about like to, to provide some background like what auditors can do, today without any protocol changes, or anything. Is that they can just exclude transactions from the man pool? They can do this for whatever arbitrary malicious and unmalicious reasons, But it's an important thing to, understand when thinking about this CAP. because it's doing something like. very uniquely different from what, lawyers can do today, So yeah for the for this. Corruption issue: custom core build. would reject the transactions that try. to access bad keys at the male level.

[18:00] To access bad keys at the male level, and, and, and. Corruption could only be prevented at. the moment when every tier one valuator, has updated to this new core build, such that there is no way that a transaction would end up in a transaction set that accesses corrupted data. And it is a very fragile and time-consuming procedure. Right because, first, a new release has to be, pushed and second, you need like a 100% consensus on this, so to speak, like consensus at the level of build and its consensus at the level of build, and it is not providing any guarantees, even because can fall back the build, or whatever intention or unintentional, reason, reason:

[19:00] which motivated the gap that would, allow doing something like this at to allow, doing something like this at the protocol level, and the benefit of this at least conceptually doing this at protocol level as well, an explicit consensus of all data is required. which is both good from the transparency, standpoint right because it is possible to observe what validators have voted for, but also from the emergency response standpoint. We actually need lower percentage than 100 to agree on applying a network upgrade. So even if not every validator but just say five out of seven is the but, just say five out of seven is the. But just say five out of seven is the current network config right now. Are the upgrades that would freeze the ledger keys. Then the upgrade will go.

[20:00] Keys, then the upgrade will go. through. And also it is not easily reversible without votes. So there is no concern that: oh what if someone changes. their build and what not Obviously This is the case, Like this scenario is something that we'd like to avoid in the future, because we, I guess one of the arguments, maybe against this camp is: well, probably don't want to have any similar data, Corruption issues in the future, But of course it is never possible to say that the system is 100% formally, valid and will never ever result in any bugs. So that's a bit of trade-off between like making protocol more, complicated for the off chains. If data gets corrupted again, for whatever reason, and freezing the keys would be.

[21:00] Reason and freezing the keys would be that right remediation for this, And another potential motivation for, this would be: if there is like known, hack, a vulnerability that affects some contracts for users, for example, there is a theoretical possibility for freezing the balances, But I think this case is much less clear. But I think this case is much less clear, but I think this case is much less clear. If it is relevant or not, because if you're talking about like high-profile, hacks, hacks, hacks might be really tricky to chase right by. your entries. Some exact cases of bugs, were you know they're likely not being, did you know they're likely not being exploited actively, and the impact is more or less limited to some set, of entries, somehow, but you know it's still a consideration. Okay, let me read the

[22:00] consideration. Okay, let me read the question from chat. Yes, so, now, in terms of the actual ways the cup now, in terms of the actual ways the cup now, in terms of the actual ways the cup works, works, works, there are like it pro it covers three. types. Three kinds of entries. Oh, I guess yeah, on high level, just two kinds. Urban entries and nonurban entries. And for non-stop bind entries, we are. And for non-stop bind entries, we're only considering account and trust line, entries, because this seems to be like if we bother implementing this logic, for classic entries, this two seem like the most obvious candidates, everything else on classic does not actually hold value usually and the risk of like, even if corruption happens there, the consequences are probably pretty, tame and, yeah, it's more of a

[23:00] tame, and yeah, it's more of a complexity: trade-off, And Saroyan- only entries, of course can, and Saroyan, only entries, of course-can only be accessed from Saroyan, which makes the freeze process much easier. And now to answer the material's question. yes, if network votes to freeze, contract code key, for example, then any transaction that accesses this contract, will be rejected, It will not even fail till, not even be. It will not even fail till, not even be. Furthermore, it will not even fail till, not even be included into a charge. So I don't know, for example, if a contract, gets corrupted for whatever reason and skips authorization check, somehow Right, freezing the contract is actually a good remediation, because you know the user will not be able to interact with vulnerable contract.

[24:00] Yeah, basically what is the use cases? Yeah, basically what the use cases that will die? Are this fitting the that will die? is this fitting the CAP? But the idea is that any interaction- either read only or write interaction with the entry is prohibited. with like one small exception. We said with like one small exception. Furthermore, we said, there again for the sake of simplicity, But the idea is that the entry cannot, be accessed. It's not only that you cannot, for example, modify balance. It cannot, for example, modify balance. Furthermore, it's also that you cannot even read it. Right. If you try to read this balance you will fail as well, because if balanced, you will fail as well, because if balance is corrupted, for example, then you may arrive at bad results, which happened. for example, with Protocol 23: corruption, bug where liquidity.

[25:00] Bug where liquidity pool got incorrect balances, That's actually don't recall. If the data inside the pool was corrupted, further. But there is definitely a risk of this happening, like if you have any mass based on just reading the corrupted entry this mass may go wrong and then you may end up in bad state in an you may end up in bad state in an you may end up in bad state in an unrelated contract, so, yeah, let me continue with this pack. That may answer some more questions. So yeah, basically, as I mentioned the. intention is to not include, the transactions into lure at all. If we

[26:00] transactions into lure at all, If we get into dealing with account and trust, entries. That's unfortunately not always possible. Because, like Sora ban, no footprints for classic operations, and and and it is not always possible to know if a. it is not always possible to know if a. it is not always possible to know if a frozen entry is even being accessed. which is why a fraction of transactions, would fail at apply time, and it's also some separate logic for handling decks? U described in the CAP that I will talk. about in more detail later, But yeah, the intent is really. just to prevent the interactions with, the entries and, unfortunately, the way of doing this is kind of complicated. because, like, if we include classic, if we don't include classics, then it is as simple as filtering based on footprint.

[27:00] Simple as filtering based on footprint, So let me talk a bit more detail about, So let me talk a bit more detail about, So let me talk a bit more detail about the semantics first is the upgrade. process itself. It needs to be customized a little bit compared to the normal network upgrades as well, because the maximum size of the network, upgrade is limited by the contract data size, and it may be a limiting factor if we need to increase many, keys, which is why we key, which is why we the proposes a structure where delta of the changes since frozen entries, is voted for, so that the total amount of is voted for, so that the total amount of is voted for, so that the total amount of frozen keys can exceed the contract data. entry size and can be updated incrementally, incrementally, incrementally. That's a bit of an extension on the.

[28:00] That's a bit of an extension on the current upgrade process, which rather straightforward, but again it's like a bit of additional complexity of this CAP. And now to the fun part of how. actually this would be implemented at. the protocol level, So, as I mentioned for Robbin, transactions, things are very simple. If we see a frozen key in the footprint, If we see a frozen key in the footprint, If we see a frozen key in the footprint, we recheck the transaction and that's. it. We don't need to do anything else. We can also like if an account is. frozen, and it's a source account of the transaction operation. Again, you just reject the transaction. That's simple as well, well. Well, Then the CAP lists operations. Where, it is easy to say what is a source trust?

[29:00] It is easy to say what is a source trust. It is easy to say what is a source trust line, destination account or trust line, by just looking at the operation which, is good chunk of the operation, So basically again, if we inform that a frozen account and trust line is accessed, we reject the transaction and everything is good Now to the non-trivial operations. First, cable balance operations: claim balance and liquidity pool. deposit and withdrawals, or using opaque identifiers. And without doing some logic, it's not possible to tell what the destination is unless we do some additional type of indexing, which I'm not sure if you want to do which, I'm not sure if you want to do which, I'm not sure if you want to do, but the suggestion here is just to, fail at the applied time if a frozen key.

[30:00] Fail at the applied time, if a frozen key fails at the applied time, if a frozen key is being accessed after we have actually determined what are the actual trust lines participating in the operation And I believe for KAL balances it's even, more tricky because a balance can have multiple. Please never mind that I said something. incorrect, incorrect, incorrect. Anyway, This is like a bit ugly, but still straightforward. What is ugly, and kind of complicated is DEX operations. So again, if you wanted to support free prison and trust lines and accounts, then we need to care about decks-classic store decks and decks, classic store decks- and of course it is not possible to tell, beforehand if a frozen balance is being affected by deck separation.

[31:00] Being affected by deck separation, It will only be known, known at the. apply time and then at the apply time, we apply time and then, at the apply time, we apply time and then, at the apply time, we could also just fail if we encounter an offer that would result in modifying a bad balance, frozen balance. But that would have frozen balance. But that would effectively, effectively, effectively freeze a whole asset pair for trading, which is a bit of, AT&T. An unexpected impact. for the change week. We want to be for the change week. Furthermore, we want to be pretty surgical about this. Like we want to prevent operations that depend on, corrupted entries. But we don't corrupt entries. But we don't really want to disrupt network activity, more than necessary. Beyond that and freezing all trading pair and deep, may be problematic, Of course, chances of that happening, are not very high, but still we want to are not very high, but still we want to are not very high, but still we want to prevent this in the protocol. So the prevention this in the protocol. So the proposal in the CAP is instead of:

[32:00] proposal in the CAP is instead of freezing the pair, is to emulate crossing this offer without modifying any balances, and just remove it, which is not great. Remove an offer, But it kind of gets around the issue, of of of freezing the whole trading painter And of course we could add some more. complex logic to just skip it. But we would need to skip it every time. we encounter it And yeah, it would require some pretty. invasive changes to classic decks for a very limited use case, that we don't. even know if it happens. So the proposed solution is basically a trade-off between complexity, and and and usability of not freezing the whole trading pair. Kind of agree, it's not.

[33:00] Trading pair, kind of agree, it's not pretty, but it's the best you could come up with that seem relatively non-intrusive. And the last but not least, exception to, all this mess is well if an account is all this mess is well if an account is all this mess is well if an account is frozen. What happens if someone removes an entry sponsored by this, account? And again it would kind of be weird to fail everyone that has this interact, Sponsorship, dependency on a frozen account, which is suggestion, is to allow modification of nonsponsoring, Field, field, field, which is a bit of, a leak of the free semantics, a bit of a leak of the free semantics, a bit of a leak of the free semantics, but it seems acceptable as we not really, but it seems acceptable as we're not really touching the balance or anything like that. It's just sponsorship field.

[34:00] That it's just sponsorship field, and, and it's very unlikely to be corrupted, and even if it is corrupted, they can. just, yeah, they should be relatively easy to fix if necessary. Product. So, so, so it seems like again it is a trade-off. between like complexity because tracing the sponsorships to free frozen, entries is much more complex and probably needs to happen at runtime for, every operation which seems like a lot, of overhead. So this, this is basically a small compromise between complexity and limiting impact to only what is hopefully relevant.

[35:00] Contracts do not. I see question from John: What? What other challenges exist in having contracts call to exist in having contracts call the decks? Congress cannot call the classic decks at the moment, and I'm not sure if they will ever be able to precisely because of their reasons, for why you have all this nice cure It, for why you have all this nice cure It, for why you have all this nice cure. It is not possible to know beforehand, What is the data that will be modified? by any traction involving text? We, just buy any traction involving text. We're just going against this San data model, where we define everything. That is going to be accessed in the footprint. Yeah, contracts cannot call DEX. But, for the purpose, like if you wanted to, freeze accounts and trust lines, you would need to deal with this deck, somehow, somehow. So, yeah, that's more or less it for the. So, yeah, that's more or less it for the semantics. It's again, there's a lot of semantics. Furthermore, it's again, there's a lot of complexity in handling the classic entries. And an argument could be made to

[36:00] entries and an argument could be made to maybe limiting this CAP to only sol, entries, because this only appear in the footprints and it is very simple, Check so seems weak and much simpler. Change than what is described here. But of course the impact is much more, limited. And if an account gets corrupted for whatever reason, then of course we won't be able to do anything, about it, Yeah, that's pretty much it for the. semantics And I guess I've touched this a little bit. before. But yeah, and I want to emphasize that. Well, this CAP may look controversial, like, already have censorship powers and really what this proposes is basically an emergency mechanism. That is also.

[37:00] An emergency mechanism that is also transparent. So it seems quite unlikely that it can be abused meaningfully, And you know if our leaders conspire, to do something bad anyway, then probably will not learn about it, unlike, this protocol mechanism that is at least observable. But yeah, I, I think the bigger downside, to this CAP is really all the technical complexities this comes with and the fact that we kind of do not know if fact that we kind of do not know if fact that we kind of do not know if this is ever going to be used like of this is ever going to be used like of this is ever going to be used like of our response to potential things like to do, if something like risk, Archival corruption bug happens again. but of course we don't know what is.

[38:00] But of course we don't know what is, that probably, what is that happening? So yeah guys, that's kind of the main. thing. Initial this camp and to summarize the implications it's. really like, in Canada, access entry and depending on the number of contexts, entry can appear in a number of operations will not be possible, so, yeah, any questions or thoughts on why, this is a good idea or bad idea, or we this is a good idea or bad idea, or we this is a good idea or bad idea, or we should do something else, are welcome.

[40:00] Right, well, I will then pop here and again same. for the other CAP's. Please feel free to comment on the discussion thread. If you have any thoughts, questions, concerns or anything but. but I, I don't know, I think that's pretty, much it for today's presentation, I guess, while everyone is here, I just, want to remind everyone about SOP4. Which is a proposal to basically increase, the limits for pretty much every, resource, and so about two times, and also decrease non-refundable fees, like four times, which means basically more stuff to do on chain for cheaper which is- And please feel free to.

[41:00] Which is. And please feel free to chime in the discussion. If you have any thoughts on this as well, And yeah, that thanks everyone. and see you on the next protocol meeting.

[00:00] Hello and welcome everyone to this week's Stellar Developer Meeting. With me today I have two guests, that have been around here before from OpenZeppelin. And what we're going to do today is we're going to take a look at what has been added to the OpenZeppelin tool chain and the libraries, that are supporting Stellar for the last quarter. So I'm super excited. I know we're going to talk about smart contracts. We're going to talk about WAS. So. So yeah, please introduce yourself and let's get started. Yeah. Hello everyone. It's really a pleasure to be to participate again at the Stellar Developer Meeting. My name is Buan. I'm open source developer at OpenZeppelin. and I'm

[01:00] building the Stellar contracts library. Hi everyone, it's Ugun here. pleasure to be here. And I am also an open source developer at OpenZeppelin. We are a team with Voyan trying to bring trying to improve the smart contract ecosystem for Stellar Sorovan. Great. Thank you. So we've done quite a few hackathons this year and it's really great to see, that some of the developers they're starting to use open sin software and the libraries and the tooling. And I think what you're going to show today is going to be really interesting for a lot of developers. So. If you have a presentation you can share. Yes. I will start. let me show my screen.

[02:00] [clears throat] Yeah, there it is. Sorry. Sorry about, that. yeah. So I'm going to present to you today the [clears throat] smart account framework, that we created with released with the latest u latest release of our library. Just to mention, that yeah already a month ago. When with some of you we met at Meridian in Rio. How excited I was and I guess it was the case for everyone to use pass keys to have all this

[03:00] like wallet experience abstracted into smart account. So our ambition is to make this the new normal for Stellar. So yeah we are building this framework u with, that in mind. So without further ado yeah let's dive in. First a point about naming and why we chose smart account and not smart wallet. First [clears throat] the Soroban SDK defines custom account and custom account interface and our design builds on top of it. So, that's why we decided to choose smart account as a naming and yeah smart account

[04:00] must implement this interface. Then why smart accounts are necessary? Let's just explore a very simple scenario. Where a smart account, that holds some fungible tokens and the owner of the contract wants to transfer some amount and, that's why they need to call a function on the USDC contract. In this case, they will make use of a cryptographic key, that is registered at this smart account to authorize the operation. And by looking from this perspective, we the perspective of account abraction, we are establishing a boundary between the account, that holds the sets and the keys, that control them.

[05:00] now let's try to define what a smart account is. So let's this is a smart contract first and foremost, that composes authorization intents, that are coming from multiple sources and this high level definition will guide us through the all the components of our framework. With this in mind, let's first see what are what the authorization sources could be. As in the previous example, an authorization source could be a cryptographic key or there could be multiple cryptographic keys for the same smart account or it could be a G account, that authorizes on behalf of the smart account or it could be any combination of these cryptographic

[06:00] keys, G accounts or other smart accounts and smart contracts. The next part of the definition talked about authorization intents. What are and yeah we will see what are the core elements of the authorization intent. We can examine this by answering these three questions. We can define who is allowed to act what are they allowed to do and how those permissions are enforced. Who is allowed to act? This might be already clear. Those could be some keys from different cryptographic curves also G accounts C accounts. What are they allowed to do? Well, here this can be literally any kind of action either a specific function on

[07:00] a specific contract or just transfer the transfer function on any SCP 41 compatible contract deploy deployments as well. So yeah, any kind of action how is this enforced also many different combinations are possible. It could be key one and key2. Key1 or key2 key1 and some other conditions, that are not derived from the from a cryptographic scheme and to give names to those groups. Who is for signers? What is the scope and how is for the policies? How do we compose those elements? So we have signers scope and policies and we embed them in the entity called context rule. Here you see, that

[08:00] besides the signer scope and the policies we also have the notion of validity. Context rules function like routing table for authorizations for every context. They they specify the scope and the conditions, that must be met before the authorization is granted and yeah we'll see how this goes very shortly. So a smart account is stores a set of those context rules and up to 15 rules per we can have up to 15 rules per smart account. We added this limit to ensure there a reasonable resource consump consumption and to encourage proactive management. For example, to encourage you to remove the expired or unused rules. And coming back to this authorization

[09:00] mechanism or algorithm, actually it's pretty simple. When the authorization from a smart account is required first we gather and order all non-expired rules. And then we evaluate them starting from the last addit one. Now let's zoom into signers we have two types of signers delegated and external a delegated signer can be any Soroban address, G account or C account. And on the right we group all cryptographic types of schemes or keys in the external variant. And we'll see just in a second why we call it external. But first how the delegated signer grants an authorization. Codewise it's very simple. We use the built-in

[10:00] require out for arcs function and. However there is a catch I of how we are actually constructing this transaction I won't go I won't dive into this sketch I it's like you can find more information about it in the documentation and there are some code snippets explaining how to get over it. Just mentioning it and, that the CAP-71, that hopefully gets included in some of the future protocol updates will resolve these issues. So yeah very soon I hope it will be a u no issue. The second signer type is the external one for authorizations coming

[11:00] from cryptographic keys. But before we look into, that, I'm here providing a list of the curves on Stellar there the already available ones, that are supported and BN 256, that might get added with Protocol 25. And yeah, I guess there could be many more in the future. And you remember the structure of the external serer like to go back it's a tle of address and by and byes we could have defined its structure like this by enumerating all available curves and the [snorts] bytes, that should be interpreted according to the curve type. But you would agree, that this approach is not very scalable. Because on every new curve, that is added

[12:00] you have to upgrade your account. If it supports it and this is not practical at all. Another drawback of embedding signature verification into the smart account is, that it binary size will grow and the code complexity will increase as well. For example, the ED the classical ED 25 119 like it's just one liner. But pass key verification for example is pretty much is more evolved and requires more like more code simply this pushed us to adopt a way more flexible and scalable approach, that is outsourcing and externalizing all type of signature verifications. So we have a verifier contract, that stands for this address and the public key, that is the bytes.

[13:00] this verifier contract is a special one. It is deployed only once per curve type or scheme and should be immutable. It's it shouldn't keep any state and in such way a single verifier contract can validate signature signatures for any number of keys. And yeah this was made possible thanks to Protocol 23 and, that made the cross contract calls really cheap. Now let's look into policies. So we have here one context rule with the scope, the signers and the policies. Let's say we have three signers, two cryptographic keys and one G account. And actually the policies they modify they customize the

[14:00] how signers behave. Here in this case we require any two of those three signers to sign so, that the authorization passes it's the policies also can modify some other aspects of the flow here. In this case, we want those rule to be enforced only for once per month. So, that like you can for example pay for a subscription. So policies are external contracts as like verifiers. The verifiers are external. So policies are also external contracts. Policies can be stateful or stateless meaning they can map some state for a specific account and context

[15:00] rule. They can be shared across many different accounts or can be tied just for a specific smart account. And the other aspect is, that they have a four stage life cycle. Which is visible from the interface, that those policies must adhere to. Now. If we look into this spending limit policy, it is let's say it's a stateful policy and it is shared across multiple smart accounts. When this policy is added to a context rule, the install hook is called and this in its the storage for the calling account and sets the amount and the time period. For example, here we'll have 100 USDC and one month. This is the in it params, that are pass can enforce

[16:00] is just a read function, that is invoked every time the evaluation loop runs. Enforce on the other hand it requires authorization from the already installed smart account and modifies can modify the storage and can emit events. Uninstall is called. When the is removed. So we are cleaning up the policy storage. So install and uninstall are used only once can enforce on every evaluation loop and enforce. When context rule is matched. So these are the main elements of smart account and yeah to sum it up we have we can have up to 15 context rules per smart account and each context through contains signers and policies.

[17:00] So let's see some use cases. Yeah the most like trivial one is the multisix threshold bas based or like the weighted multics. We can have with this u setup we can have time limited app sessions. For example you install context rule, that is specific for a specific app and it's valid just for one day. So you don't. So you can interact with this app without needing to approve any further transactions. You can add for example the keys for AI agent or bot to as a context rule and allow it to spend some like limited amount of your assets. So it can trade for example and you don't risk to get wrecked or

[18:00] you can subscribe for some services. So yeah let and here let's see how the subscription the flow the user flow for a subscription will happen. So I have a smart account and I have the sudo rule like the super admin rule, that is has a single signer my pass key and there are no policies and it's valid forever. Then I'm going to u some dApp and I want to subscribe to a service. The dApp prompts me to install a context rule, that contains the scope of it is the USD contract. Because I'm going to pay in USDC. The signer is the D pub key. And the policy is some spending limit polic

[19:00] policy, that limits the spending for up to 20 bucks per month and I'm subscribing for one year. So this is the single transaction I have to do u in order to subscribe for this service. And from this moment on the dApp developer for example they can use the OpenZeppelin monitors to subscribe to the install event on this policy and. When this gets triggered they will with a relayer they with the opposite layer they will charge the user smart accounts every month 20 bucks. So the key takeaways this framework is context centric framework. I will compare it as the I'm comparing it very

[20:00] often with the web to login experience. For example. When you are logging it with your Google account or your GitHub account like you authorize the third party with some specific permissions. We grant some scope permission. You don't grant the whole access to your data. But just to very like scoped permissions. So we are composing authorization intents through those context rules, that contain signers and policies. Another very important aspect is, that signature verification is not hardcoded into the smart account. So it is this is very flexible and very scalable and yeah like this framework enables programmable authorization in, that manner.

[21:00] manner. So yeah. If you want to play with it I'm inviting you to go to our repo and to check our docs. And yeah I'm pausing it here for questions. If there are any. Great. It it was really interesting. We have seen a lot of interest in using pass keys and I think there's. So many ways to do like there's. So many capabilities in Sora for authorization. But it's also complicated. It's not it's not straightforward forward and easy. I think the wealth of opportunities to create custom policies and authorize your users in different ways. I think it's great. But it's also a little bit complicated. So, the framework you present here makes, that a lot easier. I

[22:00] think this will be a great way to add a flexible authorization to your dApp. So very interesting to see. I think I'll drop the link to the repo or to the documentation. But. If anyone has any questions, I think yeah, Elliots has a question here. Yeah, did you say, that Ozair can be used to index track additions removal or Yeah. Yeah, definitely. I mean you there are some events, that you can subscribe on subscribe for those events on the policies or on the your smart account and yeah do yeah trigger some actions according to whatever you want to do. one naming concern, smart account

[23:00] will likely overlap with Stellar accounts and could confuse the idea, that this is a contract. Mhm. Yeah. yeah. I presented why we ch why we went with smart account. yeah. Mentioned, that this is this may seem a better fit for yeah this kind of entities Stellar accounts you mean the classic Stellar accounts I yeah I suppose this is what you mean. But yeah I a smart Don't Yeah. We have to give it a thought. But I think we can it can

[24:00] be disting distinguished well enough. So not to be confused. It would be great to include a 15minute demo of building an actual d. Great suggestion. [laughter] I'm taking it. Yeah. Okay. Then I'm passing it to O. Right. Hi again everyone. I'm going to be presenting the world token world and also RWA. So let me share the screen. Let's do entire screen. Please tell me. If it's successful. Because I don't see the streaming tab right now. Yep, we see your presentation.

[25:00] Great. Great. Let's try slideshow. So, what's it, that I'm going to be talking about? It's a uniform interface for integrating with various yield generating strategies also known as ERC 4626. If you are familiar with the Athereum ecosystem. The problem tokold solving is let's say you have a th00and USDC and what are you going to do with this? You can lend it, for liquidity or you can stake it, right? But these are all the options you can do or you can have a manager of your funds for utilizing the best option out there. But for every manager you will have

[26:00] different problems. There is no composability. The UX in general would be bad. So, vault tries to standardize all these and it still can be managed. So, this is what we are trying to do. So, you deposit your assets into the world. The world tries to utilize your assets in the best way and earn some interest and you will get shares in return. And you can always do transitions between shares and assets. You can convert them interchangeably. So how do we calculate shares and assets? So let's say you deposit your assets and you will get shares. The basic formula for, that would be we

[27:00] will multiply the deposit assets by the total shares currently in the world. And then we divide the this result by total assets in the world and, that whole result will be your shares. This will be very important. So now, that I'm going to do some basic math. But it's very basic. So don't be scared. First action Say Alice deposits 100 USDC into the vault. So for deposit assets it's th 100 total shares it's again 100 and total assets is 100. So let's say 10% yield is earned, and now the asset amount per share has increased. So previously one asset was corresponding to one share. But

[28:00] right. Now since the total shares have not changed it only the interest rate increase the total asset amount in the world. Then this ratio should change right now. If you provide one share you will get 1.1 asset in return. Because one 10% of interest rate, and now Bob say Bob deposits 300 USC and we do this calculation and Bob will get 272.73 shares in return. So it's not one to one mapping as in the case for Alice. Because there was 10%. And this is still fine. Because if you multiply the shares by 1.1 you will get 300. So it is

[29:00] still fair. And let's say another 10% of interest has happened, and now Charlie deposits 200 and the amount for shares would be 165. The problem is in this previous slide is we have these decimals, right? This is not an integer. But it's kind of a floating number. This is problematic. Because how do you handle 3.33 shares for example? You cannot. So for shares we round up or down. When we do we round down. When do we round up. So let's say you are minting or depositing depo depositing we are rounding down your number of shares so, that you'll get slightly fewer shares than the exact ratio. The reason is

[30:00] world cannot overmint shares and we have to protect the world not the users so, that attacks won't happen. So this is the same this rounding down goes for minting and depositing and the opposite one rounding up goes for redeem and withdraw operations for gold, which creates another problem, which I will demonstrate right now. Let's say okay this is the inflation attack. There is couple of versions of it. Let's say the attacker deposits one's troop. So he minted a share and right. Now one share will correspond to one's troop only. Then the keyword here is donates. It's not deposit. So since it's not deposit, it only increases the total asset amount

[31:00] but not the shares. So it's basically I'm just giving away this money to the vault and I'm not expecting any shares in return. Why would someone do this? You will see the reason. And. If you convert the USDC to stroops you know there are seven decimal places in Stellar. So we added after 10,000 seven more u zeros. And then we added the previous ones troop you will have this number for total assets, and now alice deposits thousands troops so. If you divide thousands troops to this total asset amount you will get something really small like 0.00001 or something like, that and this will be ultimately zero. Because of the rounding down, that I explained previously. So basically Alice deposited some money, which was non zero. It was

[32:00] thousands troops. But in return she got zero shares and. If the attacker redeems their shares they will get all the money basically stealing Alice's troops. The other scenario would be in here. So let's say again this the first two scenario are the same attacker deposited one troop. And then they donated 1 thou 10,000 USDC and after, that say Alice deposited 10,000 USD. So it's almost a half of the total assets right. But only one stroop short of it so. If you do the calculation it will be somewhat like 0.99999. But since we don't have any precision for the decimal points, it will again be round down to zero and attacker would steal all Alice's money like 10,000 USD

[33:00] due to this rounding down behavior. So this is the inflation attack. This is not only for our implementation. This attack existed through all ecosystems and fortunately we have a solution for, that. The most common one is decimal offset. So instead of this regular or the straightforward calculation we also add an offset to the power of 10 and it will be something like this. So. If you deposit one stroop instead of one share you will get this amount of shares. This is up to your decimal offset. So let's say 1 2 3 4 5 6 7 8 9 and in this case you will have nine for the offset and you will get this amount of shares and let's say for the same attack the attacker. Then donates 10,000 USDC

[34:00] they won't get any shares. Because it's a donation. Then Alice would deposit 10,000 strooss it would have been this small amount previously. If we didn't use decimal offset. But since we are using decimal offset Alice will get one share and attack won't be attack won't resolve. So basically there is no attack due to this decimal offset any questions about vault and I will just stop presenting and we'll move on to RWA after questions. By the way, maybe we can also share a link for the world implement. Yeah, just maybe we also want to shout out to someone who helped contributed to the

[35:00] implementation. I don't know. If he's on the call, GS Maxi from Sentinel F. So yeah, he helped with this implementation. Yeah, laid the groundwork and we and he also helped us writing the SE for world. We just got merged today by the way. So we have a new SE guys for the world. All right, great. Then I can continue with RWA. So for this one, I'm going to be presenting over some text instead of slides. Okay. is the is it readable or should I make it bigger?, maybe just slightly bigger. Yeah, I

[36:00] think this is good. Great. So RWA as you know stands for real world assets and it's more like a switch of contracts compared to a single contract. So it's more complicated and involved for the base RWA token. You can think of it like a fungible token. It has the same metadata and core functions. But on top of, that we have forced transfer, which the admins can force transfers on behalf of the users. We have freezing both address level and partial. Partial means we can freeze some part of your wallet balance. For example, maybe you have 2,000 in your balance and we only froze 500 of it. And address level is your

[37:00] address is frozen for every like transfer, mint, etc. Operation. So basically you are on hold. We do also provide recovery mechanisms in RWA. In case of you lose your private key. Then the authorities can recover your wallet by sending your balance to another wallet and also all the account related information of you as well. For this recovery of course you have to convince the authorities by providing the necessary documentation. It's not part of the RWA standard. But this is how it will work on behi behind the scenes. And you probably already know about pausable operations for the utility for other tokens as well. This is the same for RWA token. We can pause the operations for the contract. So this base token contract is going to

[38:00] be interacting with two modules or stacks. One of them is identity, the other one is compliance. Identity stack will be responsible from verifying your identity basically. But it's also very involved and I will get into details later. And the other one is compliance. This is mostly for hooks post and pre hooks for the operations and this is this exists mostly due to allow organizations or governments or etc to include or embed their own business logic into transfers and means and burn operations. So let's go step by step. The RWA token as I told you is the main contract and it

[39:00] it communicates with compliance and identity verifier. The compliance is managing five hook types, which I will dive further deep into. And the good thing about compliance and identity verifier is they are multi-token support, which means let's say you have a compliance contract you can share this with multiple tokens multiple RWA tokens. So let's say there is another RWA token here. It can also go to the same compliance contract. I will give this example, which I like. Let's say you have bank A and bank B in your country and since they are in the same country probably the compliance, that they need to oblige to will be the same. So they can use the same compliance in this case. Identity verifier again this can be shared across multiple tokens. It validates the identity of the

[40:00] investors of this token. I will dive this into later. So let's skip for now. If you go for the highle basics for the token you need to provide the name symbol decimals and initial supply very standard basic stuff. Same with the fungible and on top of the fungible we will have the freezing mechanisms. We will have a recovery mechanism. We will have force transfers and possible operations as I told you. So right. Now I already told about how this compliance and identity stack can be shared. So I'm going to skip this one as well. So let's dive into identity stack. So there can be multiple ways to verify identity. The one we provide, which is the default one is claim based. So

[41:00] you can think of it like I'm from Turkey and I'm a Turkish citizen and in this RWA setting maybe the residency is an issue. So I must have a claim from the authorities, that I'm a resident of Turkey. So I need a residency claim issued for me by the authorities. And one downside of this approach can be. If it is not encrypted. Then all the data for everyone since this is onchain data can be seen by everyone. So this is very useful. But also. If you care about privacy it's it may not be the best solution. So there are other approaches as well like you can do Merkel tree, you can do ZK email, you can do your own custom approach. We do not provide these by the way. But they are for sure doable and we

[42:00] designed the architecture in such a way, that this coupling here is not tight. But loose. So you can easily plug this one out and plug your own solution for identity stack. Sorry here. So basically you can replace the stack here and plug your own. So what do we provide for the default identity? We provide claim topics. These will be non customer anti-manual laundering etc. For the topics we limited the topics by at most 15. We also have trusted issuers. These are all separate contracts by the way. Like this is a separate contract. And the issuers, the trusted issuers will be able to sign claims on behalf of

[43:00] the users so, that the users can use these claims. And we also store the information regarding the identities like. If they are individuals or organization, which country are they based in etc. So the identity stack is managing all the claims and the topics and also the account related information like individual organization country information etc. The compliance one. So these are the hooks. This is much more straightforward. We have two pre hooks and three post hooks transferred, created and destroyed. So I will start from the pre hooks. Say your organization needs to run additional business logic for transfers. So before any transfer operation

[44:00] happens, you want to run some custom business logic, you can do, that. We have a compliance contract, which will call this hook. When a transfer is about to happen. And for this hook to work, you can have your own contracts. We will call them modules. [snorts] And let's say you have a module for can transfer. So what you would do is you would link the compliance contract to your can transfer module contract and this compliance contract will call your module on every time there is a transfer is about to happen and the good thing is you can deploy many contracts per one hook. So for example, you can have three contracts, that will be called for can transfer. But five for can create, which

[45:00] for be minting. This is completely up to you. We decided to go with multiple contracts due to audit auditability and also separation of concerns. So. If you just wrote your logic into this scan transfer. And then you wrote another logic in the scan transfer by pure code. Then it would be cumbersome to manage and debug. So, that's why all business logics separated into their own contracts, which will be called by a relayer contract or proxy contract is a better architecture. The same goes for these post hooks. You can have additional logic for all of these. And, that summarizes the compliance module. So what about the access control? You have few options. You can go with ownership model or role based access control. So it's completely up to you.

[46:00] And for each kind of operation you can assign roles have very complex role based access control architecture or very simple one again completely up to you. We. Now only provide one extension for RWA, which is document manager. [clears throat] enables you to attach some legal documents etc to your token. Of course, we do not store the whole document in the blockchain like onchain. This will be inefficient. We are utilizing the hash. And you can also add your own extensions to RWA. That will be it for the RWA. If you have any questions, feel free to ask. I see one question. Is RWA design based on any existing stars? Yeah, of course. So we work with tokenia and ERC

[47:00] foundation also in collaboration with Stellar included. So all these companies came together and based on the RWA proposal for the Ethereum ecosystem or general ecosystem we made it specific to Stellar. So we made some few deviations from the original proposal and most of our proposals to deviate from it was welcomed and it will be adopted in the original standard as well. So we also contributed to the maturity of the original proposal as well. So it's not designed from scratch. If that's what you are asking. Okay, great. This was three really interesting presentations and I think it's very aligned with what we see, that developers are interested in doing.

[48:00] yeah the pass key integration and use, that for authorization is something, that's very big focus on I think this framework you presented is going to help a lot of developers to create a robust framework for authorization using pass keys the vault is something we've seen an increased interest in a lot of developers want to build in a way to earn for the tokens, that the users are holding in their wallet. So very interesting as well and RWA it's also super aligned with what SDF is interested in. So I think this is a really this really hits right where the focus is from developer sites today. So super interesting and I think we did post all of the links. But but otherwise go to opensea.io

[49:00] And then you can also see all the documentation there. Let's see was one more comment. Yeah, I don't think there's any other questions. This is last chance. If anyone has a question. But but thank you both of you for joining today. It's super interesting to see all the work you're doing. And I personally I think it's super interesting to see some of the libraries you're building, some of the frameworks and some of the tooling. When we go out to hackathons and. When we talk to developers, that we see, that they're being used. I think, that's, that's the greatest part of it. So. So thank you everyone for joining and thank you two guys for being on here again and u I'm sure we will talk again sometime soon and follow up on the latest development. But thank you for joining everyone. We see you next week.

[50:00] Thanks for having us. See you.

[00:00] Hello and welcome everyone to this week's Stellar Developer Meeting. This week we are talking to OpenZeppelin and the primary focus of this week's meeting is the relayer service. So yeah please introduce yourself and we'll get into it. Yeah. Hi thank you. Thanks for having us. So my name is Dylan Kilkenny. A software engineer at OpenZeppelin and the past couple of months mainly working on the relay infrastructure, the plug-in systems and specifically the Stellar integrations. Hi. Hi, my name is Sai. I'm the engineering manager managing relays and monitors at opening. Hi, my name is Collins a site reliability engineer supporting the relayer u plugins, that you are about to present. Present. Great. Thank you. So we already talked a

[01:00] little bit about a just very high level overview in one of the previous talks we had with open selein. So, I'm excited about diving deeper into what it is, how it works, and what you can do with it on Stellar. So, please share your screen and let's get started. Okay, perfect. Thank you. One second. Okay, you can see my screen. Yeah. So what we've been working on the past few months what's kind of worked [clears throat] towards is this manage Stellar relayer service and like in a nutshell what this offers is a scalable high throughput transaction service for the Stellar network and there are a few components, that were involved in the making of this and of course the first of all is the OpenZeppelin reer. So I'm just going to go through like a few of

[02:00] the things, that got us here and like what it took to build this like first of all you've mentioned you've already spoken about like the relayer service. But just to go over quickly again the OpenZeppelin relayer is an open source tool and it simplifies the transaction management for multiple different networks including Stellar and what, that means is like it'll handle the gas it will handle the sequence numbers the reliability like the retries. If a transaction fails. So like this is useful for a number of reasons such as gasless transactions or automating transactions or like scalable workloads. But one of the valuable aspects of this type of tool is, that it's secure and secure key management is one of the most important features. And in the case of Stellar, we support KMS signing, turnkey signing, or local signers even. So yeah a couple of months ago or a few

[03:00] months ago we started working on a Stellar integration for this tool and in doing. So we. Now offer full Soroban smart contract functionality. So it allows users to deploy contracts through the OpenZeppelin relayer. They can invoke contracts. Then standard Stellar XLM payments. And like as I mentioned this offers this is included with KMS signing and turnkey signing. But there are some limitations to how you can send transactions through the Stellar network and one of, which would be the sequence number having I'm not sure how to put this clearly. But causing issues with scalability like high throughput transactions. And. So we were working towards developing some features within the relayer, that will allow the Stellar relayers to scale larger. And one of the features, that enabled us

[04:00] to do this was the relayer plug-in system. So in a nutshell what this does is allows us to extend a standard relayer with ex with further functionality. So from a developer's perspective, what you would do is write some TypeScript code and inside this plug-in, you would have access to the relay system for submitting transactions, signing transactions, querying state, etc. And you would still communicate to the OpenZeppelin relayer through the rest API. But you would be calling this plug-in directly. And in the case of Stellar, we've used this system for developing a channels plug-in. So the channels plug-in allows users to submit transactions in parallel and the key workflow here is, that we use channel accounts for building the transaction. So in this plug-in system in this spec specific plug-in called the channels

[05:00] plug-in we manage a pool of channel accounts and the user sends a request and we acquire a channel account. We sign the user's transaction with, that channel account. And then we submit it to the Stellar network with a fee bump transaction as well. So it's also gasless. So yeah parallel transaction processing automatic fee bumping and this includes an SDK client so, that users can quickly send transactions or pain painlessly and I'll give a demo of, that at the end of this anyway. But just to walk through the flow of what happens here. So from the client the user will send a request. The request goes to the relayer and the reer invokes the plug-in. The plugin. Then acquires a channel account. This channel account is managed by the realer, that I must say all of these accounts are managed by the realer. But the plug-in is able to lock one. And then sign a transaction with, that channel account. And, that transaction is the one, that the user sent. And we. Then wrap

[06:00] that in a fee bump and submit it to the Stellar network. Once the transaction confirms, we release the lock and we send the result back to the user. So the system is scalable by the number of channel accounts, that we have to offer. So. If we. If we put 200 channel accounts in the system, you can send 200 transactions in parallel with one user account. And just quickly on the account pooling system we have here. So the plug-in system behind the scenes is using Reddus to manage the pool of accounts. So an incoming request comes in, we try to lock the account. If it's available, we can acquire it, process transaction. If it's not, we try again on the next account. So it's pretty straightforward. And just quickly on the SD SDK client itself. So this is what it would look like for sending transaction. So we have this channels

[07:00] client and right. Now the base URL is pointing at channels.openzeppland.com, which isn't live yet. We're still working on getting, that live either tomorrow or by Monday. But this could also be you can also send this these requests to your own self-hosted relay. Right? So this doesn't have to go through the managed service, that we provide. So this plug-in is all open source. The open reception relay is open source. So anyone can just spin up their own instance and manage their own channel accounts. But we will be offering this as a service and man managing it all for you as well. So it's quite simple. Set up the client and to submit a transaction you in this case we're submitting a sorbent transaction. So you just provide the function XDR and an example of the response would be like. So so this is the transaction ID for the relayer and the hash for the

[08:00] transaction itself. So in the case of someone who is running a self-hosted version they would want to manage the channel accounts. So there is some methods in the SDK, that will allow you to list what channel accounts are available on the service and also add new ones. So. If you needed to increase the throughput you could add more channel accounts or. If there's some issue you can remove some etc. So yeah in a nutshell all of these things have come together and we're offering a Stellar relays managed service. So this would include the relayer service itself and the channel accounts plugin the SDK. But also the cloud infrastructure. So just a bit of a like a peak into what it takes to run this on the cloud. So we are using AWS Fargate for managing diff v a v various number of tasks

[09:00] running the relayer service and a shared reddus instance. So we have the same pool of channel accounts across tasks. And the client's SDK goes up through the Cloudflare proxy sends it down to the load balance balancer, which. Then distributes it to whichever task is free. So yeah, that's pretty much the overview and I can just give you a quick demo right now. But first, yes. So like this is just a demo script as we've already seen how you would instantiate the client and I have a little helper function here for building a sorbent transaction and here we pass the function in a to the client itself. So. So just want to point out first, though that in order to use the service you need to get a API key. So you can just call

[10:00] the domain channels.open.com/gen to get an API key. And for the sake of this demo, I'm just going to add the API key here and call the demo script. So this is going through the staging environment, that we have for the managed service right now. Okay. So the transaction is confirmed. Just to double check, that yeah transaction was successful. And just to demonstrate the parallel processing of this I also have a parallel demo. So, this is sending 10 transactions at the same time with the exact same account, that I sent the demo transaction with previously. It's just

[11:00] one account. And yeah, that's pretty much it. Any questions, let me know. Great. So, I'm a little bit curious about the managed service. Because it seems like of course depending on your use case, that especially for maybe testing it out, it seems like a lot more convenient to just try it out with the managed service. How how does, that work? How do I get set up with, that? So we are finalizing the documentation and the SDK today. So once we have all of, that documentation published on our site the your community will be able to access it and it's a pretty straightforward setup like as you seen with the demo. [snorts] yeah. Okay. Great. And and. If I want to run

[12:00] this on it is open sourced. I see, that I can run it on my own environment. What do I need? I saw you mentioned the Reddus database. Is there anything else I need to set up to run it? Yeah, it's a good question. So we in the documentation we actually have all of this listed out and we provided in the OpenZeppelin repo OpenZeppelin relay repo an example configuration using docker. So all with what someone would need to do is go into the repo and run, that docker config and it would spin up the service with the channels plugin already installed and everything's ready to go like all you need to do is start sending requests to it. But the OpenZeppelin real air like reddus is required of course you need the real air installed and all the various other dependencies. But there are some example configs, that get you up and running pretty quickly. Okay, great. Sounds pretty easy, though.

[13:00] what are the use cases where who do you think are going to use this the most? Any specific dApp types or any use cases, that you have in mind, that you think will adopt this? Yeah, look, I think it's super good for someone who needs high throughput transaction processing. And also the ga the gasless aspect of it is super convenient as well. So users don't have to worry about sequence numbers. So you can see apps like games or various other services, that might want to use it. But even you someone who wants to self-host this themselves, the it's open source. So you can extend this any way you want like the core primitives are there, which is gaslessness high throughput like sequence number management etc. And you can build on top of, that like whatever you need. Great. Do you have any I know you

[14:00] you mentioned, that the documentation and everything for the managed service is going to be available very soon. But do you have any examples of how to use it? I know you showed one. But do you have like a GitHub repo or an example library? So, So, we have a plug-in repo up right now. Just one second. So there are some examples in this repo. I'm just going to share it in where should I share it? Can you share it in the post it as a comment? Okay. Comments. I shared it in the private chat. Because I don't think I'm logged in. I'll just copy it over. So yeah, there's a pretty extensive overview of in the readme of this

[15:00] repo of how the plug-in system works for the channels the channel account. And once the service is live in production like it's only a case of being of substituting your local relay local host with the production URL and also I'm just going to share the examples from the relay repo as well and, that should give honestly with just these two things you can get up and running locally pretty quickly. Quickly. Okay, great. and this is the example in the relay repo. And there's also a read me in, that as well, which is extensive and it should get people up and running. Yeah, I have actually gone through the read me and taking a

[16:00] look at it and it does look it looks like the it's very detailed. So I just haven't I haven't tried to set it up myself yet. Okay. Looking looking forward to, that. Yeah. Well, let me know. If you have any feedback. I hope, that it's simple even, though I think it is. Yeah. Any any questions from anyone watching. Then feel free to post it in the comments. Carson, I just posted the documentation, which should be available on docs.openszprint.com. So, I just sent the link. Yeah, I posted it. Thanks. Great. Well. If there's no comments or any questions from Let me just check one more time. Doesn't seem to be the case. But it was great to get a little bit more information about the relayer

[17:00] and to see an example of how to use it. I think it's a super helpful tool and I think for. Now I think I will try using the manage version first u. When it goes live. It seems like an easy way for me to test out the tool. I don't necessarily need to spin up my own infrastructure for this. So I'll look forward to have an opportunity to play with it. And thank you everyone for watching and thank you all three of you for joining today. And please go check out the links take a look at it and yeah, thank you all for joining. Thank you. Okay. Thank you. Bye. Bye.

[00:00] Hi and welcome to this week's Stellar Developer Meeting with me in the studio here. Today I have Fernando from dop protocol and I can't exactly remember. When I heard about dop protocol for the first time. But I do remember I noticed, that my feeds in all social media like LinkedIn X anywhere this company just started to pop up and there was articles and they were going to conferences and I just got really curious about what's up with these guys what are they doing. So and of course they were attacking Stellar in everything they were doing being awesome ambassadors. So I started to read a little bit up on what they're doing and since. Then I've had the pleasure of meeting the whole team several times last time actually this week in Silicon Valley where I met Oscar. But met the team also at Meridian many other places. So I think it's a great

[01:00] opportunity to have them here in the studio and hear what they're up to, what they're doing and share with the rest of the community. So welcome Fernando and thank you for joining today. Yeah, thank you for the invitation Ken. I'm pleasure to be here. So should I just. Now continue with the presentation? Yeah, maybe just tell a little bit about who you are, how long time you've been working on protocol. A bit of an introduction. I'm Fernando Castillo. I'm currently the CTO of DOP protocol, one of the co-founders and our main goal. Now with the protocol is to be able to all of the infrastructure, that's not being funded to get funded by decentralized means. And. Now in

[02:00] this presentation hopefully I'm going to show a way on how we can do, that with token studio and with the other tools we've been developing. So first yeah what's the team a bit of also an introduction car and already mentioned Oscar he's our CEO he's currently at Silicon Valley doing the embark pro program with Deron University in conjunction with Stellar also we have Simone Spinola who's our operation and business officer and myself as I said already and also as a side note I'm finishing my PhD until Berlin. Now I'm in Germany currently. So it's a bit late for me. Now it's 10

[03:00] p.m. But I'm happy to be here and yeah. So what's the problem, that we are facing is, that in Latin America there are a lot of infrastructure operators, that are lacking fund and they struggle to scale. Because on traditional banking systems the they require to go to ask to the bank to. Then request for a loan. Then go through all the bureaucracy of the bank. But. Then also time moves and they need the money to deploy and to create this new infrastructure, that is not risky by itself. But maybe the banks consider is risky. Because of the type of size of the company maybe or the type of emerging market. So it's. But it's not, that the business itself of, that infrastructure is non

[04:00] investable or, that it will give money returns. So as I was saying let's imagine, that you are Mariano you are trying to get a traditional credit a loan for a bank. But this depending on the country also for example we've recently seen in Argentina how this country was facing high inflation rates or similar situation with Venezuela and other countries in Latin America with high inflation rates, that. Then this ties those loans to higher interest rates plus the risk on the country itself. So there's this problem of banks. Because of these situations not giving beneficial loans to these infrastructure operators and at the same time. If the

[05:00] infrastructure operator would go for example for a crowdfunding or a regular crowdfunding solution where they could go online. And then they could say okay let's get all of these people request this amount of money. I don't know, let's ask for $100,000. So we can build this power grid based on solar power. Then how. Then this operator could return or distribute the revenue, that this energy production is generating? And how could they do it in a trust trustworthy fashion. So all of the people, that were investing or supporting the project can give the money back or the investment. And just as a

[06:00] parenthesis latam infra operators are Latin American infrastructure operators. They are for example medium to small companies, that have this infrastructure projects. For example, a small or not. So small. But maybe a few kilowatts or 100 kilowatts of power into injecting into the energy grid. For example, a solar base or holic or there could be other type of infrastructure for example a data center or any type of infrastructure, that's not relying on a big company. Because big companies they wouldn't have this type of problem to access credits or loans from banks. So in our or what are we proposing as a solution we have this separated in

[07:00] four steps. One is to provide a tool for the operator to hand out verifiable data from their existing company or projects. So they can for example validate okay this solar cell is going to produce this amount of energy. Because it has this specifications. I can I have already bought them for this price or I have this revenue evidence for similar infrastructure pictures or proof of location for example for where is it installed the infrastructure and, that's the first part of okay how can we give some due diligence for example, that's the same thing, that the bank would go. When when this person goes to the bank. Okay,

[08:00] show me the papers. How can I know, that you are not going to ask for the money for an madeup project. But it's a real project and you're a real company, that was not just created yesterday. Then all of this information is naturally audited and revised by automated process, that are human le. What does, that mean? It means, that we check for example okay this is a receipt. But it has a digital signature. So it's not, that this invoice for example you get from another company paying for your service or for your infrastructure is making this up. But at least it's on the record it's on the ledger of the tax offices for example or the corresponding

[09:00] corresponding regulatory office in charge of invoice. And then so they cannot be made up and the same with the revenues or how other distribution processes have been made. And. Then so and the third part is okay how can we. Then get this decentralized funding into the hands of Mariano the one, that was asking for the funding. So for this is where we have the smart contracts, that take care of this operation where the supporters for the project can support Mariano's infrastructure project. And then he can gets the fund to install or do the setup for their project. Then the same once

[10:00] Mariano needs or is going to pay back with the corresponding interest to their supporters. Then the smart contract also takes care of, that with a decentralized distribution, that's transparent and it's auditable for all of the stakeholders. And this is currently on a suite, that we're calling DO token studio. There basically we have two types of users. Now we're thinking of a third user. But the two main users of you probably have noticed already are the infrastructure operator and the investor or supporter. On one side the infrastructure operator as I was saying takes care of uploading the information the device information how this is

[11:00] technically behaving how is the type of revenue it's going to generate distributions or revenue distributions every month every week or every quarter or annually. And those are the those sets the expected APR, that the infrastructure operator is offering. Once this is done. Then this goes into the blockchain. So it's committed, that okay this is the information we're committed for the posterior auditing. And then as I said this is reviewed the authenticity and the validity of the information maybe you can just have a moment there's a couple of questions yes. So yes actually well going for

[12:00] the first question what are latam in front of operator Latin operators are Latin American infrastructure operators. They are the ones, that want to get funded. RWS and infra are inherently illiquid. How do you address, that? Yes. That's one of the innovation, that we are doing is, that we are not tokenizing maybe, that was one point, that I was missing is, that we are not tokenizing the infrastructure by itself. But what we are focusing is on the revenue this infrastructure is going to generate and, that comes with a higher risk obviously. But then it balances is the higher risk with the with a higher APR. How do you solve regulatory

[13:00] compliance low issues? Yes, this is I really don't think I will be able to address all of those regulatory compliance issues. But I can say, that. Because of the nature of the project, that as I was saying earlier we are not tokenizing an asset and it itself. But we are working with the future revenue it will produce, that can solve other type of compliance around regulation issues. But also it's important to mention, that this is very local and depending on each country finally. So it will it won't be the same for example the same in the US and here in Germany or in Chile okay. Then wait pay is this a loan or is it a revenue participating in the project

[14:00] project Yes. So this can be considered as m multiple things. So in the end is the this revenue for the what the infrastructure generates, that's as I was saying is what's being kind of tokenized. So. But then. If you look at from a different perspective. Then or the traditional perspective this could be taken as alone from the chat file. I see Oscar was as. Now is there I don't know is who review central yes I think, that's those are most of the questions. Then yes this is obviously this is a regulated service it cannot is not the

[15:00] wild west. But now I will focus mostly on the technological part of how we are addressing these issues. Because for compliance I think we can take a bit longer to answer all of those questions. Okay. So I'll continue then. So with this we are offering multiple features in this platform, that this we can submit multiple type of evidence. This is based on the concept of trusts where we are producing evidence for all of the stages and all of the interaction the infrastructure and the operators are generating and producing. What does, that mean? For example. When the operator the first one I mentioned it already, the operator can submit, okay, these are the technical

[16:00] specifications or this is an invoice. But. Then we can get more complex evidence. When we start to aggregate different types of evidence. Because one in invoice alone for example would mean okay you will receive this payment in the future or you are receiving it. Now but. Then to do the accounting evidence for example for, that we need to connect with the ERP of the business and, that's more complex than just verifying a single invoice. Then humanoled guided integrity check means, that even, though this project or what we are doing is highly depending on automatization automat automation we still require people in the loop. Personally looked at. So

[17:00] everything goes yes as I was mentioning earlier on the accord regulation. Then will rely on the onchain verification module. So all of the transactions especially for the stakeholders, that are supporting the project or the infrastructure operator they can see how all of these actions are being verified and chained how they are transparent with the respective proofs. And finally as every project is different all of them will have a different type of scorings for and with this will represent basically from high risk project to and higher APR and lower risk and lower. Therefore APR

[18:00] and in practical terms how is this the overview of this smart contracts in particular for the token studio is, that we as the or the infrastructure operator deploys the splitter contract and there we have different functions to define the shareholders how are they going to do the withdrawals every how often are going to be the distribution events and to, which token is this binded regularly we will be working with USDC. But for example this could take other type of tokens. If that's how, that project is defined. But most of most

[19:00] of the time we work with USDC and in simple terms it's super s I think it's super easy to understand. If there's one chair holder or token holder with the 10%. Then once the distribution take place all of the revenue, that was generated and was deposited in into the smart contract. Then it will go a 10% into the one, that has a 10% of the tokens. So on how this distribution flow goes is, that first we have the admin, that communicates to the distri to the splitter contract, that's going to do the distribution what's the token address. Then this is

[20:00] verified inside of the smart contract. Then it verifies. Then check the current balance for example are those Are there 100 tokens to distribute. And then in each case it's the loop checking on the token holders and the respective balance and there, that's how it does the calculation and this goes. Then into the storage class where finish where it's finished with the distribution. It's really straightforward. Then for the withdraw. Then the each shareholder or token holder goes into the splitter it does the prospective verification check with the storage what's the current allocation. Then decrease on the

[21:00] storage part. Then communicates directly with the token does a transfer with a good successful withdraw. And then it goes again to the threshold and at the storage level this is just in case I'm presenting it this like this. Because we are currently going under the respective revisions and auditings. So it's it cannot be everything public. I mean this can. But not the code itself yet. And. Then we have the cher data key, and the allocation data key, which basically defines how is the charge for each data holder, who's the admin, all of the security,

[22:00] what's the allocation for each token holder and. And then how this can be allocated each time the distribution goes. Then here on the security level on how we are defining we are taking this very seriously defining the access control policies admin only function the authentication the lock on contract the transfer contracts also we have our internal scripts for doing the a to have a deployer and do an anatomical operations. So we don't run on front run is front running. Then we have allocation limits some validations and. And so on. And this as a first case we've presented this to investment of returns

[23:00] for the investors or supporters of the project of infrastructure. But this for example could be used as token vesting models over team members on time for similar to the revenue trading for a DAO treasury or for reward distribution. And. Then for the particular the feature, that were missing for before are, that this is a secure and transparent way on how this distribution method is performed. Because all of the transactions are done on chain and, that these transactions are. Then proportional to each one of the supporters. So yes, thank you very much. I hope I didn't pass on time and

[24:00] we have a few questions. In in the chat I think. Okay. I think the answer yes. So where I was I left is it either alone with interest or is it at your particip Yes. As I said, it's more of a chair participation of the project. I was making the loan with interest at the beginning to make the analogy with traditional banking settings. Who will review centralized entities? Yes. I mean this needs to go all of the businesses and infrastruct, which are the infrastructure operators in this case goes into a know your business process. Because this has to also go with antimony laundering policy and all of those regulations. Does, that mean, that the entire review

[25:00] process and due diligence is no the proofs or more than the proofs the hash of the proofs and the evidence are stored unchanged. Because we cannot just publish yeah accounting states or financial states from companies on chain. Is it really 100% of the project's revenue or is it some Yes. So. When when we consider this there's for the for example the energy production, that a solar panel is going to generate it's going let's say it generates 100 dollars per week. Then from this there's a minimal amount, that's defined during the creation of the project, that needs to go by to

[26:00] the operation itself. That could be for example 30% or 20%, that depends on the project. So it's finally on the discounted from the operation then, that's what goes into the what's the distributed how could you manage. Then state expiration. If you are storing hashes on chain do you mean like. If a proof is expired for example I'm not to, which state do you mean? World matias. Yes. So, that is so. When proofs are verified

[27:00] it depends on the type of pro proof and there are multiple risk. When you verify proofs. Certainly one is for example using old proofs or reusing proofs. Other is just trying to use past evidence as newly evidence. But all of those parts are very part of the ver, that of the offchain verification. And. When the onchain verification happens this proof is has been already through this process. Yes. So currently the guarantees where do I pass this? Ah yeah let me answer this first. Yes. So there's currently

[28:00] a new feature we want to do is to actually put some collateral, that can give stakeholders more guarantees. So ina. So we would. Because from the beginning this sounds more like okay we will we could be giving random money to a strangers stranger, that maybe at, that point everything was true. But then still did a rock pole as you mentioned and. Therefore we are creating this other collateralization mechanisms but, that's not defined yet. But, that's why also on the first stage of this we are focusing only on companies, that we know, that can give this guarantees and are not a meme company for example. So

[29:00] that's one really important point. So Stellar asset or so. So. So the tok the Stellar the artist this token actual Stellar asset or Soroban tokens. So as we as I was saying it's the token, that's distributed is a USDC and how the asset of the token holder is also a token. Because why and why not a regular seller asset. Because we needed to create some extra functions, that were not into the assets. Okay, great. I think you got caught up on all the questions. It's great to see, that there's. So many questions. So much interest in what

[30:00] you guys are doing and how you structure it. So yeah, it was great. If there's no other questions. Then I guess we can stop here. But thank you so much for joining today. I think it's super interesting to see what you're doing. It's I kind of like these type of projects, that are not the typical projects we see. It's definitely using tokens and using the platform in a different way. I think, that's, that's super interesting. Yeah. Yeah. Just let me add there's a last one. Yeah. Yeah. To to answer, that last question. Yes. One of our also our current goals is to bring liquidity from other blockchains in particular from Ethereum based blockchains liquidity and, that's

[31:00] because actually we're not only based on working on Stellar. But we're also working on base and we see this potential from bringing more liquidity to Stellar from base through this infrastructure projects and yes we are taking a look at near intense. Great. Well, thank you for joining everyone and thank you for joining too, Fernando. It was great to catch up with you and I'm sure I'll see you at events around the world like I have this the past year. Thank you for the invitation. It was a pleasure. Yeah. And and. If anyone else has any questions, I'm sure you can reach out to the team on Discord. I think one of the things, that's very interesting about this is, that brings up some use cases and some things, that are, that

[32:00] that raises some questions. Because maybe we haven't seen, that before or maybe we're not used to thinking about tokenization in this way or using the platform. So, a lot of great questions, that really I think you had great answers and it's interesting to see how you're building this. So, thank you everyone and see you again next week. Thank you. Bye.

[00:00] We're going to talk about a protocol upgrade, that we're pushing for next week, that is around fixing a bug, that was discovered last week. So last month we pushed out whisk, which is Protocol 23 protocol was upgraded by a vote from tier one validators. And on Thursday last week, a week ago, we discovered a bug in the protocol. We've we worked the following two days on containing the bug. Which affected state archival. So basically some small number of ledger entries, that were archived with the wrong version. So the not most recent version and. When they were restored the

[01:00] restoration allowed for the non-most recent version to be restored. The total number, that was actually affected is less than 500 ledger entries. 478 to be exact. Out of these only 84 were restored. So these are ledger entries, that were actually restored to the Navos recent value. Last week, Thursday, Friday, we worked with tier one validators to contain this issue, which means, that we've set out an emergency SLP to avoid archiving more u more ledger entries. We also manually bumped all entries on the network, that were about to expire so, that they don't. We. Then issued a released a new version of Stellar Core, that was patched in order to ensure, that the affected

[02:00] ledger entries cannot be touched so, that any state inconsistencies remain quarantined. Quarantined. That happened last week on Friday and from, that moment on we've been working for the past week since Friday night on communicating with validators and with affected protocols to understand what the extent of their issue was. We've also suggested a few protocol upgrade options in order to rectify this. And the protocol option, that is overwhelmingly the most popular is the less intrusive one, which is to obviously fix the bug to fix the archive. So all the ledger entries

[03:00] that were archived and not restored will be fixed in the archive and so. When they're restored they will be restored to the correct value. But with regards to the ledger entries, that are live and have been restored incorrectly we will not be addressing them on the protocol level. But we have ensured with all affected issuers and protocols, that we've been communicating with. We're talking about around 20 protocols. That they do have ways to rectify this on their end. So for some issuers, it just means, that they need to adjust the supply to make sure, that it's it reflects what's on chain. A lot of the state changes have actually been benign and not had any meaningful impact. and some protocols have had ways to, kind of like upgrade out of these issues. And so I am going to stop talking

[04:00] for a bit right. Now and, happy to, take any questions. Justin, did you guys hear all this?, yes. It sounded great. And right. Now I'm just going to paste the blog post, that we just released, that explains this a little bit in the chat over here. So. If you want to sort of read a version of what Tor said, it's there. We also you'll see, that there's a link to a CAP there. The CAP is the suggested change, that Tor was talking about and I think Nico is here and will join us on stage in a minute to talk through the CAP. But first there is a question from Jome. This was completely random. So some entries were correctly archived and restored. Restored. It's not random in the sense, that this was not arbitrary. It was deterministic in the sense, that all protocols all validators actually behaved exactly the same. So the network did not fork based on this

[05:00] behavior. It was consistent. But it required a very kind of like specific arbitrary chain of events, that relate to how whisk handles live state prioritization between the bucket list, which includes all the live states and the evicted state. So not random. But definitely also not trivial to identify. Does, that answer your question? Okay, it looks like there are I mean I see someone saying I am late. How bad is this? As Tor pointed out and you can read, that blog post, that's posted above, this bug was discovered by Elliot friend who's here on this

[06:00] call. Who's who is a Senior Developer Advocate at the Stellar Development Foundation and he discovered it. While he was you know doing some work to get ready for a hackathon, that's coming up and you know short it did not take long at all and you can see the timeline there for there to be for the issue to be very quickly quarantined and the fix will be rolled out pretty soon. So. While it's a bug, that, you know, is very it's a serious bug. The impact is something, that we've like evaluated, talk to everyone who's been impacted about and, you know, it's definitely contained at this point. So I'll let you read the post and decide how bad it is. But my answer is I think, that the response has kept it pretty contained and has cut it off very quickly. But the other. So at this point we have I'm going to post here this is cap

[07:00] yeah and as Dimma points out above I mean you can read what he wrote in response to your question too. So, I know there's a lot of discussion going on. But at this point, I also think it's important to take this opportunity to look at the proposed solution, which is what I just pasted there. It's a Core Advancement Proposal 76. And we have some people from the core team to walk through this. Nico, do you want to do it or is it better. If Dimma does it? I can Yeah. Take a first stab at it. It. Guess hear me? Okay, perfect. All right. So yeah. So like at a high level what the CAP is describing is first what is actually in scope for the to kind of mitigate this problem. So like Toma was explaining earlier there's actually two

[08:00] types of entries, that u, that were corrupted. They both started in the same way where they basically entries got moved from the live ledger state into the archive and during, that process entries got corrupted. And then after, that some of those got restored and at, that point they were restored for all sorts of purpose. It could be for just reading them like a you know a lot of entries on in Soroban are just accessed for reads like a WAM for example is an example of, that. Others were also accessed for modification. And yeah. But what the CAP is putting in scope is the only the first category of entry. So

[09:00] basically the ones, that were moved into the archived and kind of stayed there. And and the solution as part of this is to basically go and take the value, that was supposed to be in the archive. And then override the archive with, that expected value. So the fix itself sounds fairly simple. U. Because it is the u the bit of a challenging part here is how can you all of you guys can trust us, that this is the right list and there's actually quite a bit of work, that went into this in the CAP. So the there's a full list of basically of in a CSV file, that you will find where you will see for each of those entries, that end up in the archive we have the ledger number

[10:00] where. When the entry got moved into the archive corrupted like I said. So in, that case we actually have in this CSV the value of the entry as it was at the moment it was about to get moved. And. Then we also have in the same row like the value, that of the corrupted u entry and. And then what happens. When we are going to u follow the this CAP right is the core is going to scan those entries one by one and see the ones, that match the corrupted state in the archive and then. If the. If it's there it should be. Because we also froze restoration at this point. Then the value will get

[11:00] replaced by what it should have been. So, that's kind of like the first part I guess of this fix. There's another one, that's this one is actually related to this second set of entries, that actually got restored. That's for the total lumen supply. They were about I think it's like three lumen around, that like of accounting discrepancy. So in the proposal what we are saying is, that well some lumen got burned in during this event we're going to just kind of for accounting purpose move, that burn as a into the fee pool. So, that's kind of what the mitigation is for, that. So in terms of like the like I said like the. So this is

[12:00] the CSV file what the what core is going to do as part of like in terms of like actual steps right to restore the entries in the archive to the right value in terms of like verification. So there like a few things, that can be done. There's first there's the list itself. This one was computed by instrumenting core and replay all those events, that are around eviction. Eviction. The version of core, that will go out with the protocol change will have this instrumentation and better than, that actually it will also have a way to basically use, that CSV file and check, that the modification those changes are the only changes, that happened in the in, that time period. So it's kind of a

[13:00] double you know double use in a way where the CSV file you can use it first to see what is the full list of impacted entries to also see, which ones will be restored and you can also use, that as a way to understand, that what will happen with Protocol 24 and also, which one, which of those entries will not be impacted by this protocol. Upgrade in, which case they will stay corrupted as they are today on the. So those are like the entries, that are in yeah, that got restored. So those are like live entries. So maybe I should stop here for a bit see. If there are like specific questions I just want to add one thing. Because I got some questions on this earlier today the patched version of core, that is currently in production by tier one

[14:00] validators bans every transaction, that tries to touch any of the state, that's been corrupted. That's those 87 ledger entries. So. If for some reason anyone on this call or anyone you're talking to is unable to get a transaction in and is getting a timeout. Because of just getting timeout. Then this might be. Because you're trying to touch, that state. And part of Protocol 24 is removing, that ban. So, that ban is supposed to be removed as soon as the protocol is in effect. Which is right. Now scheduled for Wednesday next week 5:00 p.m. EDC. And again, that's a small number of ledger entries, right? Yeah. Just for just for context,

[15:00] you know, ledger Stellar is a database. You can you know think of these ledger entries as row rows in the database. And Stellar has around 47 million rows in this database. Out of, which 80 87 have these issues. There's a question will Protocol 24 contain new ZK features? No. The the features, that were planned for Protocol 24 will. Now be pushed to the next protocol. Protocol 24 is just a stability upgrade. Mootz has a question to clarify this CAP focuses on managing the existing corrupted entries. Was there a cap/update, that could be shared, that

[16:00] addresses the root cause of generating corrupted entries? Yes. Definitely this Protocol 24 will fix the debug. Yeah, actually I thought we included the fix itself in the CAP. So. If we didn't, I'm sorry about, that. But yeah, it should be there. There. Yeah, Yeah, like we could add it to the CAP for posterity. Like we typically don't include bug fixes in the cup. Because it's like two lines fix and you do not do anything new from the protocol standpoint. Standpoint. Like you already have a CAP defined for this feature. The issue is not the protocol. But the issue is, that implementation was incorrect. But the CAP itself is CAP-62 I believe. So you know we got added to the CAP like

[17:00] that we also fixing the bug. But it's not, that historic historically done for the bug fixes. Sorry about, that. Does, that make sense to you? Of course, I asked as several people are typing. Just to confirm, will this require a network pause? No. I see there are some questions about the features, that were planned for Protocol 24, that will. Now be for Protocol 25. If you scroll up and you grab, that CAP, you can actually look at the different proposals for things, that relate to ZK features. And I think you can dig into those. But for now, I think we should

[18:00] kind of keep this focused on the current situation, the current upgrade. Because I think it's also important. I mean, Nico, you sort of talked through a lot of this. But can you just tell us what happens next? So in terms of you mean like implementation. So and all this. So like the team already has been very busy actually implementing this u this protocol change. Given the yeah the urgency of getting this voted as you know as soon as possible so, that we can you know like Toma was saying part of this is also allows the network to unblock those entries as well. So yeah it's a it's there are many reasons, that why we want this to

[19:00] happen as quickly as possible. The. So yeah in terms of next step what's going to happen is, that. So we are going to have builds of Stellar Core and the rest of the like platform type of software, that depends directly on Stellar Core released by, that's like Horizon RPC galaxy. Yeah. Yeah. Yeah. And. Then those will be released by Monday. And. Then what we expect to do is Tuesday will be the test net upgrade to this new protocol. And then we'll get the vote to with the validators to be scheduled on Wednesday and hopefully given, that we did a lot of work already with those validators the vote will actually be approved and meaning, that we'll be back in business in general

[20:00] at, that time. And so just in general to prepare. If people run infrastructure, that basically has Stellar Core embedded in it. So either Stellar Core for a validator or those things, that are on the platform side, that Nico mentioned RPC Horizon galaxy you'll need to upgrade right before the test net. If you want to your infrastructure to work on test net and before the mainnet floats. That means you have to like pick up the fixes, the new releases on Monday. But unlike other protocol upgrades, this doesn't require everyone to install new SDKs. Correct. Correct. That's correct. Yeah. It's only there's no impact to the XDR in particular. And. Because of, that, that means, that applications in general don't actually need to do anything. It's basically like about picking up the It's already about picking up the right version of core at

[21:00] this point. The reason we have to upgrade systems like RPC and Horizon is. Because there's actually a check in the those systems, that check, that the protocol version, that core is, that the network is running on. So in this case it will you know after the vote it will switch to 24. 24. So like the systems are actually built with a safety in place, that they will only ingest data from a protocol, that they understand. And. So basically this is this constant and, that's the only, change really in those downstream systems. Systems. I'd like to answer Adam's question. So Adam asked. If a reserve asset is added to the pool they are tokens created inside the contract it won't require a deposit of the actual assets to reconcile. So we did have a few of these ledger entries ended up being

[22:00] ledger entries, that relate to liquidity pools. And the remediation u is a bit different between different pools and different assets. So for some assets, that changed imbalance. If they have a centralized issuer it was fairly simple to basically add the backing asset and offchain so, that they can reconcile the issue. In some other situations it was almost trivial to burn. If if there was a eronous credit for some pools some liquidity pools are sorry are implemented in different ways. So for example the Aquarius pool is implemented in a way in, which actually adding an asset doesn't change the price or anything. Because

[23:00] Aquarius has like internal tracking of the reserves. And so manually adding a reserve doesn't actually impact price and, that added balance is unusable. It's not like, that for source swap. And so it's really different assets and different protocols like found different ways to fix it. But again we've talked to pretty much every affected protocol and issuer and ensured, that all of them have ways to fix the situation in the context of these 77 ledger entries. Sorry, I said the wrong number before. It's 77, not 87. And I can't stress enough how helpful every protocol and asset

[24:00] issuer have been. I think we started reaching out Friday night and Saturday morning and we've and everyone has been extremely understanding and collaborative and it's awesome to see the ecosystem come together like this. I see there's still some people typing in the chat. If the questions wind down is I think a lot of it's just sort of comments. I'd say. If you have a question, get it in now. It's telling me OrbitLens has a question. But Orbit asked, "Do we need to update the RPCs as well?" and George from the platform team said yes.

[25:00] Yes. Yeah. Is there a technical reason this must be a protocol version upgrade instead of a patch release? Well, yes. like it's a it's an update to the ledger and. Because of, that it has to happen basically on all machines at once. It was going to be like a patch release. yeah, we would only be able to kind of the change would happen basically on like whatever machine is running right on, that with, that patch version.

[26:00] Is this recorded for playback, Carsten? Yes, correct. Yeah, I would say in general. If you know you have further questions or it's a good idea to read, that blog. It just came out I think an hour ago, maybe even less. And also to read the CAP. and in general, I think. If you're interested in these kinds of issues, make sure, that you pay attention here or sign up for the Stellar Dev mailing list. Make sure, that you pay attention to the CAPs. we do try to be as transparent about any of these changes as possible. And obviously we you know through all of this we not only couldn't make a decision without all the feedback from the ecosystem about what to implement. But implementation is just one step in governance and the actual adoption of a protocol change on the network requires validators to vote it

[27:00] in. So in all of this we always are trying to talk to people including you know this call. But also online and various other platforms and we're trying to like put the work out there in a place where you can examine it and understand it and we certainly encourage you to do, that. In fact, with the CAP, there's a whole process for Core Advancement Proposal and as part of it, we put them into Final Comment Period. And. Because of the urgency here, we just fast forwarded this to Final Comment Period. And. So it's going to stay in Final Comment Period, which means, that you can write about it on the Stellar Dev mailing list until the time, that the validator vote happens, which should be on Wednesday. So, this CAP is officially in Final Comment Period. You know, we definitely urge you to take a look. If you have anything to say to add it.

[28:00] Orbit is pointing out the short timeline. Yeah, it is a short timeline. I agree. yeah, like the reason we are still kind we think this is best for the ecosystem is, that we are actually giving at this point like yeah like a you know almost a week notice, that this is coming. So the people should be able to prepare ahead of you know and allocate those two days for upgrading their infrastructure. Infrastructure. I think given the severity of having those entries blocked I think this is the probably the right trade-off.

[29:00] Nico, can you what will the experience be like for somebody, that needs to upgrade their RPC? RPC? Will it be difficult? So like Yeah. No to upgrade this is basically just like doing a regular kind of a software package update. U there's really no other steps to take. And for people, that don't I think you mentioned, that earlier the this, that core instance will get stuck until u until the package gets updated. It's not going to do like some strange things. It's just going to

[30:00] Anyone else have a question or anything to add? I think there were question I saw a question, that I don't think we can really answer to, that directly like on potential impact of like for specific protocols. I think yeah th those need to be answered by those protocols themselves. Like the assessment, you know, that we got from basically everyone at this point is, that people are going to be able to mitigate for the most part

[31:00] the impact of this corruption. I think Elliot, that the answer to Your question is what Nico just gave.

[32:00] Well, I'll give it a few more minutes for some of these comments or questions to come in. Anyone know where the bug came from slash how it got in? I mean like bugs or bugs. Yeah, it's kind of a they're always sad. What I can say is, that yeah we had multiple rounds of code review. We had

[34:00] Well, feel a little bit more typing. It seems to be witicisms more than questions. Thank you for being. So responsive to fix the issue. That's, that's really nice. Yes. Again, I also want to say echo what Tor said before. This has been like a really cool moment where a lot of engineers at SDF. But also a lot of people in the ecosystem have really stood up and provided information, given opinions, given feedback, reviewed data, done their own analysis. And. So this is like, you know, for what it's worth, it really does show, that there is just an ability to be super responsive in general across the ecosystem.

[35:00] Yeah. If you're not following over there in the CAP, there's actually a list CSV file, that has all the different columns, that got restored. So, you can actually look at all the restored entries. yeah. Or you can do some stuff with the RPC. Look at, that. We're learning here and

[36:00] sharpening our honing our chops. Yeah, that's correct. Right now, all you will get is a timeout from. If you try to interact with one of those entries. I see somebody said and may maybe this was a joke. I can't tell. It says or not, I guess there's no way to tell. So, this isn't going to cause Stellar to fork. Fork. No, this Well, I, that's a tricky construction. Because there's a negative in there. this will not cause Stellar to fork. That's my statement.

[37:00] I'm trying to even think through how it possibly would. I don't I can't even picture how it might Yeah, again the important I mean the place where we are right. Now like the issue was identified the functionality was turned off impacted ledger entries were temporarily quarantined fix will basically allow them to be uncaranted. And and allow the any of the ledger entries, that are currently archived. When they get restored they'll be restored correctly I believe is where we're at. But again all of, that is an implementation based on feedback from the ecosystem it actually requires validator ascent through a programmatic vote on

[38:00] the network to go live and take effect. It looks like Adam was experiencing a timeout message to save you from yourself. Okay, cool. I feel like we're winding down. and again, some takeaways, read the blog, read the CAP CAPs and Final Comment Period, join the Stellar dev mailing list. If you want to leave a comment. Look at, that thread, that persists about the issue. If you have questions or an experience, that you want to share, we will try to keep you updated as new things happen. Again we have sort of it seems like there is social consensus on a path forward for a fix, which is what is captured in, that CAP. As

[39:00] the Stellar Core team implements a solution and it becomes available we will let you know and shortly thereafter we will try to upgrade the network. To orbit's point it's a very short time frame for, that to happen. So, we're starting to talk to people. Now to let them know. But once this all the software is released, the actual upgrade process from a from an operational point of view should be pretty straightforward. So yeah, I really appreciate you all for joining this and maybe under different circumstances we can just hang and chat again sometime. This was nice. Thank you all.

[00:00] Hello and welcome everyone to this week's Stellar Developer Meeting. We are finally back again after Meridian and lots of hackathons and activities. But I'm great to it's great to be back. And with us today we have Steve from OpenZeppelin. You have probably heard about it. Maybe you've even tried some of their tooling. But they're building some really great tooling, that's compatible with Stellar and built for Stellar. So I'm really excited to see a demo of the latest tool, that developed, that runs the UI builder. So Steve, yeah, maybe just introduce yourself really briefly. And then yeah, we can jump into the demo. Yeah, thank you so much. I really appreciate it. It's nice to be here and to be with you all here today. So again, my name is Steve. I am doing developer relations with OpenZeppelin. And so I handle a lot of things anywhere from documentation or interacting with a lot of our ecosystem communities and you know showing you guys how some of the stuff works and yeah I think it's going to be really fun.

[01:00] Okay, I'll share the screen here. Maybe you can zoom in a little bit. Yeah, I think I can do, that. And my screen is a little big. There we go. I think, that should be good. Yeah. Does, that look better? Yep. Sweet. Awesome. Yeah. Well, like I said, today we're going to be showing off the OpenZeppelin UI builder. Essentially, this is a tool you can use to interact with contracts, that you have on either Stellar mainnet or Stellar testnet. But it's actually goes a little bit further than, that. It's honestly like a React component library, like a UI library. And. So once you've created these forms or got the basics going, you can actually download it as an entire app or you can install the library as a package and build these UI elements yourself. And it just takes a lot of, that weight off of you. When you're trying to build interactive elements, you know, with your contracts. So today, I'll just go ahead and show you what it

[02:00] looks like. You can visit this today. It's live at builder.openzeppelin.com. And you'll be landed in this, you know, new contract UI screen. And all you have to do is just go ahead and select the Stellar tab. And. Then you select Stellar test net or mainnet. So I'm going to click test net right now. And from here we just go ahead and paste in a contract ID. It does work with both WASM and Stellar asset contracts. The main difference is, that these will pull directly from source. But these since they're not you know all the API and things like, that are not with source will actually pull, that from GitHub directly. But both of them work. So you'll have no problem there. But we'll go ahead and pull this one in. And right away, you'll see, that we go ahead and pull in a whole bunch of stuff. First, we pull in the contract state here. So, this is the current state of the contract. This is kind of like our we call it our kitchen sync contract, that has all sorts of variables and functions just to test a lot of different, you know, possible interactions. And we're pulling, that directly from stellar.expert.

[03:00] Stellar.expert. Really cool. And so, from here, we can go ahead and click next. And this is where we start to decide or build out our form. And the first thing you'll want to do is select a function. What do you want to build a form for? What piece do you want to interact with? And there's a whole bunch of different stuff. I'm going to select something pretty simple, just a set text right here. So I just hit select here. And from here I can start to kind of customize this. So I can say like set greeting. I can change the description, things like, that. from there I can go into the fields and have like field labels. I could do field types and you know. If we need an email or input, there's like a whole bunch of different types here. So I'm going to say we'll just call this greeting and say placeholder hello. And there's a whole lot of stuff you can do like required fields. You can hide from the UI, use hard-coded values. It's very customizable. And. So once we have, that,

[04:00] I'll go ahead and do an execution method. So from here we can decide. If we want to allow any wallet to connect with this and start using it or. If we want to require like specific account to interact with it. We also have the option to do OpenZeppelin relayers. If you haven't checked out relayers, I would highly recommend you do. You can check them out at docs.openzeppelin.comrelayer. And essentially they're managed services kind of like a back-end server, that can relay transactions for you and can automate certain things and you can do things like gasless transactions. It has full Stellar network support. So it's really cool stuff. Would highly recommend checking it out. But for. Now we'll just stick with like a standard account. And. Then from there we have a UI kit. So you can basically choose, which wallet kit you want to be included. So right. Now I have just the built by OpenZeppelin standard one. It's kind of like a very minimal, nothing really fancy. So I can see my accounts connected here. I could disconnect. But. If you wanted to, you could also use the Stellar wallets kit.

[05:00] And. So you'll have, you know, a different experience. You can kind of customize, that and choose, which one you like. I'll just go ahead and switch to OpenZeppelin. And once we have everything ready, I can either just go and hit next or at any point. When I'm in this, you know, building phase, I can hit preview form to view it and test it out. And then go back to building it. So once we have it set, I could actually go ahead and give this a shot here. So I can say hello world or something like, that. Go ahead and do execute. And, that's just going to have me sign, that transaction. And there we go. It's successful. And what's really cool is, that we can just hit this refresh button here. And you can see we have our hello world, that's been updated in our contract state, which is really cool. And from here, we can go ahead and export this. If we want to. This is going to export it as a like zip folder. And once you unzip it, it's going to be a V react project. And you could just install the dependencies,

[06:00] build. And then you basically have a app ready to go. Now, that's only half of it. Because that's like a really simple one form piece there. If you wanted to, you can even go to our GitHub here, which is open zeppelini-builder. And from here, you can actually download package dependencies. You could build these and use them in your app yourself, the components themselves. So, there's a lot there. And just to show you too the some of the other things, that the UI builder has to offer is once we created this UI, we can see it here under our contract UIs here. And. So as you build these forms and let's say you're doing multiple different tests or multiple different forms, they're all stored in your browser as local storage and you can actually click on them here. So, here's a different one, that's a much more complex form where I can put in an account address. I can put an account label, key values. There's a whole lot of stuff you can put here. And so, these are all kind of stored. And. If I

[07:00] wanted to, I could click on the three dots here to rename, duplicate, export. And all of this is basically just basic JSON data. So at any point I can actually export all of my current UIs into a JSON file right here. And. So from there I can import it and. If I ever needed to bring it back or something like, that, it's all dated. Just click import. And it brings in those forms, that I just had. And. So we can just go ahead and delete those. And yeah, that is the basics of the UI builder. And again, I think it works really great. If you're working with our wizard and you're like maybe putting together a contract, maybe you've deployed it. From here, you can just paste in, that address, interact with it, and test it out. Or. If you wanted to build your own web app, that has those UIs built in. Yeah, that's pretty much it. Great. If there's anyone, that has

[08:00] any questions, please feel free to drop them in the comments. I think this was a really interesting demo. Are there any limitations or anything I should know as a developer? If what is the what would be the common use case? Is it some someone who's playing around with the UI and they can drop it into their own UI as a component or what is a typical use case you would say? Yeah, I think there's actually a lot of great use cases for it. One of them, like you said, is. If you're just playing around and you want to test around or try out a contract, it gives it a really easy un interface to start using it. But we've seen some other people as well where like it could be used in a team application like for instance to help manage liquidity pools or build more complex forms, that might be used internally. There's all sorts of things I think you can do. But I think you know for people who are just starting out just wanting to build and get experience I think it's great for, that

[09:00] use case personally. Yeah, I can definitely see it. Developers in like early in the developer journey. If you build a smart contract, it sometimes it can be a little bit complicated. If you're completely new to Stellar to use the CLI to invoke the contract and get all the formatting correct in the invoke command. Definitely makes it a lot easier to be able to quickly spin up a UI and interact with your smart contract and test things out. But. But you said it's built in it was built in React. Yeah. Yep. It's all basic React UI components. I think we use Shad CN UI components under the hood as well. So I think we have a lot of visions too about what, that might look like in the future and how you might be able to import them into your existing app or something like, that. They are packages, that you can install to an existing React app and just start building right away. If you'd like to, which is really cool. Yeah, it definitely makes it easy to

[10:00] drop it into to. If you're building a React application. Then drop in the forms to interact with the smart contracts. I think personally, I think we'll see a lot of use of this in hackathons where you have limited time to accomplish something. It's a very it's it looks very easy. I had a chance to play with it yesterday and it was just in a matter of minutes I had a front end for my smart contract. So really great experience. I see we have a question here. I see it as a good starting point for building deps for your customers to interact with your C contracts. Yeah, absolutely. Yeah. Absolutely. I even see it sometimes. I do a I in my role as a dev as you know from yourself, we get to play around with a lot of new stuff. Sure do. And and a lot of time just for the convenience of it. I think this could be a great way for me to

[11:00] to test out some new features in smart contracts and. When we try to roll out. When we roll out something new. And I like to be testing things early on. But I don't necessarily want to build a whole dApp around it. So I think this has some great opportunities for both people playing around who's experimenting. But also building the dApps. Because they can drop in the their the components in their Next.js or their React application. Yeah, absolutely. Then there's a question does it support the new release of React, which includes a compiler demonstrated a few days ago at the React Summit. Let me see. I think as of right. Now we might be using React 19. So probably close. I'd have to double check. If we can actually get to using React compiler. But yeah, I'd be interested to try and see. If that does work. I know

[12:00] that's still pretty new. Yeah. Great. Any other questions? In the meanwhile, I will say you mentioned relay. I think we are going to do a presentation about, that in about two weeks. I think it's Oh, excellent. I don't think it's on next Thursday. But I think it's in two weeks. If I remember correctly. But we are definitely going to do a developer meeting around the relay and have a demonstration of, that. So, I'm looking forward to, that as well. Yeah, don't miss, that. That's, that stuff is pretty sweet, very helpful. Okay, can you maybe just talk a little bit about what Relay is? Yeah, it's essentially like a it's like a Rust backend. So, it's written in Rust. It's very nice, fast, it's efficient, and it's very easy to set up in my opinion. You basically clone the repo. There's like a build command or a setup command you run and it creates like a single binary, which you can run you know in most environments and it'll basically create

[13:00] like a API interface for you know smart contract interactions. So you can basically set up accounts or re they're called relayers and they can maybe have different addresses different permissions different you can load them up with different balances etc. And. So from there you can kind of make permissioned or spec particularly granted access for part particular tasks you know. And so there's a lot you can do with it. I think a lot of the people have used them for like gasless transactions. You can send an API request asking to do something. The relayer will take care of it. And then you know on your actual user interface app you never had to have a user pay for gas or things like, that. But yeah, it can really build a lot of, that. And I think there's also. When you use them with monitors, that's the other half of the equation there. monitors allow you to listen to smart contract events or functions or anything happening. You they're very flexible and the really

[14:00] power comes in is like you can monitor one thing on your contract. And then as a reaction use something on your relayer. you know, so, that could be something like,. If somebody withdraws way too much out of a contract or is an alarming amount of money, you can maybe pause the contract or you can stop certain things, you can react to things. It's kind of built as both a security setup as well as, you know, just a ease of life setup to, you know, for building apps and stuff. Okay, great. It doesn't seem like we have any more questions. So, I would just thank you for the demo It was super interesting to see how easy it is to set up a front end and create front-end components for a smart contract. I It's kind of tooling where it's making life a lot easier. You get something up and running quicker. And one of the things, that I always love about using tooling like this is, that it's gone through a lot of testing. It's gone typically it's gone

[15:00] through some auditing as well. So. So you get a really solid starting point for your project instead of trying to build everything yourself. So, thank you so much and yeah, we'll be back next week with another great demo. And just a reminder for everyone joining here at 1:30 p.m. Pacific, we have a protocol meeting on Discord. So, see you all there and thank you again, Steve. Thank you, Kristen. Yeah, it's great to be here. See you. Bye.

[00:00] Okay, I'll get started. hi everyone. Today, we are going to be talking about CAP-75, which is a proposal to add two new host functions to support Poseidon and Poseidon 2 head functions. So the CAP itself is fairly straightforward. two new host functions. It it's pretty standalone doesn't involve any of the previous protocols mostly except using the BLS and BN field. But I want to spend a little bit time on the approaches, that we decided on and the rationale behind this approach. So first of all just a quick introduction on the motivation why do we want the Poseidon and Poseidon 2 hatches. So. So

[01:00] the Poseidon and Poseidon 2 they are I'll call them Poseidon family. So they are family of hashes basically it accept a range of parameters. And then you can configure it to compute output. So what it is it's a sponge based hash function, which means it consists of a sponge, that absorbs input and fit output, which is a variable length input various variable length output function and internally there's a permutation, which is fixed input fixed output and the reason, that u it is useful along with Other catches of similar design is, that it directly operate natively on the prime field. And as you can as you know most of the zero

[02:00] knowledge applications are built off of the prime field such as BRS or BM254, which makes Poseidon natively work with this field and they are ideal in DK application. Just to give a rough idea, it the amount of constraints to generate using a regular hash like a SH 256 versus Poseidon is two order of magnitude difference. So it's a lot of proof side less proof side complexity and time to use Poseidon. So for contrast. So proof allocation typically don't involve rehashing or anything. But for contract implementing logic such as a mer tree, that you want to generate proof of you want to have the same hash implementation between your contract and what you use. When you generate the proof for, that

[03:00] mole tree. I think, that's quite obvious. And to have the Prooseidon implemented on the gas side or contrast side is quite expensive. Even with the functions, that we already provide for BLS field arithmetics, there's still a lot of round trips between converting a few element to bytes and things like, that. So, that's why we want to support Prooseidon as native host functions. So just a recap of where we were last time. Last time we proposed a few three possible approaches to this. First is just to provide the hash functions plain and simple. You know for different field you know for different field combination of B and BLS combination of PID and PIN 2 and a combination of number of hash

[04:00] input. So this gives us what like eight different type of host functions, that will cover a lot of use cases. But this approach isn't good. Because we've from the feedback and from the evidence, that a lot of these hashes they require particular parameters these parameters are not set in stone. So different implementations could choose them differently. So even. If we specify them in the host for example someone else might need a different way to provide a parameter. So this way isn't just provide a hash function isn't the most maintainable way and what about providing more host functions for those field arithmetics and also it wouldn't solve the problem. Because even. If we provide things like matrix multiplication the pose hashing involves a lot of rounds of permutation each

[05:00] round is doing this multip multiplication. So we still end up with a lot of these cause and a all of these round trips. So one of the proposals ended up last time was can we provide a more generic interface for the sponge hash namely the to absorb some input doing permutations and spit out the output. And then be and let it be parameterized. So yeah so, that's what we settled on last time and yeah. So now to transition to this CAP. So this CAP proposes a slightly different approach, which I call approach four, that from the discussion thread for anyone who's following. So approach four is instead of providing the launch interface we provide the internal permutation functions, that the launch

[06:00] hash uses. So why is, that? So. So the sponge is a it's sort of its own animal. It's a different animal than the permutation. sponge design had many different considerations for different applications. For example, not only for hatching. But also for like generating like a random stream of bytes or for MAC method message authentication code or for random like for receable random value generator like these applications are all u designed scope of a sponge. So the sponge needs to be more flexible. It needs to maintain a state. It needs to in some cases it requires switching between absorbing and squeezing. And then

[07:00] switching back. So the sponge interface itself isn't it isn't a single definition, that we can just take. Because and itself is also has some complexity in it. However the internally all the sponge function they call the same permutation function. So after. So in both stun absorb and squeeze the input and output before it was the input is passed. And then the permutation is applied and the output is squeezed. So. So at the center of it is just this permutation function, that takes a fixed length input and a fixed length output. So this is much more maintainable and it's much more easy to support in solarong without ramifications. Because

[08:00] it's just a simple cryptographic building block and the sorbound host doesn't need to maintain any state. So there's no like state related issues for like what. If you make a subcontract call do they you know reinitialize a sponge and how to do, that. So. So by supporting Prooseidon permutation instead of the full Prooseidon hash it gives us a lot of flexibility maintaining sort of host and also sponge itself for a h for a simple hash algorithm, that's like a binary hashing of a Merkel node for example isn't, that complicated. Is just basically it's just a single round of taking the input and applying the permutation and spitting out the output. I've written down a little pseudo code, that basically is what it is in the CAP. So. So just to

[09:00] recap, the sponge interface is complicated. It the sponge is designed for many different use cases, not just hash. Even, though for hash the sponge is really simple we don't want to just baking a simple sponge implementation inside host. While this is much easier to do it in the contract or in the SDK. But it is makes much more sense to support the primitive, that's mostly the most expensive operations happen, which is the permutation function inside the sort of host So, that's the high level motivation, and now I can go through the actual two functions being proposed. One is a Prooseidon permutation and second one is Prooseidon 2 permutation. The two

[10:00] look fairly similar. So. So just a bit of background Prooseidon is the original version developed in 20 2019. Poseidon 2 is a improved version of, that developed in 2023. Internally they work slightly different. Poseidon 2 has u improved the internal matrix shapes. And then add pre relication add a single layer of pre-apply. But overall it works fairly similar. So I'll just cover the Poseidon one. So the process permutation takes the input, which is a vector object, that is your vector of field element. And then the second thing is the field type. So I think it probably makes sense to have field type as a symbol. But in the CAP I'm putting U32 should be

[11:00] equivalent. But yeah field basically is a enum, that specify, which field you want your permutation function to be defined on and of course your input will be passed in the same field as the permutation matrix and all, that. and the rest of it is just internal parameters for the hat functions. so, that's pretty much it. But I'll just spend maybe a few a couple minutes just explaining what these fields are. t is the capacity parameter. So it's the capacity the internal sorry not the capacity. But the internal state side much must match the input and also must match the size of internal matrix. It is decomposed of the rate, which is number of you can think of as number of input

[12:00] you need to hatch at once plus some capacity, which gives you additional security parameters. D is the degree of the fbark, which is the internal one of the internal step in the permutation before applying the matrix multiplication. So for bn and bs both fields d is equal to five. So we may just only accept the equals 5 u. But of course for other field in the future could be different. The round f round t these are the internal partial round and the for round these are the number of round the matrix multiplication happens. So the yeah. So the there's also a linear layer, which is u sorry the linear layer is a run the mod matrix multiplication

[13:00] but the nonlinearity is provided by the run constants, which is also matrix. But specified for each run. So the. So the MD MDS matrix for hash two function is 3x3 run constant is a is another matrix with dimension n by m where n is the number of run and m is three. So, that's a high level run through of the different parameters. The second one is fairly similar. The only difference is, that the internal MDS matrix in the second version is a diagonal matrix. Because of the precision 2 improvement in terms of cost type. So we. So we manage I think we can manage to ship this as a native solar bond library, which means, that all of the operations they are already existing and were defined. These include the

[14:00] field arithmetic for adding and the multiplication and things like, that. So there's no particular peridon specific metering parameters we need to support. But we do have to add these ban 254 field u arithmetic cost types, which is a very opportune timing. Because we have the CAP-74, which has b24 scala field and pairing. So I went through the parameters metering rationale. Yes. So, that the rationale why hash function why we don't provide a hash function out of box rather than providing the permutation primitive. It is explained and yeah just to also mention these parameters they are

[15:00] so. So yeah. So so some of them they are kind of defined based on the application like. If you have a curve of. If you want to do hashing with BN25 254. Then the degree is five you can change, that. And then the sum of them is depend on the actual application, which is how many inputs you want to hash at once. And then based on the size of the input these parameters like t. And then the number of runs they need to be adjusted the original procidum paper provides scripts and guidelines for how to generate these parameters in general I think most applications have their own they have they use a set of generated parameters like CIRCOM does and Noel does and to provide the maximum

[16:00] like safetiness we would have these as part of preset in the SDK. So like the SDK interface will look exactly just like a hash two, that takes two input. And then internally you may be able to specify the set of parameter like a circum parameter or neural parameter things like, that. And then we also possibly expose these Poseidon permutation as a more like a hazmat interface something, that advanced users, that know what they're doing can call with their own parameters. But we will make them the distinction more clear. Yeah. In terms of testing there's a reference implementation for Prooseidon. And so Horizon lab has a reference

[17:00] imitation for Poseidon 2 and in the same repo has Poseidon one. That's the one we likely going to adopt. And it also provides test vectors for both one and two in different fields and parameter. And. Then there's also the original Prooseidon paper, that come with a sage script implementation with some reference vectors, which we will also match our implementation with in our tests. Tests. There's a draft implementation and I think, that's it. Now four is open for questions.

[18:00] Okay.

[19:00] Yeah. So I did a very rough well I wouldn't say too rough. But like the implementation is fairly mostly good. And then the field for BRS is already there. So I did a number on the reference test cases for BLS the 3x3 matrix case, which is the hash two operation, that's about half a million CPU instruction. So it's a lot better than what I projected last time. And. Then the 5x5 matrix case I believe, that's like cache three input, that's around 1 million CPU. So yeah, that's well below our target ceiling, which we want to support around 20 hash cores in a single contract.

[20:00] questions. Okay. Back to you, C. Oh, okay. You want me to close it? Okay. Bye, everyone.

[00:00] All right, I'll get started. So welcome everyone. today I'll be speaking about CAP-74, which introduces host functions for the BN24 pairing friendly curve. So as you may know, Stellar already has support for has host function support for the BLS 12 through 381 curve, which was chosen over BN24 due to growing support for it and security. But we've gotten ecosystem feedback, that there are existing use cases, that rely on B2 BM 52 BN254 and adding native support for it will make it easier to implement those use cases on Stellar. The other option would be to adapt those use cases to use the existing VLS host functions. But, that would be prohibitively expensive in some cases. Cases. So this proposal the main part of this proposal is, that it adds three host functions G1 add G1 malt and a

[01:00] pairing check, which gives us parody with the BN24 pre-ompiles in the EVM. Now there have been some discussions about extending this in particular adding a host function for G1 multiscaler multiplication. But this proposal doesn't include, that. At the moment we're just trying to support the existing BN24 use cases and this should be sufficient and for any new use cases I the recommendation is to use BLS the CAP also specifies new cost types for the BN operations, which are similar to the cost types, that we added for BLS they're just a subset. Because BN has a subset of host functions and Yeah. It's a pretty short CAP. We also define the field and groups and yeah are there any questions?

[02:00] If there aren't any questions. Oh, Tor's typing. Yeah, it's a pretty straightforward CAP. if. If anyone has any questions, you can tag me on Discord and we can have discussion. but. If not, I'll pass it off to Jay to discuss adding host support for Poseidon and hash functions. Can you hear me? Yeah, I can hear you, J. Okay, wonderful. Yeah, great. I just want to add on what Sid just talked about. So yeah the ecosystem technically they could use all these BRS functions. But in the proving framework including like this the circuit like switching those curves off is it's in reality it's more

[03:00] challenging than u than we thought. It's not just a simple curve swap. But sometimes those protocols can be evolved and circles have to be recompiled with different curve. And. Then there's also different type of issues with like different u like proving systems support one curve versus another. So BN254 is mostly for backward compatibility. And also we've also added a solorone example of importing the BN 254 inside the solar contract, which works. But it takes I think like 500 million instruction to do one pairing. So, that is also prohibitive. Just wanted to point out the like these two specific rational why this is needed. Cool. Cool. And yeah I will start on yes thank you an yes. So the poseidon hash

[04:00] function has also been one of the requested primitive to add into solar. So I've recently just looked into this I don't have a CAP yet. But I will lay out what I found and sort of the different approaches u like informally here and I'll work on the CAP probably be ready in the next couple days. So yeah, first of all, why is this also needed in the proving in the DK application? The the commitment scheme is a lot of commitment scheme is hash based meaning you hash something. And then you prove, that this thing has been hashed is without revealing it. So the hash function is critical. And then for the hash function, that's used is also important in terms of the performance of

[05:00] the prover side. So from what I understand not expert. But from what I understand is using the right hash function like Poseidon can reduce the number of arithmetic argu the arithmetic gates the arguments by an order of magn like two orders of magnitude. So this is a fairly big difference, that's why a lot most of the like the circuits use these field based hash functions and poseidon and pose. Then two are two of the most widely used ones. So the next question is why do we need to support in the host, although the proof is generated offchain and the verification of the proof is doesn't involve hashing the hash is needed. Because some applications need to

[06:00] maintain for example a mer tree of different coins for example. And then to prove the coin's existence they can prove without hashing. But to update it on chain or some any kind of state, that involves hashing to be proven it needs to use a hash to update. So to be consistent we need to make sure, that the hash function, that's being proven is same hash function as what's being used for contract state update. So, that's kind of a big u overview of rational and poseidon functions these are not one function it's rather a family of functions or it's a rather it's a it's an approach, that based on sponges. And then ways to connect it connect these

[07:00] sponges to provide different permutations with different input. So it's fairly generic. You can in terms of you can plug in different parameters like for example. If you require a higher security parameter. Then the round parameters will be larger and also depending on how many inputs you need to hash at once also how many output the throughput the number of runs needs to be adjusted. So. So in the Prooseidon paper there's different implementations of different versions of Prooseidon given on the requirement as well as underlying field. So here we the primary field what we have to support for compatibility is BN24 and also BS2381.

[08:00] So, that's a two requirement and based on these requirement some of these parameters can be decided. But some of them are still can be some of can be cho choices. So we need to really decide what level of flexibility we want to supported with. So in this discussion last the discussion thread the last post I've laid out the three approaches, that I feel we could support it. So these are in terms of u from the most high level to the most low level. So number one we support it as hash functions directly. So for, that we will support Poseidon 2 and the two curves. And then so yeah I think this is the most straightforward one. But the

[09:00] limitation is, that we are we need to kind of decide on the parameters internally like there's a. So so in the Prooseidon paper they describe how to choose these parameters and they choose it. They provide a script to how to generate these parameters and own guideline on how to choose them and in reality from what I know seems like different applications sometimes generate their own parameters. I'm talking about these internal like round constants like these matrixes. So so. If if someone from another ecosystem, that generates a proof with a different instantiation of Prooseidon. Then potentially here we could not support it. So, so. So there's a little bit of compatibility risk we have to decide. But I think for

[10:00] this one most parameters are fairly straightforward. And. Then we need to make sure, that the major prover can be supported like the circum or no and we just need to make sure, that whatever parameter we choose is compatible with a major, that wants whether we wanted to migrate to Stellar with so, that's number one number two is to expose the internal poseidon building blocks. So as I briefly mentioned earlier the prociding hashing is a sponge based like a block cipher it consists of absorbing the input per permuting them. And then squeezing them. So one of the ecosystem member Antonio suggested, that we could support

[11:00] the generic interface to provide these. And then users can just choose the parameters or choose the security parameters field and all, that u. And then we can expose these options through the SDK. I like this approach. But I think it's maybe a little bit it involves a little bit of figuring out the requirements for the libraries. And then the level of details we wanted to expose how to expose them to SDK. I'm not expert in the this part yet. So I will say, that this one right. Now I would say this is a less favorable option. And for I think one of the main advantage for this one is, that Osan and Poseion 2 they use very similar interface. So potentially this one is more

[12:00] cleaner, that we just support this. And then the two different variants can be supported like more uniformly. Doesn't add complexity station. Yeah. Yeah, I think yeah, this requires the user to understand what they're doing and how to instantiate the hasher with these options. Yeah. Yeah I think yeah I'll also talk about number three. Because I think exposing the host function is the most straightforward approach. But in reality it's just the different parameters we can support them all. But then with the internal building block it's possible, that we could let give

[13:00] more flexibility. But yeah I Think, that's kind of the main rationale. But in how to do it we have to think it more carefully wanted to say, that for approach two and probably three it's not like we have to put much burden on the users it's just, that we can build SDK functions right, that do the same cache functions for example. Because you have an option one. But there is a huge benefit of you know not introducing like combinatorial explosion of the code types into host, which I think is a really bad property of approach one right it seems like instead of just setting a few cost types we need a lot of them and. If you wanted to do something more complex we would need even more and this is I think a lot of

[14:00] maintenance burden and a lot complexity in the protocol, which I think kind of would be nice to avoid. So I feel like these parameters could be implemented in the SDK. So user complexity would remain the same. The only question is really performance at this point. Yeah, I disagree on the cost type part. Because I think doing two and three can reduce the amount of cost types potentially. Because these are just three building blocks. And then yeah to be clear I totally agree with you. I'm saying, that I do not like option one. Because in option one we need a cost type per hash and per whatever curve and perity, which is an argument of the function, which is what I refer to this explosion right we have like three

[15:00] different inputs to, that. So I think we're on the same page here I agree, that we probably want to have more limited and like number of cost types, that can be useful building blocks. Yeah. Yeah. Yeah. And by the way, also the RT it I think for a minimum we just we need to support RT 2 to support the Merco tree or binary Merkel tree. But we fairly certain we don't need four right. Now and. Then one maybe. So at a minimum maybe just a R of two. But I would need to confirm it. If this is just what we need. Yeah, I still feel like it is like a really hacky design, right? Like we have a host functions, it has an argument. But it can have only like couple of values. But I don't know. I would really try to stay with the building blocks and do work on the SDK side. If it is feasible

[16:00] from you know the instruction count standpoint. Yeah. Yeah. So number three is going a step further. To to do this without providing any Prooseidon host functions. Because the algorithm itself is fairly they say straightforward. It's more like applying arithmetics repeatedly in iterations. So in theory most of the heavy costs are in the field arithmetics, which we already provide for BS 12381. And then for BN we are going to provide them. So the question is can we just do this on the guest side. So I did a bit of experiment what I wrote yeah hash 2 takes

[17:00] about 17.6 million instructions. This is trying to like do the optimized implementation or I think it's with the current implementation, that's the best we can do and out of, which only like around three million other crypto arithmetics. The main reason is, that every like to do every irrespective you have to go round trip to the host. And then to do the bite to internal representation conversion. And then internal type for efficient arithmetic requires. If I remember correctly it's a Montgomery form. So it needs to do some arithmetic to convert the numbers into some form, that's efficient for multiplication or division for example. So there's quite a lot of these overhead. So the s the thought process is. If we can bundle these

[18:00] into some u like more efficient field arithmetic functions such as dot product and matrix multiplication is it possible, that we can reduce, that cost? I don't have a straight answer for, that. But my intuition is, that we can include we can reduce, that significantly. But maybe not to the level, that we require. For reference to hash a mer tree of a million entries we need 20 hash operations. So this would require at least you know 10 to five times reduction of, that number. So I think we can like reducing these operations. It's it's doubtful, that we'll get close to the upper bound, that we're shooting for. Yeah bit of rationale

[19:00] reason into, that is. Because even, though we can provide the matrix multiplication these matrix are fairly small like 3x3. So we're not bundling like a thousand operation into one we are just bundling like you know nine. And then the rest of it still like was code and these loops and, which will still have significant overhead, that's why I feel like this approach even, though it's more attractive it probably wouldn't work well and also it will require the user to handle their preciding implementation. So overall I think in my opinion number one is probably the best option to support it today. And. Then we need to think more about these parameters and choices

[20:00] any numbers for option one like how much more is it? Yeah, I yeah, in number three, I added up all the metered cost for arithmetic. They are about 2.5 million. So I would say number one would be much more closer to, that. There's still like some like extra cost of like memory allocation and like the conversions still a bit. But I would say it will be much closer to 2.5 million. Yeah, good point. Toma are the numbers in three like. When you say optimize is, that like what do

[21:00] you mean by, that? Is, that like a native call, that you tested 17 million? Yeah, it's not a native call. It's was contrast. So, it's basically implementing Poseidon cache in W was. But calling the host functions for BS scalar add multiply and these functions. optimize just means, that I try what I can or what I know to make sure, that these calls are all necessary. And then we're not wasting like unnecessary convergence and things like, that. That. Okay. Okay. The cost between one and two. Yeah. I don't know the in terms of CPU cost. I don't know how much they will be different. It's more like the complexity and the maintenance. So I

[22:00] would imagine. If done properly they will be pretty similar in terms of performance. But it's more like the question of yeah we want to expose, that level right again for the complexity I sure I get the argument like I think really complexity I said can be moved on the SDK right I think what is important here is protocol complexity and I feel like one is more protocol complexity just from the standpoint of maintaining the permutations of different input. So. If two is really yeah it's unique as the same. So. So yeah. If you had a number for two and. If you knew, that it's not significantly worse than one and I feel like two is much better option.

[23:00] Yeah. Yeah. I haven't done enough exploration in, that direction yet. Yeah, we I'll try, that in the update. Yeah. But even for two, we need at least Prooseidon and Prooseidon two. Because these spongy implementations are different. So, that we're talking about yeah like at least maintaining like six of these functions essentially. Yeah. But it just feels much better still. Because it's like at least finite and it covers like all the cases, right? Yeah. So as Nika points out like. If friendly isn't hard for coded. So you know something new needs to be done and can do it as a guest layer. Okay. Yeah I'll do a little bit more exploration to two and yeah. If I

[24:00] yeah I'll update on thread. Yeah, Alex, I think yeah, that's a agreement. I think yeah, two is more flexible. it's just little bit of complexity to do it, right?

[25:00] Yeah, I think In option two, even, though we expose these primitives, the internal parameters would still have to be like I think these interfaces don't let you specify the like the security parameters like the long constants matrixes. So

[26:00] yeah one thing one other thought I had was should we expose those or should we like let the user initiate the hash with set of parameters they want and how relevant would, that be for most ecosystem. But I haven't figured out answer to, that yet. So there's potentially they're doing two with maximum in top interoperability you could be more complex. Different parameters like would they impact the runtime or are they just No, it's just numbers. No, not runtime. Yeah, it's different. It's just different hash. The output will be different. But the runtime is just the yeah the width of the inputs and the number of runs. So yeah long time I think we with

[27:00] number two we can have, that metered with like per iterations. But the security parameter is just the choice of yeah like the choice of hash states, that don't provide different outputs. Yeah, I agree. Like. If we add a capability to provide configuration and it does not change host complexity much. Then we should do, that. Because okay from the hosting point I would be concerned about the metering. But since we can meter it all the same I don't see like why would pass in an additional vector or something as an input. But but we introducing too much

[28:00] complexity here. Okay. Yeah. Yeah. I think yeah mix yeah two would be a good yeah good solution for interoperability. I'll spend more time on, that. I think I saw someone typing

[29:00] Hey guys. Hey. Hey. Can you hear me? Yes. I'm in a bit of a loud environment. So, you know, you can hear me. yeah. So, I joined in the middle. So maybe I missed some things. But I think I kind of understood J's proposal. With a hardcoded option, an option, that enabled us to configure MDS and run constants parameters. Seems to me, that the configurable option is the is a good way to go. Because that still optimizes the hash function itself run faster after the initialization. But enable some flexibility. Flexibility. The one thing I think we need to

[30:00] ensure is and I don't entirely understand how it works is how often we need to initialize the potent initial initialization types like let's say for milling as instructions. So I think it would be good to understand whether say to deploy as a separate contract. And then poly to whether the initialization only occurs once deployment is done. So, that those are details, that are less familiar. So as long as we can guarantee, that the initialization of the hash doesn't often think abilities disadvantage yeah I don't know any specific questions lots of. When doing stuff. So actually guy was looking into, that as well yesterday he was looking into implementations from what we saw Tom

[31:00] when we did it with you. When we had the budgets it seemed So. If it's around for milling instructions. And then the hashes themselves are around 10 million for everything running wasn't right. But yeah as long as for instance those four million instructions happen in my limitation one positive, that's, that's not too bad. Sorry, could you repeat the part? What's the forming instruction?, that's the construction of the house. Oh, okay. Yeah. yeah. I think we Yeah, I'm thinking like. If if it's like a contract like every contract has its own the seat for like the RNG for example. Similarly, every

[32:00] contract can set its own the state. And then they can once it's set it should be yeah, that should be the initial cost, that yeah I'm not also familiar I'm also not very familiar with the internal working of like these hashes. So I need to look a bit into it. But I imagine the initialization is just one time and absorbing yeah. And then yeah you need to. And then to use you have to absorb it first. So, that would be like probably based on the number of inputs. Yeah. Yeah. So the initialization is just like reading the checking the conference. It's not a stateful or something, that. So as long as, that's done, done, you can hash. Yeah, that's right. Yeah, I guess it's per No, it can be per contract life. That's a good question, that. Then you

[33:00] need to serialize it somehow betweenations or. If you're invoking a method from another contract, that. Then I guess can just keep invoke getting cached and we can keep invoking, that. But hey I'm talking here about lesson. But but yeah I mean it's not for invocation it's How. However long you can do here questions. I have a question about what you wrote. So why would it matter whether other V projects have different configuration witnesses apart from unless you want some interoperability to be inter between different channels.

[34:00] Other than, that we can speak around for answers. sure. Makes sense. I mean, it's not it's definitely there's definitely an advantage to having the same parameters, that Yeah. More feature for sure. Yeah. Yeah. I think it makes sense. Yeah. U Yeah. Allowing the constants to be overwritten for Yeah.

[35:00] for different chains and different projects. Yeah. Makes sense. Yeah, good point. Thanks GPT. Okay. So I think, that's seems like

[36:00] that's the main questions and concerns is the interoperability and the flexibility parameters. So yeah, I will look into option two in more depth. And then I will update, that thread. And then CAP will follow. Is there any other questions? I guess also to add I guess it would be good to look at the parameters of the circum lead the standard the circum library and see what they correspond to in terms of other stuff in specific projects. Because I. So far I've replaced them with something, that works on interoperable between what I could, that work in cir and rust and m

[37:00] So, that's a riding stand library. If we can go back to the stand library and use the parameter, that probably, that simplifies C. Oh okay. Okay. So. So did you say you changed those parameters in order to Yeah, basic basically on both ends both on serum on the rough end basically parameters, that I keep from side implemented forum. But I need to check. If it depends on the fun library or from other library system, that I found. That's how it's hard to double check, that. If we could exceed to the default CD parameter, that would be good. Yeah. Okay. And probably they probably work on other project. Project. Yeah. So perhaps supporting right like supporting like a default set

[38:00] if. If it's not overwritten like default to like a circum or something. Cool. If no other questions, I guess hand it over to you, Bri. You want to close the meeting? Okay. Wonderful. Thank you all. See you later.

[00:00] Great. hi everyone. sorry, Carson, I said you would start up. first, can you hear me? Well, please let me know. write in chat. all right. Great. okay, cool. So, hello everyone. today I'm going to present a few CAPs. As many as time permits and I have three total and all of them were kind of spawned from Le's proposal, that was linked to one of the CAPs and the idea behind the proposal was about extending our capabilities for the classic star account or G accounts and the idea behind it was to

[01:00] add a capability for IG account to have a set of contract signers. So one contract signer and. If you have a contract signer you can really have arbitrary authentication logic with arbitrary policies and stuff like, that. But in addition to, that you could also add a capability to manage trust veins for example from soraban, which closes even more feature gaps. Because this proposal as it is it won't be possible to use this C standards outside of Soraban. Because we currently do not provide a way to run contracts outside of the transaction apply for with, that like Jay is not hearing me. I don't know Jay seems like people still hear me.

[02:00] so, that's kind of high level motivation behind, that. But I'd like to actually start with CAP-71, which is something I figured. While thinking about how this whole GI account customization thing could be implemented and this CAP is about adding protocol level support for delegating authentication between custom accounts. Yeah, thanks Marius. It's actually not a new mic. It's just Discord settings. Which is funny. So CAP-71 and motivation for, that stems from several different issues. And basically currently what is

[03:00] possible to do in Soroban what some of you may know there is this require O function, that requires authentication authorization from an address and this function can actually be called from within a custom account check O function, that performs as well. So this is kind of the current way of delegating not. So you have an account. But instead of verifying some signature you say I try this other contract to perform verification for me and this has some benefits for modular custom accounts and it is like a cornerstone of this proposal for G accounts to have C signers. Because it's effectively the same kind of delegation right. So instead of having a cryptographic signature for a G account we say you don't actually know what the signature is we let a contract to perform

[04:00] verification instead on its custom signature format. But this mechanism. While it kind of works it was not like built as a full-fledged feature in the protocol. It's just a byproduct of the design. Design allows it. That's not visible out. Because there's no reason to dissolve. But just kind of inconvenient to use and also not optimal to use. The inconvenience factor lies mostly in simulation. So. If anyone has tried it, they would quickly learn, that you cannot simply simulate this. Currently you need to build for the delegated contract call you need to build its own signature payload. Which is kind of tricky and this could in theory be fixed the simulation where, although it might be a bit complicated as well.

[05:00] but yeah it would still be kind of annoying. Because you would need to do several simulations and all kind of propagating more and more authentication information into the system. And yeah, I think it is still kind of annoying. But in terms of optimality as well there is quite a bit of duplication here. Because like you spawn new authorization entries like for example. If you have two accounts and one delegates authentication to another one. Then you would end up with two authorization entries in transaction, that increases transaction size and increases complexity for building it and the tipping point for me for why I came up with CAP is the context like the some of the proposals, that I've seen

[06:00] for the delegation for custom accounts maybe do not use context much but. If we were to do this for the G accounts we do not want to lose the authorization context, which is basically the list of the contract codes, that have been authorized And the issue with the approach of calling require O from within check O is, that you could pass context to the require O call. But it would not look the same as the normal context, that you would have during normal authorization, which means, that for example let's say you have a an account implementation, that does something about the context you cannot simply use it as a delegated banner of a G account for example. Because the context will be kind of in messy nested form like it will be

[07:00] an argument of a call instead of a list of the call. So it is kind of messy and I think it is going to be quite annoying to maintain this mess in the protocol like it creates some inconsistency between like how different types of contract signers can be used. Which is basically the motivation for this. But it also solves the issues I've described before. Oh yeah, and also. If you want to have the context you will need to attach it to the transaction as well, which is like even more duplication on top of it. But you have like besides like specifying multiple authorization entries for every address, you would need to specify like the whole call stack as well for every address. But in different forms. And it's a lot of mess. Mess. So what do I propose to do about this?

[08:00] it is actually not, that big of a change and it consists of basically two parts. One part of it is on the XDR side as can be seen in the CAP. And what we do in the XDR is we introduce a new type of credentials, which is basically this part of the authorization entry, that contains signatures and stuff like, that. And the credentials are pretty much same as robban credential of address. But they have an additional field called delegates. And each delegate is just a strct, that contains an address and a signature C value, which can be an arbitrary value for one can parse. And it also has a list of nested delegates. In case. If you call delegated

[09:00] accounts from within delegated account and the cool thing about this exr is, that you may have a single authorization entry, that has as many delegated signers as you need. So there is no duplication at all like there is only necessary information. Information. So in the simplest case for example right we have an account, that asks another contract to perform us on its behalf and this will be represented as a single authorization entry, that has the main account, that we are performing O for in the credentials at the top level and the contract, that actually performs O and delegates array and we only store its address and its signature. And this structure is very simple and like. If you get a result from this

[10:00] like it's usually up to you to fill in the credentials anyway. So. If you are dealing with delegation as a wallet, what you need to do is just build this new type of credentials. It should be pretty simple like it's only a couple fields more than you would need to fill for normal or entry and there is no like this messy propagating the O data into simulation and stuff like, that is basically kind of a way to do multi-IG. But instead of doing multiple signatures you have multiple like sign implementations on the high and there is one more small change, which I will talk about a little bit later. And from the host side we add two functions, that actually allow contracts to interact with the delegated

[11:00] signers. The main function is delegate count O, which is very similar to require O. But it can only be called from within a custom account from within check O reserve function. And it doesn't take any arguments. And what this does is something similar to referrals. But instead of like just authorizing the current call arguments and current call, instead it will inherit the context and the signature payload from the current check implement from the current checkos invocation. Invocation. So basically you have a check off. And then you have another contract, that you want to perform checkos for you and, that other contract will get exactly the same check arguments and its own signature.

[12:00] which is really cool. It allows like all the delegate centers to sign the same payload basically and have the same context. So there is no messes like this nested context in argument and stuff like, that. So for every contract it would look like as. If they were authorizing the call themselves. While in fact they're doing this on someone else's behinders present for the current cost check. And the motivation behind this function is simply, that. If you were to use this feature you would have an issue of somehow attaching this delegated signers to your signature payload. Like you would need to list some signatures or something like, that. And like since I would imagine

[13:00] a few contracts would want to use this and it's kind of annoying, that everyone needs to reimplement this and come with their own UDS and stuff like, that and in since we already have the delegated XDR we just add a getter, that returns this delegated attached to the transaction and matched to the current. So you can get them. Then you can make sure, that they are actually the centers for the account. And then you call deate account on for them. So there is no need for some bespoke representation of this deate center. They're kind of building feature, that you may use and you don't need any data structure or app. And again, this reduces duplication even further. Because like. If you fully delegate your O to another account, you do not need the signature for your main

[14:00] account. Account. All right, that's it on the high level for the host functions. The CAP has a bit more detailed description of the exact algorithm or how does it work. But I think the simple summary. If it is really, that just make sure, that the arguments look as. If you've been authorizing the require call at the top level and the last small thing, that I've mentioned before in the XDR is, that unfortunately we need a new type of signature payload, which I think is like the main downside with this approach and the motivation for this is, that the current payload, that you need to

[15:00] sign to for thoraban is it does not contain the address for, which you're signing this payload and in the current O framework it makes sense. Because it is implicitly tied to the address. So address is signed. But it is signed in a different part of the payload. But with a delegation like you need to explicitly sign for the address, that is a top level address, that delegates everything. Everything. So basically without, that this whole thing would be insecure. So, that's kind of the annoying divergence between like the different credential types. I think. While it is definitely a downside it's probably not as big. Because it is it has one to one mapping

[16:00] to the credential right. So. If you do not support delegate credentials, you don't need to worry about this. If you do support delegate credentials, you don't need to worry about this. But the criteria for picking the right signature, it's pretty straightforward. Again camp has more context on this issue. Yeah. So I think it is more or less it at the high level. CAP also has a proposed simulation flow, which is kind of universal for any world, that wants to use delegated accounts. Sorry J accounts are this you can do this for J accounts. But there are some custom accounts implementation around, that. But also delegated account, which I know there could be like know Zeppelin has been working on something similar

[17:00] and I know has experimented with this for a. While but you know. If you like a lot of convenience and to link your well also simplifying and optimizing the transactions Right. We'll CAP the trail for Yeah, we will get to CAP stream later. But probably answer is yes questions. Questions. So any questions? No designers to send G transactions.

[18:00] that's CAP-72 and not yet. But it is a step forward in, that direction right. If we ever allow CERS to sign transactions and G accounts with C signers will also be able to do, that's again we can talk about this a bit later yeah, it is definitely stack or more interoperability between GNC accounts in general.

[19:00] I know, that Lee had some concerns about CAP-71 specifically in terms of like about yet another protocol feature. And I do not disagree, that it could partially result with simulation. But as I've mentioned before I think doing this at protocol level very beneficial especially. If you go ahead with CAP-72 and does not only like improves ax. But it also simplifies the transactions, which is not something, that simulation would allow us to solve. I see is there no question for please feel free to chime in the discussion thread. If you come up with something

[20:00] yeah I think, that let's go to CAP-72. Because I can see, that folks are excited about it. So again 71 is kind of what I think is a prerequisite to 72 just to make it kind of not happy out of the box. So CAP-72 is about the mentioning contract signers for scar account for T account and motivation this gap it's this in the original discussion as well. But basically well to allow you to do difference in this existing CH account. Because G accounts still have

[21:00] quite a bit of adoption rate and this allow to extend their functionality arbitrarily. It can be new ways to sign for operation. Operation. It may be a way to implement new policies and stuff like, that. It is really very open-ended. I think there is a lot of demand for passes. It is a pretty hot topic and an argument can be made, that maybe you can support this natively as center. This is not the part of CAP-72. But I don't know I'd like to gauge some interest maybe another discussion can be started. If someone thinks strongly, that has to be a feature on a G account. Now

[22:00] of course. If in the future we support signing for transactions with C account this will become a nonissue. Because you will be able to do anything with a C signer, that you can do today with a normal T account. So well yeah I don't want to spend much time on motivation here. But I think it is pretty significant factor like the ability to u modify the account like a lot of things to do this. So what do we do for this? The first thing, that we do is we add a new ser type, that is stored in the account entry in a similar fashion as any other sign and it is called the dated serer

[23:00] which is basically how it's it connects to CAP-71 right it's also delegation. Because unlike u the cryptographic centers for example, that exist. Now they're just public keys. Get it center is a contract, that defines its own logic with its own cryptography and stuff. The every signer has its own weight in the same fashion as normal planners have weight. But the caveat for. Now at least is, that logated centers can only be used in the smart contract environment. Because well they are contracts. You cannot run contracts outside of smart contract m environment just yet.

[24:00] so unfortunately you will not be able to use the seat sign to sign the whole transaction. Transaction. But we can do anything in carbon and signing the transaction will work. If we ever support signing the transaction with a C account as well. So basically. If we support running the contracts transaction validation time, which I'm not saying it's necessarily going to happen. But it's definitely something we are thinking about. About. Again B I'm sorry about, that. Okay. So besides, that what we do is, that since modifications is a sorryation since operations the C accounts can only happen. But one notable use case we

[25:00] been thinking about has something to do with various account recovery flows right with using pass key or there are other custom logic to for example recover the account. Account. This use case needs an ability to modify G account from Turaban. And we provide this ability this new type of built-in contract, which I coined as GAC G account contract and unlike terror asset contract stack, which has to be explicitly instantiated GAC is implicitly it implicitly exists for any G account on chain not need to do

[26:00] anything to interact with it from Soraban you will be able just starting from a new protocol to call contract functions on a G account just really convenient and it is well overhead solution in terms of storage okay so, that's kind of a high level overview. Now go into a bit of detail. So in terms of the standard changes as I've mentioned it's very straightforward. We just extend the existing ser set of signers for the G accounts and we just them in the G account. They're not supported in some more exotic context like in some operations and stuff like, that but, that's a minor detail

[27:00] and. Then the GE account interface as well specified in the CAP and it is still up to debate the CAP as it is proposes to add an ability to add any type of address as a delegated signer, which might create some ambiguity like G account is a delegated center of a G account. But it's like G account itself is a public key. So we have kind of the same identifier, that may be in two different context and it may not cause some issues and confusion downstream. Downstream. So, it is still up to debate. Like. If you decide to not go with delegated G accounts, the contract interface may be simplified a bit. To

[28:00] manage signers just based on the address type, G signers would be always cryptographic signers for example and C accounted signers. That would slim down the interface a little bit. But anyways, the current proposal is just to have a pair of functions to modify a weight for a ED 25 signer or remove it. Then the same pair of functions to modify weight for delegated signer or remove it. And. Then two functions, that just manipulate the weights of the account. It's not like strictly necessary. But this seem like a logical thing to have. If you provide the basic account management capabilities anyway. So just allow to modify the master weight and update the thresholds for the

[29:00] account. Account. So these are just for completeness and not strictly necessary. So for the classic transactions as I mentioned the derated sus will not be supported at the moment. So transactions, that try to use them they will be rejected and there's not even a way to kind of provide a signature for a delegated. But for the smart contracts themselves we extend the building functionality, that performs authentication for the G account and this extension leverages 71 one where we would call the functions behind there, which will enumerate all the delegated signers existing in the current context and we will call this

[30:00] new Jate account of house function for them and we'll obviously use the XDR format for the payload defined in CAP-71. So it's directly benefits from it And another caveat is, that current management operations, that in this CAP u are they must have a high signature threshold to match the semantics of the set options operation. So it is something new, that we do. Previously we always used medium threshold for all the Rob operations to all G accounts. So, that's a small change to use high threshold for the account management operation. And I guess the only somewhat tricky part about the implementation of the G

[31:00] account contract itself is, that we kind of do something new for Soroban. Here we had a way to manage classic entries from Soroban. Not not just manage them. But add or remove new entries, which hasn't happened before right before the only thing we did with classic was we update the trust in balances for the account balances. Now with this CAP we will also modify subentry count this sub entry count, which affects the page reserve for the account and. If we remove a signer we also might need to remove a sponsorship from this signer This is all like perfectly reasonable to do on this robust side. It is a bit of work to kind of properly maintain the variance. But on the high level, yeah, I guess the main concern here is

[32:00] that, that account has to authorize its modification and it obviously does, that by authorizing the G account contract function itself. So on any call with I said you need to provide a signature, that matches the highway threshold and besides like performing the modification as well also authorizes modification of the accounts reserve and sub entries. The only difference between this and classic is really, that you cannot create new sub entries using some sponsorship. Because there's not even a way of setting up sponsorship. So. If you want to manipulate a G account with GAC, you need to have enough base reserve. You cannot use someone else's sponsorship. Which I think is generally fine and

[33:00] someone wants to sponsor a G account they can do, that by for example performing an XLM bundle with G account modification or something like, that. Yeah. So I mentioned already, that every G account function performance requires and it will require high signature threshold and I think it is pretty much it for the high level overview of the CAP. I think yeah I think I don't have much else to talk about like from bit more details in the camp. But I don't think there is anything too significant and the main thing, that not the main thing. But at least one thing, that I'm still not sure about is a final interface like what we do with delegated

[34:00] G account standards. But I think this can he can offline especially since Lee is not here and had some concerns about representing stills. And so on. Yeah. So any questions? Yeah, speaking of string keys, by the way, way, I do not think you will need string keys like an E string key for this one. I hope at least. So you will just have a G account and it can have a C signer. So, that's probably direction we'll end up in. So know your account time. Yeah any question.

[35:00] Okay. I think I don't see any questions for now. It's going pretty fast. Again, I would say like. If anyone has any thoughts or comments, please feel free to chime in the respective camps. And Mat is typing something. I'll wait for a few more seconds. Okay. So, close from the CAP. This has a somewhat naterization in selling balance of the account for hasn't been for. So why this is the

[36:00] case this is the case. Because classic. When we create a new classic entry or sub entry such as an account signer we need to reserve base reserve from the accounts, that owns the entry. Okay. Best reserve being.5 XLM as of today. Right. So it is not a strict withdrawal of the fee, right? We not like in fe or anything for, that rate. It just increases just reduces your spendable XLM balance on the account. It is just like we cannot bypass this mechanism, right? We are doing the same things, that we are doing on classic based reserve and just doing it from soran. Now and I guess the only intuitive non intuitive part about this is really, that this hasn't happened before. But I feel like

[37:00] it's not super offensively counterintuitive. Because when you authorize an account operation you basically it is like a high privilege operation anyway and you acknowledge the consequence quences and one of the consequences as well your days reserve can be increased on the account. So you can spend less XLM. Now it is the same as classic no way around this I looked into an alternative where like extra standards could be stored in the robite. And then you would need to pay rent for them it's not like it removes the fees magically it just moves fees in different direction. But automatically I'm not sure. If the approach other approach or is centers and Soroban is sources. Because creates some new interactions in classic st, that going to be kind of tricky to

[38:00] implement and maintain and are generally much more invasive than what proposed in this CAP. But yeah. If anyone is curious, they may look up the history of the CAP. Because it's the first version, that was merged. All right. I think we have like 20 more minutes. So why not go through CAP-73. While we at it? And CAP-73 really supports CAP-72 on one hand to allows the accounts to sign for the trust l creation. But also in general it just closes the feature gap, that has been there from the inception of soraban and I think some people are very well aware of it and it happened I guess just in some flows, that do not involve from custom o or

[39:00] anything. And the issue is basically, that. When you're doing contract operations in Soroban you cannot create new balances for the G account and new balance being an account entry itself for the XLM token specifically and a trust line for any other token and it is like not completely blocking usage of sack right for G accounts. You can ask the users to set up the trust point first. But there are contexts where you may want to do this programmatically. There is of course a capstone 72 context. You may want to use your C account logic to manage your trust lines. And it also helps to kind of bundling this with some programmatic operations.

[40:00] such as for example an example I saw recently from Tyler week. With, that you would be able to for example create a new classic asset effectively and create a distribution account transfer asset to the distribution account distribute later to the users all in the same transaction, which is pretty convenient. So yeah I guess there are convenience there is convenience factors there is a factor of really closing the gap and factor of being more compatible with C designers of J account with CAP-72, that's the gist of the motivation and the way it works is via two new functions for this to asset

[41:00] contract. Contract. These functions are change trust and has trust and again the exact interface is still a bit up to debate. But as it states. Now the change trust function operates in the same fashion as the forget the name of the operation classic the I think it's called change trust as well in classic the operation and what it does is basically sets a trust line limit for a given address. If the limit is zero. Then the trust line is removed. If the limit is non zero and the trust line hasn't been there. Then created and of course. If it is there it can be just modified. The question is whether we need to manage limit at all. I did some analysis among the trust lens, that have been

[42:00] active during the last year with 98 plus% use limit trust and limit over one to the power of 18, which basically represents infinity. But. If anyone is aware of any use cases for limits, that are low please let us know u. Because we might get rid of it for the sake of simplicity. Because yeah it is not really obvious. If it's necessary and for this programmatic manipulation of trust twines. Really likely, that only binary modifications would be possible. Because if you need a non- infinite transpoint limit, you're doing something super specific probably and it seems kind of weird, that you would know, that the wants to do, that. It seems really unlikely. Unlikely. And another function has trust just

[43:00] checks. If an address has a trust line. And the purpose of this function is really to make for better programmability of trust management. Because change trust operation requires authorization from the address, that the trust lane belongs to. And for example, you are performing a DSD transfer to a new address, right? And normally you would only need O from the transfer source. But. If you wanted to create a destination trust lines. Then you would also need us from the destination as well. You cannot just unconditionally call change trust to make sure, that the trust point exists. Maybe you could. But then you know you could make it. So you don't need to require us. If well it's not verified is really something up

[44:00] to the further discussion how this interface looks like. But anyways this is the current proposal. The h trust function really helps to check. If you actually need to call change trust or not and thus whether you need to require o from the receiver of the balance or not. Which is kind of convenient and. If you wanted to call this from Z contract similarly to CAP-72 this modifies base resource and again in the same vein we cannot avoid, that. Because it's classic semantics and we require authorization on the change trust operation in same way of classic. So the base reserve modification ation is just yet another thing, that you're authorizing by signing this u and it has the same

[45:00] downside of saying about it going, that sponsorships are not available. So. If you want to create a trust line, you need to have sufficient excellent balance for it. And for the excellent specifically there are no trust lines and instead just create a new account. Then an excellent transfer is performed to a G address, that does not exist yet. And this account will be funded with this newly transfer balance. The only caveat is, that the minimum transfer amount here is one XLM. Because that's the minimum balance, that H account may have. If the balance is less than one XLM the operation will fail as it does today. Well it will fail with an error. So yeah XLM is arguably much simpler. Because it does not require any

[46:00] , and yeah, it just is very simple in this sense. and yeah, I think, that's pretty much it on your head over, that's a pretty simple CAP. yeah, the only tricky part about it is really handing down the interface. Because yeah we could make it much simpler. If you went for like binary either zero or infinity trust. But we need some signal whether it is too restricted or not. Okay question in classic one of the reasons sponsorship were added was to print accounts created by wlets from being merged by Z party for the base reserve. Is it a concern for creating accounts on transfers of sponsorships? Sponsorships? I am not sure I understand the question create an account on transfer

[47:00] why would you isn't, that how it works for classic as well like. When you create an account you it's like an excellent transfer maybe I could go to this page I cannot. If you're talking Oh no,

[48:00] that's unfortunate. Yeah we can discuss this I think I am still not sure I understand this maybe it is some bit of classic protocols, that I'm not aware of I want to count out on currencies CAP, well, technically the Okay, I think it's technically the transpoint part and XLM part are kind of independent. I bundled them into the

[49:00] same CAP. Because they really serve the same mission of like dealing with non-existent G account balances. So I thought like it makes sense to close this gap all at once and not just for a part of the site balances. But yeah. If we figure out, that something is much harder to do or much easier to do, we could build this up further. But given how simple it is, I would hope we could do both atomically. So yeah, that's recaped. I guess the only one thing to say for. Now is, that we are still not sure, which protocol will this go into this get through. So likely some of the CAPs will come a bit later, later, may come sooner. So just stay tuned for, that. And yeah, please feel free to leave any feedback, suggestions in the C

[50:00] discussion. Discussion. thanks Ariel.

[00:00] Hi everyone and welcome to this week's Stellar Developer Meeting. This week at Stellar we just concluded the latest cohort in the incubator collaboration we have with Draperu and I thought since we just wrapped this up and 20 teams graduated from the incubator program I thought it could be interesting to invite someone who went through the program last year. So today I have the founder of Flashback in the studio. So yeah, please introduce yourself and let us know what you're working on. Hello guys. So my name is Briu. So co-ounder of flashback. And so yeah we were part of this first and initial batch for the draper cross ster unbug program, which was I

[01:00] think between yeah November 2024 to February 2025. And so yeah some just a bit of background about myself. So I have PhD in computer science mainly in machine learning artificial intelligence. So I did, that for seven eight years. Big patient with in AI and all you can use AI you know with cloud technologies and the fact, that today AI is very related to cloud technologies. I got very curious about what we call the decentralized physical infrastructure network the cloud storage cloud computing sovereignty data protection etc and of course since 2016 I discovered the cryptocurrency space initially with project like lisk and arc. So very old project I would not say I'm no g. But close to

[02:00] And yeah, I discovered the blockchain more kind of patient and since March 2023, I decided to start my entrepreneurship journey start to build my first solution, which was a decentralized storage network. Trying to in fact build something for fast data retrieval. Because if you are trying. If you already tried you know fon iwave it's made for archival data. But once you want to do what storage and to use it in a very frequent way is not very compatible for this kind of usage. So we wanted to step and to try to build something there. But you know building solution going through for one year and a half we understood like we talking with thousand of I was hundred and thousand of funders with different conferences par blockchain week ETH progCC token 2049 we discover quickly, that yes

[03:00] in fact flashback was born from an simple problem it's a vunderlooking problem everyone is facing, that. But yeah. If you want custom I have a small presentation to help people to go through. Through. Yeah let's go to the presentation. Presentation. Okay. Okay just to be sure it's PDF. Okay, it's loading. Here it is. Okay. Okay. So, yes, Flashback is an AI power code defecification solution.

[04:00] So we want to be this unified interface for developers and companies to be able to diversify with centralized and decentralized cloud providers. We want make we want to make it cheaper, simpler and more flexible to you to deeper your data storage and in fact make the mic cloud journey something, that you can start at the beginning of your entrepreneurship or. When you want to start to build a project. So in fact basically we have the large vendors you know Google cloud AWS Microsoft Azure they are fast and reliable we know them well they have a lot of stacks. But the thing is, that they're very expensive I think we know we as a developer we know this me of. If you want to justify your please you just have to say AWS it's very well known very difficult to understand all you are doing your expenses is and at the same time most of the company. When they started to deploy with one provider they depose. So much solution on

[05:00] the top, that they have this fun looking issue, which is the major issue today. Because it doesn't allow you to be great easily to another provider. So you're stuck with the bunder and the other side we have the decentralized solutions more affordable more privacy rel compliant and low cost. But think, that fon for virus. They're using the blockchain technology and they're using a lot of protocols and decentralized consensus, which makes the system more slower. And so at the same times very difficult for developers to know the tax and or to build efficiently with this solution. So yeah for a company very quickly at the beginning of the journey you can spend hundred hours even more spend a lot of money to deploy with one or two or three different providers to build your own infrastructure it can be up to 25% of your revenue you're going to

[06:00] inject in fact to develop this at the same time DP technologies very interesting technologies. But it's only 0.1% of the market size. So I would say, that it's still a niche, that can be explored by people. But people do not have the time to explore them. So it is why we have decide to build flashback. So with flashback you can do a cloud divers it's cloud diversification platform. So in fact you're going to have three different advantages. The first one you will be able to reduce your cost. Because by deploying on flashback what you can do is indeed play with centralized providers quite expensive. But sometimes play with decentralized providers you can have this easy access to deep technologies. We want to make it very easy like you connect you deploy your bucket. with this providers, which are some specific services on the top to deploy buckets. And. Then of course we want to make the

[07:00] mutual deployment seamless not only for large companies. But at some time for startups for five coders anyone, that want to indeed start at the beginning of the development of their technology to have a multi cloud approach. And so to not to get right the bundle looking issue. Issue. I think it's mainly for the main presentation. But what I can do is perhaps. If it's okay to make like a little live demo of the platform. Sure, let's do, that. Okay, let's go. deos is always fun. Live demo is always fun, you know. Yeah, it's let's see what's u Okay, I can share the screen and just get used to the system. just to be sure, that I will share my work. Can I share my work screen? Okay, let's go like this. It would be easier. Because we're going to jump between my spider and

[08:00] Okay, great. So, So, this is the platform. Very simple. So with the platform of course you can read about the platform. So it's platform.flashback.tech and of course you can learn more you have a documentation I just open here the documentation you can go through the documentation a lot of information about indeed what we are building why we're building this you have introduction storage want to make it as transparent as informative as possible for people and of course you have some guides to help you to create your buckets repository configure with the system uploaded on the files. So today we are focusing on the optic storage, which is the first layer. I will say, that any kind of cloud solution. But indeed in the future want to have

[09:00] more features according to what developers can bring us in term of feedback and information what they want to have in this platform. So feel free as well to give any kind of feedback. You have a lot of API references. If you are more in depth of indeed interacted with our flashback API. So we are trying to make it this as flexible as possible for developers and indeed being able to play with the platform in the best way. So let me of course you can sign up with your Google or GitHub account. You couldn't create otherwise you know email password it's okay and of course login. So in this case I'm going to log with my Google account just a few time and here

[10:00] of course you have the platform. So the platform made we try to make things very simple to understand what's going on at the same time on the microord level. So the idea is to abstract the fact, that you're going to work with different code providers or to provide you all the information to understand how you can interact with different code providers. So you have an overview page where indeed you can have some links to the documentation you need and to start your journey with the platform. Some statistics transfer packet activity. So the packet activity is part of the cloud storage where we have the repository and buckets. So let's see the buckets. So I won't go deep in term of what is a bucket I think people who already are using no AWS or GCP or some S3 compatible solution can

[11:00] indeed understand what is a bucket. So here in fact it's with we are starting kind of flashback buckets to connect your buckets from AWS or GCP to the flashback system. So very briefly I want to go far. But for instance. If you are using AWS you can have different buckets. So here you have like three or four different buckets and indeed you can indeed find this bucket here. So two connects. Connects. Let's see. If we can just cancel this one for instance. Deleted sure. If it's going to work. Ah okay. Thank you. So to connect a bucket you have different ways to connect your bucket. You can connect your bucket with GCP AWS Azure. So Azure is bit different. So every provider has its own concept of all you can store you can do object

[12:00] storage with the cloud. So today we tested these five providers. You can find FCON. So we're using in fact through FCON we're using AAV, which is an S3 compatible provider on the top of Finch system is S3 compatible. But feel free as well. If you subscribe to the platform and want to try it to test the other S3 compatible providers. Yeah, you can try I know there is some pinata stuff like this. So feel free to get your API key stuff like this and to set up your system. But for instance. If you're using. And then IWS. So let's see, I'm going to give a label for my bucket and see look. I'm going to create a new bucket on my account. This way I can show you, that can work. So let's create a bucket on my AWS account. Oh, come on. You prepare

[13:00] everything to be log and you're log out. Huh? So, let's see. If we can go fast. Sign inh. No way. See later. Just want to skip for now. Now. Of course, always set up a lot of security there. But yeah, let's create a bucket. Okay. So, we're in the we're going to create a bucket, that say like the thieves AWS buckets and PH blah We're just. So you can go through these different stuff depending on you're working with its. But of course for us and for the purpose of the demonstration we're just going to create the bucket directly. Here we are. And. So this field bucket I can just keep

[14:00] the name here. So it's good to there is some information to provide of course in the platform to be able to set up your buckets. But you need let's say, that it's my VSS buckets fivebs here some stuff. So yeah. If I show you my secret and access key the I'm not sure I'm sharing my work screen, right? So, yeah, I can pause it for a moment. If you want. Oh, yeah. Just. If I can just this way. Yeah, in this way I can just perfect. Thank you, custom. Thank you for my privacy. So, let me find my keys and information like this. So there is a delegation system as well where you can delegate instead of indeed

[15:00] setting up the API keys and the secrets where we have to store it and to split it in different servers. You can use a delegation system, which allow you in fact to not share with us this kind of secrets or to keep a kind of a better security for you and your privacy. Okay, just a minute. Just this one. Okay, I'm just going to copy paste. Just one second. Of course, my computer is slow. Okay. And this one. Here we are. Okay, you can share again my screen. I think you're custom. So you see my screen normally. Yeah.

[16:00] Okay. We. So we said key secret key in this way. I can create my packets and too many requests. What did what did I do? Do? Okay. No worries. It's part of the test. Instant navigation. So what we're going to do is, that we are we're assuming, that you create your account. You can do, that with GCP as well. So same for GCP you have all the information to provide and according to what you want to provide it's I have a sound from my side Kirsten I don't know. If you have the same you have one okay no I have a strange sound in my ear anyway. So depending on the different information you have to provide. So Google cloud storage is different information. So of course the best is to refer to create the bucket for instance to get the information or

[17:00] or to create the bucket. So there some information to provide to connect your bucket with a solution. So once you indeed provide your bucket. So it's create your bucket you have this status in fact we're using a technology, which called the bridge node. You can as well find some information in the documentation. So we explain what is the bridge node and indeed the purpose of the bridge node. So we have some region we're covering. So the bridge node is mainly in fact a system, that allow us to interact with the different providers. It's our AP technology and it's where in fact we can get and collect different metrics of your different buckets. And. So of course once you create your buckets you can create what we call a repo. So we have created I created this morning in different buckets and of course you have this repo. So. When you want once you want to

[18:00] create a repo you can call it any names you want like repo 6 five like this you can add one or two packets different. Because let's GCP one create okay I should disconnect in fact I think. So anyway. So I continue say, that you just yeah it's anation. But it's okay it's part the yeah it just went live. This this just went live and you already told me, that anyone who use it you would appreciate feedback. Because it is in the very early stage of being live. So. If if any of you try it out I know feedback is very appreciated. Appreciated. So these things happen. Exactly. We have a button to give a lot of feedback. So feel free to give any kind of feedback. Indeed it we started to develop this in fact

[19:00] just straight after the. So all this concept since February. And then we want to add this Stellar concept of the pin we have. But we can come back on it later. And so in fact. When we once you have a repo in fact and the repo allow you to indeed have your different buckets. So you have the GCP AWS buckets and you can create to API keys. So here I create an API keys, which allow me in fact I will try to make it a very simple demo. If it's working to test any storage. But indeed for instance. If I want to store. So I have a repo I provide some access key secret key. So of course I did it in JS and stuff like this and of course. If we can make this little example we are going to transfer this genus bill. I

[20:00] took the text of the genus bill, and now we're going to create the genus bill and copy eight. So let's go. Here we are. So right. Now we're storing with an S3 endpoint to S3 buckets. So we can see, that we store something. We can always check, that is working. But. If we're looking the second AWS buckets, we should probably see this. We have a lot of test P8, which is here. But of course what is very funny is to see. If in our you know Google buckets from an S S3 endpoint we can get something there. So we're going to copy paste in term of bucket name, which is great. Because GCS and AWS is using some same wording. So let me go on the platform. You can find in fact duplicate

[21:00] names directly on the report details. So. So this one is the GCP one. I'm going to copy paste and here we are. Good. Cut and we're going to send this same copy to the GCP. So we have an S3 end points and we're sending to DCP. Okay, thanks to in fact this bridge node, which is this address. Okay. So we can check it is do don't log out please. Okay. And here we are. So of course alpha vision right. Now I just show you with an S3 endpoints to store with

[22:00] GCS and AWS. You can try with Azure through the tutorials. You can indeed provide some feedback. If it's working or not. It's a truly alpha vision. We're going to do a more stable vision in September with indeed more better UI and some improvements such as the private bridge nodes. Because today the bridge nodes are hosted by Flashback. But the idea indeed is to let you to be able to deploy this node in your tenants. And. So to manage your strateging my screen should work like this. Okay, perfect. So it's globally all about the presentation about this little live demo with all the bugs we got. But

[23:00] yeah, of course it's still an alpha vision, an improved beta vision for flashback and our road map is very simple. We want indeed stabilize all of this. It's always a complex features. If it was simple you will have this everywhere. So we decided to take this challenge and thanks to Stellar, we have this chance to indeed push it with Stellar. We have this in the Stellar community fund for the one who are interesting. There is in fact a second product and feature called the flashback DP where in fact we as you can see in fact with this platform you interact with the platform with the service level of cloud providers. So of course it's still the services but. If you want to interact with I would say data centers or in a higher privacy model you the flashback DP will allow you in fact to interact

[24:00] with the data center is going to ask is hardware a software connect is bridge nodes. And then connect to the DBN marketplace. And so the Stellar is going to play a big key role there. Because we're going to deploy all smart contract with Stellar to indeed manage as marketplace as the same times to collect thanks to our bridge nodes to our smart contracts all the quality of services agreements and all the metric related to, that. So in the marketplace what you're going to find as a consumer you're going to connect to the flashback DPIN platform. You're going to find different offers from different providers. You're going to select the ones you want. Then these ones are going to give you thanks to the bridge note, which is S3 compatible and stuff like this. We believe, that they're going to use you know like system like Mio. So they are going to give you an API keys and stuff like this. So you can

[25:00] already interact with in S3 in a very easy way and of course. Then once you decide and you have the right agreement with the storage providers we deploy all of this in the smart contract. And then we operate and the bridge is going to say okay this is the quality of services of the storage with the consumer speed I mean upload download speed latency stuff like this and according to the quality they agreed to increase the reputation score of contract on earth as a providers as well. And then it's where you start to have a bit of tokconomics and stuff like this. So it's what we want to achieve with Stellar and normally we should have the first trench one delivered within the next weeks. So it's our next goal right now. That's super exciting and I think it's really interesting. It's an interesting use case for smart contracts. just before we went on

[26:00] the call here, we were talking about there's a lot of focus on DeFi applications on chain and more like working with tokenization and real world assets and. But but this is a very to me is a very untra untraditional blockchain project. But. But you have taken some of the elements and applied, that in a project, that or a product, that you don't usually associate with blockchain and I think, that's super interesting. Love to see more of, that. It's it's interesting to see these kind of use cases where you are thinking huh, that was not obvious to use blockchain in, that way. But it works really well. So it broadens the scope of what you can do and how you perceive blockchain. So yeah, super interesting. Interesting. Yeah, thank you. Thank you. Indeed, it's I would say, that for the ecosystem. If people are very curious about this kind of technology, it's the deep technology finally. So

[27:00] the central physical infrastructure network some people are indeed deploying their own blockchain and their own protocol stuff like this. For us, we prefer to use the existing blockchain and to build in fact with smart contract. Which is great with Stellar is in fact the flexibility. I mean we first in Rust, which we have a preference in rest. Sorry Goland. But yeah we have a preference in Rust. The Stellar kit is very nice and the thing is, that with all the programs you're doing like with the university is great. Because indeed you can discover the ecosystem and to you can truly develop something real. Great. Yeah. I don't know. If there's any questions from anyone watching. But otherwise I say this was this is super great to see this demo. I remember talking to you about this about a year ago and I

[28:00] thought this is an interesting use case. I would love to see, that in real life and here we are. You launched the first version and yeah I've been playing around with it and I think this is super interesting and everyone who plays around with it. If there's any. If you find anything u I think I know, that you're very u you're very appreciative of feedback. It is the it is early days of the platform. So yeah, please forward any feedback you may have. I think we have a question here from Matias. It also raises awareness from other nonblockchain orient corpse and orgs to start thinking of integrations to make things more efficient. Yeah, I think this is a good example of, that. Exactly. Exactly. And I think we blockchain is AI cloud storage it's very demanding in term of I think, that's put for the blockchain. So it's why it's maybe comparative is not. So developed

[29:00] because there are still a lot of things to do around blockchain in term of scalability to make this kind of use case more and more applicable with the blockchain. Yeah, we see a lot of focus on AI not just on tooling. But also like implementing both blockchain and AI in the same application where it makes sense how are you using AI. I know. If I see on your website you do mention AI. So in what way are you using AI in your application? Application? Yeah. So it's true, that. If people go through our website we don't do not mention. So much about decentralized technologies and stuff like this. And indeed. Because it's like for us a kind of motor and people you know see the design of the car and not specifically the motor inside. But in our AI we are going to I mean from the AI we're going to develop we have different steps of the we're going to have the first step is could be a chatbased recommendation system. Because basically most of the

[30:00] developers v coders even exper people with expertise sometimes needs do as well to see how they can leverage in the best way the platform. So we're going to guide people. So chart to understand what they are looking for in term of multi cloud configuration. If they're looking for a micro configuration. If they have some credits or we can help them to reduce the cost and sometimes to take all the benefits of this wide ecosystem, which is extremely fragmented today. And. So it's going to be the first version of AI and indeed with the use AI needs data. And so AI can't do a lot. If you don't have a lot of people using the platform. So it's why I'm pushing people to indeed try and use the platform. Because this AI is going to indeed learn more about your patterns and more learn about all you can do with the

[31:00] platform. And then improve your recommendation in real time saying like oh yeah you are using this kind of storage, you're doing everything in odd storage with AWS. While in fact we can see, that 50% of your data are not used in a frequent way. So you are just being a lot perhaps you can just be great part in StarJ or FON and reduce the cost. And so it's where the AI is going to intervene in your journey with the platform and what we want to achieve with AI for decentralization. It's you know decentralizing AI is always complex is more perhaps what we are looking at right. Now is perhaps on the privacy level perhaps on providing all the is doing certain recommendation stuff like this. But right. Now the decentralized AI is still kind of a baby in the crypto space. Yeah. I noticed something you said, that you're not really advertising. You don't really write, that you, that you use blockchain.

[32:00] and I think, that's actually it's interesting. Because I see blockchain as a technology just like many other technologies. It's not necessarily, that the users don't really it's information, that if. If you have a really nice imple implementation, that doesn't really have where users don't have to jump through a lot of hoops, that we usually see in a lot of blockchain applications. It's not really relevant. How you choose to solve the problems is not you use technology. In this case you use blockchain. I love to see it be more normalized, that blockchain you don't need to put it up as a big banner you're using blockchain like more normalized using blockchain in different kinds of applications. So I think, that's, that's interesting yeah we have a question more from Matias he asked what you think about awe

[33:00] a good question aweave is extremely nice in term of volat of course it's made for this I mean it has been designed for this I know, that there is they're doing more and more kind of development on the top of the protocol there right. Now to indeed diversify with other storage type like storage and or at least storage perhaps our wave is a bit expensive from my u point of view specifically. If you want to store NFTs. So you know very small portion of data the cost for a terabytes is very specific application at least for the main the core protocol of code I know, that they're working on different angle and trying to simplify or doing what the cloud is doing finally. So I think the next evolution they're going to do can be good I think it's

[34:00] they got the same issue, that Fon got in the past. Because Fon did this protocol very interesting consensus by the way. I mean it's very the math behind it is it's beautiful. I mean they did something very nice zero knowledge applic too slow and I don't know all people know about, that. But you have to. When you store your data with fon you have to unlock a portion of gigabytes you have to seal it. And then in seal it. So this mechanism, that prove, that you're somebody hosting your data at the same time it's very slow to retrieve the data. So they have to work on a lot of systems and you know to accept certain central centralized process to make it faster. But anyway it's part of the blockchain journey I believe, that more

[35:00] and more the blockchain is going to evolve the best it would be in term of u decentralization for storage and computing and more great well thank you so much for joining today for me It's it's been fun to be a tiny part of this journey. I've followed you along the lines since we on the side since we met first time last year and see, that you launched the product and yeah, it's great to see. So everyone please go check it out and yeah, thank you again for joining this week. Week. Thank you very much guys. Thank you everyone for joining. We'll be back again next week.

[00:00] Hello, welcome everyone to this week's Stellar Developer Meeting. Today joining me are Francisco and Estan from Pzelabs. Pzelabs should be familiar to any of you who's been in the community for a, while. They have been building on Stellar for yeah way longer than I have. So welcome guys and yeah just please do quick introduction and. And then we'll get started. Great. Thank you, Carson. My name is Estean. I am building patals since 2022 where we met all the Stellar team back in Meridian Rome. Since. Then we have been building source undefined and in this presentation we will explain a bit more, that Francisco.

[01:00] Yeah, I'm Francisco CPO Baltabs and we are excited to present the hackathon and motivate everyone to build here. Yeah, as a quick yeah, a quick comment, we are with Francisco. We are currently at the Draper University in San Francisco. So I will encourage all developers to join all the programs like grants programs, that Stellar has. Because like the opportunities, that you can get like we are getting. Now like currently I am in the dorms of the draper university the opportunities is they're really great. Great. Yeah, Draperu is a program we started is a collaboration between Stellar and Draper University we started last year and continuing this year where like you guys you stay for three weeks

[02:00] go through a really intense program with a lots of different things everything from business to yeah the financial parts and it's a great program but, that's not what we're talking about today. You are running you're running a hackathon with Stellar hacks and I think to lead up to, that to talk about the hackathon the idea is, that in the hackathon, that the participants are building on either source or on defendex or both. So maybe we start with an introduction what is source swap and what is defendex and what can you build on, that? So yeah, please take us through the basics of both products. Thank you, Caren. Please, Francisco, I will share the screen.

[03:00] Great. So ster hacks with the ster hacks you can swap and build vaults with palas source app and defendex. So let's talk a bit about source. And then we will talk a bit about defendex. If you have questions I think you can write them in the chat right. So I will stop. If anyone has any questions we will stop there and maybe we can share more our screens we can take a look at the codes etc. Source is a DEX and a DEX aggregator on the STA blockchain and as a brief introduction it was the first DEX built on Surban on the smart contract side of the Stellar and we aggregates liquidity from multiple liquidity sources or multiple platforms. So on the right you

[04:00] have like a swap, that got gets loaded through Soros swap, Aqua and Clinics AMMs. In order for you to understand like the tech of Soros. And so you can have like more ideas on how you can hack and build on top of source you need to understand, that source has three components. Components. It. There is the AMM. Then we have the aggregator, that aggregates is a smart contract. And then we have a road API. So our road API is the one, that will, that will optimize your trade, that will be executed on the regulator and. If you get a trade, that will go through source AMM it will go through our pools. Source of AMM is where you can create liquidity pools. If you want to do like a simple swap or. If you are building a

[05:00] protocol, that needs a liquidity pool, you can create a list liquidity pool on our AMM. It's a classic swap version two type of AMM. And we have a router contract, that does everything for you. So you can create new pairs through the rotor contract. You can add liquidity through the router contract. Remove liquidity and swap through only one contract. So you only need to understand this one router contract and we will put the links later. But it's github.comsource core. So all the core smart contracts are in, that core repository. Now I am reading the comments sorry. Yeah hacks. Yeah let's go. Great. And. Then we have the aggregator. If you want to aggregate multiple protocols we

[06:00] already built a contract, that handles all those transactions. So you don't need to think about Fenix or source. You need only need to inter interact with only one contract. And then inside, that aggregator contract we have all the adapters, that will help your transaction go through all those different AMMs next slide please. So this is how it looks a transaction through the simple. So you just put token in, token out, the amount you want in, the minimum amount you want out, and. But the tricky part is this DEX distribution like how you distribute your trade between different exchanges, between different dexes. And this is how yeah, no next one.

[07:00] So you will need to create this object. But you don't need to calculate it yourself. We have it in our road API. Yeah one back sorry the yeah this one. This is how the transaction looks like on the ster explorer. So you put like how many parts you want of one trade to go through protocol zero, which is Aquarius how much part you want to protocol two, which is source up yeah any questions until. Now no through this aggregator you can touch all those liquidity sources it's only one contract, that your app or something, that you are building needs to interact with it's only one contract and this contract will execute all transactions and will do all these subcontract calls necessary for

[08:00] that trade to go through. So how do you get this optimal vector of DEX distribution? You can calculate yourself or you can force it. So you want you can force it to go through like specific protocols. That's also, that's also a possibility but. If not you can use the API, that we have and this is like the third part of this source app tech stack. We have a public API, that anyone can use. We created an a APK key API key for those, that are building on the hackathon. So you can experiment with our API and the easy thing the cool thing is, that you just put what you want to trade, what are the protocols, that you want to implement. And then returns you like what is the best way on

[09:00] how you split the trade. So we have in the description of the hackathon there is a link to our postman collection. If you want to talk with the API you can go and check the postman collection. Because it will make it much easier for you how to interact with the API. API. And next one. Yeah, this is the all the documentation you need. We have also an SDK. I forgot to put it in this slide. But there is at source SDK. That's the npm package on TypeScript. If you are building on TypeScript. So you don't even need to build all those API calls. There a function for it. And we have on the telegram group we are sending reposit example repositories, that of projects, that use

[10:00] our APIs. There is a question here Matias the distriution in this case will be the 60 3010 shown in the previous slide right yes. So in a previous slide there was like this distribution of 60% 30% 10% and cor, that's correct, that the next distribution you say I want 10% to go through Phoenix and the path will be XLM direct to USDC. Then you put 30% I want it to go through Aqua going from XLM to Aqua to USC. Because I think or you think or your program thinks, that's the best way to do it and 80% to do it or 60% to do it through Sora. Yeah. Great.

[11:00] Yeah. And finally we in our back end for our API we use the source indexer and this project is completely open source. So. If you plan to build something, that requires information of the traits on source. If requires yeah. If if. If you need to build an indexer or. If you need to improve the indexer, that we have the link is on, that slide. But it's sorosab.com sorry github.com/sorosabsupql, which is the technology, that we are using. indexer with subql and of course. If you're more interested talking the telegram there is the readmi has all the description on how you create this indexer and yeah you can build like maybe like a front end, that shows the last transactions or

[12:00] a bot, that will send you a alert. If there is like a difference of price. So you can buy a token. Something like, that. Does the source of indexer relies on mercury? No, it doesn't. The source the SUQL indexer it's its own technology. It's on TypeScript. There is like Docker. So you bring up like three different Docker containers. One, which is like the worker, which is doing calls to the RPC all the time to get the last test block. And then it will ingest it to another container, that will check, that there. If there is the event, that you want to check. And then it will ingest the information to a local data database. Then later it's you can query it with graphql

[13:00] So. Now the findex I'm not going to see the questions. But so. If the stean or cast can tell me. If there is any question. Yeah cool you know let me know. Well. So the findex we want to make easy. So what is the findex? The findex removes the technical complexity for apps, that want to offer savings accounts for their users. So you know, that if. If you're a wallet or an application end user application you may want to offer some sort of savings account and at the same times

[14:00] you have defy protocols or real world assets, that can provide you Jill to make this feature of savings accounts possible. But this is difficult h you it's technical to integrate defy it's difficult to manage risk and difficult to monetize on top of, that and it's time consuming. So we created the index to help with, that. So our plugand play software can make you earn. When you uses earn and all with, that with without the crypto complexity. So with the findex. If you're a wallet

[15:00] you use our plan and play software and you can offer yield to your users and this is done by using defy strategies. So. So you can use this device diverse device strategies to offer multiple options. You have automation on the smart contract side and you can always look for the best earnings without the need to for without the need of the user signatures for every movement. So to understand the findex we need to understand two main concepts one is strategies and one is v. So for the strategies is the smart contract, that connects the DeFi protocol

[16:00] is the connection, that we have with DeFi protocols and also we can include there some automation, that can benefit the users. And. Then we have the vaults. The vaults are the savings accounts. It handles all the fee distribution, all the accounting for users. It manage all the how many users you have, which, which user has the amount of the funds, that any user has etc. So let's see an example. So this is the blended strategy, that we have right now. We have it for USDC euro C also. So we basically we lend USDC to blend on in a blend pool. We

[17:00] harvest the blend rewards. We swap this blend rewards for more USDC and we lend again. So we get this autoco compounding effect on the blend blending and borrowing protocol. Then we on the b contract we can include multiple strategies. So we you can expose the users to multiple pools. In this case, we have this USDC strategy on the blend fixed pool and on the blend gel blocks pool at the same time. So. When a user deposits into the B contract, the funds are distributed automatically on both pools. Also. If you want to you can have like one 100% of the money in just one strategy. But

[18:00] that could change in the future. So you can move all the fonts of your users to the other strategy, that is performing better. And, that the good thing is, that the user don't need to know, that their phones were moved. You just move it. But also you as a manager of the vault you cannot take the funds of the user out. Then. So this is what we have right now. So. If someone wants to create a new strategy, that could be more interesting like a leverage position strategy, strategy, you will need to implement the strategy trade. So this is how it looks like. So

[19:00] you just need to put code inside, that reflects the strategy you want to. do with the find index with the index just need to comply with this function and. If it complies with the function you can plug it to the index vault and, that strategy will be exposed for any wallet, that want to offer, that kind of strategy. Then on the board, can I say a small comment on the strategy? Strategy? Yeah. Yeah. So we want to see more strategies, more ideas, that you can come maybe other more can be more risky maybe using other protocols.

[20:00] , as Raso said, like the average strategies, you can short one asset, you can long like 9x with the current like. If if you. If you check with blend, you can lend borrow. And then swap and borrow again. So you can think about those kind of things or even using other protocols like sa Yeah. So, that would be like a very good idea of a hackathon project, that works with both protocols as well. Matias is asking for the harvest function what will data will be options this byes. Very good question. So. Because the strategy trait is general for any kind of protocols like say source swap blend

[21:00] or normal or Aqua FxDAOo you don't know we don't know beforehand what are the parameters, that harvest function will need probably you will need to submit some like some instructions on how the trade should be. If there is a swap or not you know, that's and Matias yeah. So it's an optional parameter, that you may need for some logic. Then we have the b B contract role. So. If you want to create a vault for a specific use case and for example combining multiple real

[22:00] world assets and you may need to create these roles in order to create a vault. So the manager can do everything. But taking the user fonts. So you can change who is the rebalance. You can change the other roles. Rebalance manager can only rebalance the receiver can only do fe related stuff and the emergency manager can rescue funds from the users. H. So in order to create a vault you can use it in our front end. Then you need to invest or rebalance for the first time. So the vault will know how to distribute the funds automatically. Then you implement it in your app in your front end and

[23:00] start collecting fees. Yeah I want to go want you to go back to the roles. Yeah, here there is a challenge here. So. If anybody wants to work on, that, how to manage like co how to co-sign co-sign these messages. So maybe the manager can be like a smart contract with different co-signers, you know, or you can have you can use like the cosign u structure of a Stellar maybe like created a front end, that will help like manage defined exults. That's maybe something interesting. Some ideas. Yeah. Yeah. Multi multic. Thank you, Matias. Then. If you want to do is do it this programmatically or include this in a front end, you just need to create this trigger this function on our factory.

[24:00] yeah. And. Then this is the front end we have right. Now is just for creating bolts. Bolts. So you just fill all the parameters here and you will have your vote. And then invest for the first time you can use Stellar C cli with the same with this instructions. And then we also have an API. So for the API we have an API key also for the findings right, that is public I mean we check this. So you can go to api defindex.io

[25:00] docs to see the complete documentation on this. You can also go to docs.define docs.define defindex.io IO and you have like more extensive documentation. And so yeah, that's and this is like an example of how to. If you have already an API client you can use something like this. So for example. If you are doing a front end to use the a vault contract erh you can call the our endpoints with the function deposit for example

[26:00] you just set the amount from who is going to be going to the deposit and we will return the sign transaction. Then you sign it and we can even send it for you. So. If you want to implement the vault in a front end this could be very useful. Yeah we also have we have deposit withdraw and we have the APY endpoints. So you don't need to build all those things. Yeah. So and we are here to help you. So please join the telegram group. We are going to be there answering as fast as we can and yeah we are here to help you.

[27:00] Great. Thank you for the introduction to Defendex and to Soros Swap. I think it's great to see, that some of the other teams, that you are you're at with the Draperu, they're already starting to look into how they can integrate your services and I think many more projects in the ecosystem could benefit from integrating with you guys. Francisco, you are sharing your screen. I can remove it. Yeah, sure. Okay. I don't know. If anybody has comments and questions. I think there was a question of Matias, that was not answered. yeah. So, he asking. So for the source of a aggregator, he says you don't need to specify the distribution.

[28:00] So you don't have to hassle to do the paths. That's not completely right. Because the aggregator needs as an input the specific path the contract. So the contract, that he cannot calculate what's the optimal path. However the API is the one, that will help you with, that. And you can try with the our API on public net. So. If you want to like start testing in production, you can do it. And yeah, we calculate the best path for you. But. Then the aggregator contract needs, that information. And. Then yeah. Okay, great. Let's change tracks to the hackathon. So right. Now we have

[29:00] the Stellar hacks. I'll just share a link for the hackathon. And this hackathon is actually about building on top of Defendex and Soros. So maybe. If one of you can talk a little bit about it. I can Are you sharing your screen? Screen? Yeah. Share this one. No, it's not this one. Okay. But show to show the like to hacks web page. Yeah, let's here we go. Yeah. So, this is the second hackathon we're doing with Stellar hacks. The first one was integrating blend. This one is focused on

[30:00] building on defendex and source swap. So. So yeah. Tell me more about what would you like to see? What is what are people building? So for example here in defy integrations is my screen is showing right? Yeah. So for example here we have a smart wallets a smart wallet using source and or the findex it will be great. So you can use our APIs the Pasi kit and build something with this an staking contract for SA LP tokens. So so, that would be great.

[31:00] a re balancer bot this is great. I don't know. If you remember here. But we have this role and this role rebalancer manager. So we can you can create a vault with where this rebalance manager can be the bot and the bot can manage the portfolio for us. MCP servers, that can I don't know I can tell him hey I want to create a vault and rebalance it, that could be very great something to doing something like, that. Then for the finex strategies. So ah. So for most of these not for the

[32:00] LPS stack staking. But for the smart wallet rebalancer bot and MCP server you will probably need to use the APIs, that we are providing. But then. If you want to use create for example an strategy you can start from the index protocol and modify the contracts for sample where the index here. So this is the main repo. You can go to apps contracts strategy and start coding there for more the index strategies and use all our the already existing variable. So you don't need to set up anything. You you wanted to say something.

[33:00] Yeah. Yeah, I am very excited about the strategies. I think this is like the Finex is already like very robust in the boats and we need more strategies. We need someone, that will came with some new idea on how to manage funds. You know, we thought about blend and rebalancing. But you can think about something more interesting. So and as Francisco said is like there is a trade already for, that like you don't need to and, that's a trade, that will be will it be easy to plug it into vaults and another comment I wanted to say about the rebalance is, that our vault contract. When you are a rebalancing manager the vault doesn't give you any like

[34:00] access to the funds at all. It only allows you to move from one strategy to the another strategy. So, that's why you can feel confident of experimenting with a rebalancer bot. All right. I wanted to say, that and about the LP tokens as Raph said in. When we first talk about this I am also very excited about I want to see people using LP tokens. So we created source swap erh. While like even. While Soroban was not on main yet and we created in a way, that LP tokens were compatible with the classic tokens. So and we want to see more people using LP tokens. Maybe you can send an LP token. Maybe you can create like a liquidity pool of two LP tokens. I don't know. Think about, that. Or maybe

[35:00] a strategy can need an LP token to have an exposure 50/50 I don't know to different assets. Yeah. Great. So, there's still one week left of the hackathon and. If you want to. If you haven't already started building and you think this could be a great fun challenge to do and a great way to learn more about source swap and defendex. Then this hackathon is a great opportunity. Go to the link, that I shared in the comments, the door hacks link, you can read more about the hackathon the submission requirements, the deadline and what to do and these great examples of what the pot team think could be fun to see and would love to see being built. So. So yeah, go check it out. It's it's a great fun

[36:00] hackathon and as I said there's one week left. So plenty of time to do something fun. Fun. It's up to the 1st of August. But yes until the 1 of August. Yeah. And and final comment we will be helping. If you have any question please ask them directly. Ask the question directly. Because some maybe we don't have the best documentation. I don't know we are trying to do our best together with a lot of things we are trying to do. So please be patient. If we don't. have. If you think you don't understand please ask. Because probably maybe we don't have, that answer in the documentation and it's very good way to help us to improve our documentation. We built these APIs. So you don't need to inter interact directly with contracts. But you don't need to do it. If you really

[37:00] had want to hack hard, you know. So, yeah, thank you Karen for the opportunity and Raph and Boxy and all the team organizing this hackathon and Jerome. Jerome. Yeah, they're really doing a great job with these mini hackathons. So, big shout out to them as well. I see Raph shared a link to the Telegram group for the hackathon. So yeah, ask away. If you have any questions. It's there's still time to build something cool. So. So please visit the hackathon page. Okay, great. Any any other questions before we end this call? Doesn't look like there's anymore. But thank you for joining. I know it's a crazy busy week for you. Being at Draperu is a lot of fun. But it's also a lot of work. We we were pitching the Findex to Tim

[38:00] Draper on Tuesday. Yeah, Tim Draper is a VC legend here in Silicon Valley. He was one of the first investors in many cool companies like Tesla, SpaceX, and ton more companies. So being a being having the opportunity to pitch Tim Driver is definitely an awesome opportunity. Opportunity. Yeah. Yeah. Because we think, that the millions of users will have their first Savings account through a wallet, not a traditional bank. Yeah. Great. Okay. Thank you everyone and you too guys. We'll be back here on Twitter next week. Thank you everyone for joining. Thank you. Bye bye. Bye. Good idea, Matias.

[00:00] Hello everyone and welcome to this week's Stellar Developer Meeting. Today I have quite a few guests joining the call from NMIX. So please introduce yourself. Good morning everyone. My name is Chaved. The CEO and co-founder of Onomics where we are building financial institution infrastructure on chain on Stellar. We use the diamond proxy standard, which we will be talking to you about very shortly. And our entire objective is to allow a seamless transition of for asset managers to seamlessly transition onchain without ever realizing, that it's actually blockchain, that's running the show in the background. I pass over to Thomas and Sebastian. Yeah, my name is Thomas Brown. I'm here

[01:00] at Nomix. Been working on Sora, a project, that caught my eye as a native Rust developer. I've been doing it. Now for about 10 years, that is to say Rust. And. So far my experience working Stellar has been incredible. I had experience working on other blockchains and being a Rust developer and being familiar with the benefits the language I feel like Stellar's system makes it really intuitive for a seasoned developer and even those with lesser experience to just jump on board. So this has been a really fun and interesting experience for me. So far. Hi everybody. My name is Sebastian Shepus. I'm the CTO here at Nomix and I'm excited to be here. We've been working on this technology for a. While and we Thomas is one of the best

[02:00] Rust developers we know and we've had a really good time building this infrastructure. So we hope, that you enjoy what you see and find it useful. Excellent. Mason, you want to introduce yourself? Let me just wish my comments. Hello everyone. Good morning, good evening, good afternoon from wherever you're joining. I'm M Heather. I'm the head of engineering at Nomix. It's been quite a journey at Nomix, and now we see Nomix also working with solar pan and seller and my part here is to integrate, that into our overall auto deployer solution where we onboard customers within a 20 to 30 minute time frame and

[03:00] deploy them onto their target chain and we're quickly on wrapping them onboarding them onto chains as well. Great. Thank you for the introductions. Yeah, I really love tooling and yeah, what can make your work as a developer and deploying your smart contracts easier. That's something, that's really interesting to me. I have not had a chance to play around with your solution. So I'm super excited to see your presentation and your demo. Sounds great. So to start off I believe we would like to share a little bit about the motivation for why we were developing the Soraban version of the diamond proxy standard. So like I mentioned earlier our mission at Nomix is to allow traditional asset managers and traditional finance projects to transition onchain in a manner, which completely abstracts away the complexity

[04:00] of blockchain technology where they don't even realize, that it's blockchain running the show in the background. We don't say the B word, There's no blockchain, no crypto. It just happens to run on blockchain based infrastructure. So one of the key challenges, that we saw. When we were going out there and refining our product market fit was convincing these asset managers to transition onchain. Because everyone has their preconceived biases about blockchain technology, which is hey it's immutable and once something is deployed on chain, that can never ever be changed ever again, which is great. When you're operating in the DeFi land where you know you've got pictures of monkeys on NFDS or I don't know you, you don't know me, and you're issuing a random token, that I want to audit the code for to make sure I'm not going to get my token stolen or you're not going to dilute me just by issuing new tokens. But, that immutability is a double-edged sword. That immutability turns into a massive

[05:00] liability for financial institutions, that expect to update these smart contracts at a regular cadence. When either a zero day bug is discovered or whether regulations change. As you all know, we're in the very nent stages of tokenization as a industry, as a market segment. Maybe only three to five years tops. And. Because of this immutability, these asset managers were very hesitant to adopt. Because when you do smart contract upgrades in the traditional sense, which is you're deprecating the old contract and transitioning everyone to a new contract, it's a massive pain for the asset issuer. It's a huge poor user experience for the end user as well. So what we're deploying out there into the world looks, feels, and smells like a traditional brokerage account, that's built on these diamond proxy standard. One of the key reasons, that all of the tokenization initiatives

[06:00] to date, apart from a few very diff very few exceptions, have happened behind walled gardens is. Because of this feature. Because they want to carefully control the entire blockchain, that they're operating on. So. If they need to roll something back or. If they need to upgrade things, they have the complete cart launch to do so. But we all know, that there's inherent liquidity on public ledgers. And. If you want to democratize access to various financial instruments and increase your investor base, you need to be able to tackle these public blockchains. This entire concept, this entire challenge is why we decided to build the diamond proxy standard on Sora. I'll pause here very quickly for any comments from you, Carson. Yeah, I just want to say, that. If anyone watching here has any questions, please feel free to post them in the chat and we will try to take them as they come in. But. But

[07:00] yeah, I think, that was a, great intro. Maybe maybe just very briefly describe what the diamond pattern what, that is for those who are less familiar with it. Of course. So the diamond proxy standard is functions similarly to how proxies work in the traditional web 2.0 world. If you're familiar with them. So instead of having a monolithic smart contract structure, you actually have something called the diamond smart contract, which basically. If you think about it all typically all of the smart contracts have their independent stoages and they're all hardcoded to each other to work with each other. If you've got a marketplace smart contract. If you've got a fee distribution smart contract, all of them are kind of linked together in a hard-coded manner, for the lack of a better word. What the diamond proxy allows you to do is have a common storage for all of these smart

[08:00] contracts. And there's multiple facets on, that smart contract. And each one of these facets are responsible for a specific kind of functionality. Now, at a 10,000 feet overview, and Thomas can get into, that a little bit deeper, at a 10,000 feet overview. When you need to change anything at all in a diamond proxy, you're simply able to shave away a facet and replace it with a newer facet without impacting the rest of the functionality of the contract or without having to do costly reissuances and migrations of those tokens. Great. Okay. So, I'll pause for any highle questions. And then I'll let Thomas take it away and get down into the nitty-gritty. Sounds good. Here's there was one question from the audience asking for a link to the standard. Now, did you want it in just like a GitHub repo link of our SCP

[09:00] filing. Because that's what we're going to go over next. Yeah, I can post, that one. Yeah. Okay, there we go. Yeah, there you go. So, yeah, we are proposing a set. We filed this up a couple of months ago, and now we're ready to drive additional eyeballs on it from the community and have it start to be adopted throughout the Soroban community as well. We'll also be going through Sor OpenZeppelin audits of the smart contract in very short order over the next month or two. So, yeah, Thomas, take it away. If you want to share your screen. Screen. Great. And just get this set up.

[10:00] All right, the diamond proxy standard. So before I get into discussing the jargon, that's used here. Because somebody looking at this for the first time will be inundated with all these new keywords. I think as a developer speaking to other developers, it makes the most sense to approach this from a common perspective. typically. When we're developing a smart contract, we can think of a smart contract as like a class of sorts. It's something, that runs and it's structured. You can add functions to it. You can add data fields to it. You can control how those data fields are accessed through different view modifiers. Modifiers. And in web 3.0 or in blockchain space instead of having a class just running

[11:00] on your local machine, which is the case for normal object-oriented programming. When you're talking about paradigms like Stellar or Ethereum anything like, that we have a distributed class so, that class file, that code is being executed across many machines at once. And so there's a beauty and elegance to the notion of smart contracts. Now, in order to achieve, that, you have to have consensus and there has to be pin to the location of where, that smart contract exists. And, that's, that's one of the reasons why we have to have the diamond proxy. Because it's great. You can go ahead deploy smart contract. But we quickly run into

[12:00] the problem in the web 3 space where say you have some business logic and you deploy it. A month down the road manager approaches you and says, "Hey, I would like this functionality changed." Well, in order to do, that, you're going to have to a redeploy and b change the pointer of the smart contract on chain and tell anybody who's using your system, okay, don't target this contract address anymore. Target this one. And. So you could have, let's say, some kind of layer, that automatically reroutes all, that for you. And people were doing, that for some time. But what. If there was a way to proxy and reroute calls on the blockchain itself? So how can we

[13:00] go from something, that is intrinsically immutable to something, that is actually mutable? And. So it seems like a little bit like magic. But it really isn't. And therein lies the beauty of the diamond proxy is, that it is simple yet seems like magic. With the diamond proxy, what you have is you have several stable points in me in the decentralized memory. Those stable points are your proxy and your shared storage layer. As far as a user is concerned, their interactions are going to target the diamond proxy. So let's assume a very simple case. I want to deploy a smart contract. What I do is I make sure the diamond proxy is deployed

[14:00] and. Then I deploy the smart contract not directly. But through a proxy. So the diamond proxy through a function called diamond cut deploys the smart contract, which we call facet and initializes it. When it initializes the facet. In Stellar, we have a macro within our source code, that allows you to seamlessly integrate with this diamond proxy standard on Stellar such, that it injects another stable point in memory, the contract address for the shared storage layer. So whenever a facet is deployed through the proxy, it gets a pointer to, that shared storage.

[15:00] What does this mean? This means, that let's say you deploy a facet. And then you update the logic again. Because you have a shared storage layer, it doesn't matter, that you have two separate smart contracts. Now facet A and facet B can still access the data, that you had mutated within the ledger. That, that's, that's just great. We really want to give people the opportunity to have the freedom to change data without having to go through the hassle of having to deal with the issues, that exist with the immutability. And in reality, this sort of functionality is really what you want anyways. Because as any developer knows, you're never actually truly done with a

[16:00] program. You can get 95% the way there or 99. But there's always part of you, that feels like you can always improve it somehow. You can always do something else. And indeed in the world of business. When you have business logic and changing business requirements, you can't have, that immutability. When you're talking about the business logic. You have to have breathing room for it to be able to change. And. So the diamond proxy standard gives us the ability to go from a complex immutable setup to a very straightforward approach to maintaining code bases, that can be arbitrarily complex. So. So let us consider a facet. We have facet here and we want to be able to execute a function.

[17:00] function. Typically you would just you know using Sorabon you would invoke a function directly on this smart contract, which in this case we're calling facet A. But. When you're using the diamond proxy standard you don't call the function here directly. Instead what you do is you call the function through the diamond proxy and, that function, which within the framework of this the jargon we use is selector function equals selector for all intents and purposes. So you may hear, that interchangeably. When studying the diamond proxy pattern. You run the function through here and the proxy internally looks at a set of selectors and those selectors are associated with a contract address. Address. And. Because it knows where, that contract

[18:00] exists, it. Then proxies the call to the associated facet, whether, that be facet A or facet B. Let's say facet A has two functions alpha and beta. And then you want to update function alpha. What you could do is instead of redeploying a version of facet A, that just has alpha changed, you could just have a very targeted approach and deploy facet B. And facet B is much leaner. Because it has just function alpha. So the gas costs associated with deployment are going to be cheaper. And. When you call this, it's going to get the most recent version in the storage of these selectors. So

[19:00] before. When you're calling function alpha, alpha, it's hitting facet A. But once you upgrade, you call function alpha, it's going to be routed to facet B. Now what about function beta? Well, function beta doesn't exist here. We deployed only function alpha within here. Function beta still exists here. So the diamond proxy will continue to route it. And. So as you could see there is a lot of room for flexibility here. Now. If the developer wants to they could still deploy a version of facet A, that has alpha and beta functions and beta doesn't change. But alpha does. And, that just means, that. When we call the function to the diamond proxy, it's almost as. If facet just doesn't exist. It's functions are not being called. But

[20:00] that's not to say, that. If any calls you made to facet A in any way mutated the information, that you can't access, that mutated information anymore from facet B. No, you actually still can access, that mutated information. So you can imagine a scenario where as time goes on you get more and more facets over here to the right and you could have a very complex program. If you wanted to. And going back to the analogy of object-oriented programming in a class, you could even from like a non-upgrading perspective, you could just deploy different facets like different modules of or name spaces within your application to have a strict separation of concerns. So, not only does this allow you to have

[21:00] that upgradability, it also allows you to have, that clear differentiation between different pieces of logic, that represents your program. So, from a bird's eye view, this helps consolidate your software's architecture. And not only does it do, that, as we just discussed, it helps you upgrade something, that would otherwise be challenging to upgrade. There's a second part to this, that ought to be discussed and, that is the diamond factory. Now the diamond facto's job is just to create a diamond proxy. So. So why would we do, that? Why not just deploy a diamond proxy directly? Well, you could. But there's a little bit of a setup phase just like how there's a

[22:00] setup phase with facets. With facets, you have an init function, which receives a pointer to the shared storage. And similar here with the factory. When it deploys a diamond proxy, it ensures, that the diamond proxy has everything it needs to initialize itself. And. So internally, it's going to set up, that stable pointer to the shared storage smart contract. And, that there abstracts away any setup you really have to do. So as a user, you're going to use the diamond proxy. But you're going to first start off with the factory. You use the factory, deploy the diamond proxy. And then once you're at, that layer, you could just go ahead and treat this as normal. You don't have to touch the factory ever again. If you wanted to. Or

[23:00] you could use the factory to create another diamond proxy and, that diamond proxy in turn will have its own shared storage address. And so on. And so forth. You can use the factory over and over again. As it relates to Sora, there is another feature of this SEP filing and, that's the storage helper. So typically. When we're developing in Sora, we have access to three different types of storage. We have the instant storage, and finally we have the temporary storage. And. So you would do something like storage instance.get or something like, that. And the same thing for temporary.

[24:00] Well, I wanted in this to have a very similar paradigm. So. If you wanted to go from instance storage to shared instance storage, you would do storage.shared instance or storage shared temporary. And so on. So it creates a very familiar pattern for the developer. There's only a slight difference and, that's, that whatever you're putting in whether it be a key or a value. Because it has to exist within the storage of a diamond proxy to know where the selectors are and where all the metadata is. Is. It has to be serialized to XDR format, which as storebound developers know is the encoding format we use for

[25:00] networking transmission. There's another component to the diamond proxy and this is more of a meta feature and, that's the loop facet. Now in EVM land they call it a loop facet. It's like a smart contract. But here it's different. We have it leveraging Sora's inherent capabilities and we have it sitting with the diamond proxy contract itself. So. If you want to know the address for selector alpha, it will return to you the address of facet A or. If you get upgraded. Then it would return you the address of facet B. And. So the loop storage allows us to

[26:00] just introspect upon the diamond and it also stores the state of the diamond itself. Itself. Whenever whenever one performs diamond cut, which as we recall allows us to deploy a facet or smart contract, that will get recorded within the loop storage. Storage. Now, did anyone have any questions? Yeah, there were some questions. If we go back a little bit, let me see. I think there was a question about. When data is being stored.

[27:00] Oh yeah, say silence asked it sounded like storage isn't written to until ledger closes in this setup. If that makes sense. Correct. Yeah. Yeah. Let's see what else. Yeah, I think, that was what I think Matias had a question too. I think we can continue. Okay. Yeah. Uber, I don't know. If you

[28:00] wanted anything to add to this. But. If not. Then I'll just move on to deployment flows. Yeah, let's just No, no, that, that was great. Thank you, Thomas. Thomas. Okay. All right. So, we've already discussed this a bit. But just to visualize what's going on, you start off, you're the user, you want to ensure, that you have your diamond factory. Factory. Oh, sorry to interrupt you. But Silence had a question. that said, that you would access storage as storage shared. Yeah, you would I look want to see Oh, here we go.

[29:00] So we have a pattern here, that's pretty much just like before. So you do env shared storage.persistent and I believe I worded it incorrectly earlier. But the idea is, that you have just a drop in replacement. So instead of env storage, which is what we typically do we do env.shared storage. And then you call persistent or instance or temporary on, that handle. Okay. Yep. And other important thing to consider is, that. When you have access to, that persistent shared storage handle, you need to make sure, that whatever you're putting in has to be serializable to XDR. Yeah. And. Then Silus also mentioned, that

[30:00] that this would require the end shared storage would require a CAP. CAP. So. So but this is a CAP proposal as well, right? So so. If required we could make one and we've been told. So far, that what we have here is a starting point, that shared storage layer yes we're going to need to have it ingrained within the ecosystem and an incrementalist approach does make the most sense. But yes it will require changes to multiple parts of Sorabon. Okay great. Yeah. So you have diamond factory and the factory just creates diamond proxies. The user calls deploy diamond.

[31:00] The factory deploys diamond proxy. And then the proxy goes ahead and it deploys the shared storage layer. So. Now you have a diamond with no facets. Facets. Now you want to add a facet. You want to start adding architecture to your software. So you go ahead, you call diamond cut. Diamond cut will deploy the facet. And then it will call the init function on, that facet. And keep in mind this init function, it's a macro within Rust. So you just add it right on top of the contract imple macro and it will inject the init function for you. That way. When diamond cut is called, it's passing a pointer to

[32:00] this shared storage layer. The next step is after the facets's initialized, we update the selector or function mapping. That way, whenever somebody attempts to invoke a function, as we see here next, it will perform a lookup within, that selector mapping. So, we invoke the contract. After we call the function through the proxy, we might set some storage or get some storage update or delete. And then we return the result and the result has to be XDR encoded and, that's is the additional requirement, which is typical anyways. So you're just adding an additional layer and, that's why again it's

[33:00] considered a proxy. Are there any questions about this deployment process and the life cycle of working with diamonds? So. So I think Neil Nish had a question earlier about how would you design an upgradeable contract. While managing storage efficiently. So, Milage I think we address, that later on down in the presentation, right Thomas? Yeah, we do. Yeah. And apart from, that, how would you design? Usually you have to migrate the storage. Similar concern to traditional web two development. Yes. So again, the same question came up again, that you know how would you handle storage? Excellent question guys and the entire intent of the diamond proxy standard is, that you don't have to manage smart contract storage migration. Yeah. That's, that was also my takeaway.

[34:00] Great. All right. So I go down and I'm just going to compare what we have here, the diamond proxy, to what already exists in Sorabon. And in general, there are pros and what one chooses depends on what one has as requirements, any preferences. So I'll start off with the first one, which I think we've already discussed, which is the notion of granularity the ability for us to be able to define in very compartmentalized terms or even very uncompartmentalized terms the design of our software In

[35:00] In Sorabon. If you want to update the smart contract, what you have to do is you have to call a function and, that replaces the entire smart contract. and for some people, that's all, that's needed. But. If you have more complex requirements, you don't want to deal with the headaches of let's say migration, which is the next comparison here. Then you're definitely going to want to use the diamond proxy pattern. And as discussed, we have, that shared storage layer means, that doesn't matter how many times you upgrade your facets, it's going to always have a pointer to, that shared storage layer. And with Soraon, you replace a contract, you're going to have to manually manage

[36:00] how you access, that data and where, that data is going to exist. Those are things you have to consider. But with the diamond proxy pattern, in Stellar terms, you don't have to worry about, that. You can just act like the database is always there. It's abstracted away. The code size limits. Now this typically in my opinion the benefits to the diamond proxy here in terms of code size limits is, that you can have a very small set of code and you could just do incremental changes. So you deploy a facet. And then you deploy another facet and you keep things exactly as needed. You could do a monolith. A monolith is completely acceptable. The diamond proxy

[37:00] can certainly handle, that. In Sorabon you're limited by the maximum size of the contract code, which is fairly large. But with the diamond proxy pattern let's say the limit on Soroban is n well. Then then your program let's say is 2n what you do is you have several facets. Then the first facet is of length n in size and bite code. And then the second facet is also in size of length and of bite code and you have different functions for both and. When you call the diamond proxy it's going to proxy it to the right smart contract address. So you completely get over, that hurdle of the code size. And by proxy you have, that same

[38:00] principle applying to the method count. Now the number is still pretty high for both. But nonetheless just imagine typical code base, that may have nowadays thousands and thousands of functions. Functions. The diamond and proxy pattern you can go ahead and you could accommodate for such and you can have very large programs. theoretically. If you wanted to, you could have a diamond proxy pointing to hundreds. If not thousands of facets, that in total are gigabytes in size. it'd be very interesting in terms of a case study to see somebody go forward with, that. And really, the sky's is the limit there. And I think people will do some very creative things with this. We've only really just touched the surface here. And with the performance and security and stability

[39:00] that Rust provides, I really think, that in contrast to EVM, we're going to have not only Rust developers in my opinion are just more seasons, seasons. But they pay close attention to the fine details. They're very good at what they do and, that's reflected by seeing how elegant Stellar is and the Diamond Proxy is complimentary to all of, that. It's a simple and elegant solution, which opens up the sky for everybody and Stellar it's in its name. I think Stellar is meant to be married with the diamond proxy. Because in a way it's what allows access to those higher realms. So to speak. The other comparison between the two is modularity and we've already talked

[40:00] about this. You can design your software. You could have different categories of your business logic in different facets. And you can visualize it as you have facet A. And then you have facet A1, which is an upgrade to facet A. And then in parallel you have facet B, facet B1. And so on. And so forth. So you could independently upgrade these parts and still separate the business logic. So it's clear you have the ability to through loop functionality to introspect upon these functions and the addresses. There's no notion of, that directly. With a smart contract you can of course get the AI

[41:00] that's different, though with introspection this is live through actual transaction calls and keep in mind every time you call diamonds cut, which is deploying the facet again the diamond proxy is recording, that in storage. So introspection will just give you, that information, that it's recording. Okay. So it sounds like everything's good and all with Diamond Proxy. But as I mentioned from the very beginning, there are indeed pros and cons. One of the cons is, that. When you're setting up the diamond proxy, you're also going to set up the diamond factory. And the diamond proxy is going to have to set up shared storage. So, this is really just a one-time thing. So, you have a constant initial cost. And then you also have costs associated

[42:00] with deploying a facet. And. If on Sorabon you want to deploy a smart contract, it is direct. But here it is indirect. Because we have to call diamond cut. Diamond cut has to ensure, that the bite code exists on the blockchain. And then it has to run the functions to initialize it and, that also includes passing in, that shared storage address. So. Because of, that yes there is not only a constant initial cost. But there is a constant cost associated as overhead with each call to diamond cut. So on Sorabon you don't really have, that issue. It's just a onetoone deployment.

[43:00] It's not a one to two or three smart contracts being deployed. It's just one to one. And to be clear, that one to multiple deployments only occurs in the very beginning. When you set up the factory and you set up the shared storage. But once you have, that set up, you don't have to reinitialize the shared storage. You just pass a pointer to it. So really, you're just deploying the facet smart contract in the direct proxy. But. But one of the key benefits of doing it using the diamond factory is, that let's say you're spinning up something like a let's take the example of a DEX pool right. When you know, that you have to have the same contract replicated multiple times. If you're using the diamond factory, that will reduce your overall cost in the long run. Because instead of having to deploy the entire contract from scratch, you're actually calling the diamond factory, which the

[44:00] bite code already exists on chain to deploy those contracts. Thomas, correct me. If I'm wrong there. Good. Yeah. want me to continue? You want there? Yeah. No, no. did I not you guys not hear me? Oh, yeah, we heard you. Okay, cool. Yeah, no, go ahead. We just discussed, that there is a bit of complexity and yeah, that does entail, that the transaction costs are going to be higher, and the costs are going to be lower on Sorabon each time. This point the development experience this really varies in my opinion there will be an initial higher overhead

[45:00] simply. Because you're going to see all this jargon. What's a facet? What is loop introspection? What is diamond factory? What's the diamond proxy? What is all of this? And at first it might seem like a fire hose, that it's really overwhelming. But. If I draw our attention back up here, it's actually really simple. And once one goes through the process of using this and seeing it in action in code, it becomes something, that is just intuitive and simple. So there is, that initial hurdle and, that is why in the very beginning of this presentation I discussed let's set aside the jargon and let's talk about this in terms, that we're all familiar with the notion, that we have a class in object-oriented programming and we want to be able to mutate it. How can we do, that in web 3 space? So I think

[46:00] going with, that approach. When teaching this to others is you guys will eventually do you guys continue to learn more about this and actually apply it. I think just sticking to a simple analogy is the best approach. Less is more certainly here. It should not be something, that one overthinks. I know I certainly did. When I first looked at this. But the end of the day it's fairly straightforward. And in terms of state sharing again we already discussed this. So I think I will omit, that one. Are there any questions about the paradigm of the diamond proxy being brought onto Stellar or any logistical questions? Anything we'd be happy to answer.

[47:00] Yeah. Matias had some questions about large systems built on this, that how do you handle DevOps and monitoring etc. Etc. And yeah he says I'm guessing you would also offer at least a tool to handle the orchestration. Orchestration. So in terms of DevOps. If you want to be able to understand what's happening to let's say you have a very complex program and smart contracts may be dynamically deployed based on criteria, you need to be able to monitor, that. And so, that is an excellent question and, that is one of the reasons why we have the diamond loop allows us to introspect. But there's another part to this SCP filing and, that's, that. When you perform a diamond

[48:00] cut events are emitted and with those emitted events we have built in Rust a Stellar indexer, that captures these events. Events. And. So you're wanting to do DevOps, you're wanting to make sure okay everything is good. There aren't issues and. If there are issues we want to see them right away. You have an indexer run. You pass the index or the contract address of the diamond, which as we know is a stable address. It's not going to change. Change. And your indexer will. Then listen to events and you will have some application then, that listens to specific types of those events and. If certain criteria are met, you can send an alert to pager whatever software you decide to use.

[49:00] So really it's through indexing and listening and diamond loop functionality as well as listening to just those emitted events, that we open the door. As for do we provide like an actual toolkit, that allows one to monitor their diamond? We don't have like an actual program to do, that. We have some components, that allow one to build towards, that. And I think, that as a community working towards, that would be a very important next step. Because then at, that point we open the door to organizations very large ones in fact, that they want to build out complex software. They don't have to worry about the immutability of blockchain as we discussed. They just hop on board. And then they already have this open-source toolkit, that does all this monitoring

[50:00] for them. We it's certainly something, that can be done. There are no limitations there. Good question. Yeah, there's another question. If you have a demo app, that's built on Stellar, that are using this. Yeah, we do. Okay. Yep. Before we jump into the demo app, Thomas, maybe it would also be good to show them the diamond looper, that we built for seller to introspect this. And then jump into the app. Oh, for this presentation as we discussed, we would just go straight into the, other app. But we do have a link to repository to show, that, and it is getting short on time anyways. So we will go straight into the app. No worries. Sounds good. Okay,

[51:00] Thomas question by silence there to say, that. If you made an app there must be a contract to handle shared storage layer correct. Because he's feels like he's having a fundamental misunderstanding. So you don't even have to worry about the shared storage layer, that's abstracted away. It's, that. If you want to access storage in Sorabon, you're not calling env.persistent. Let's say you're doing env.shared storage.persistent. Storage.persistent. That's the new pattern. So, it's very similar. yeah. Any other questions?

[52:00] Okay, that sounds silence. Once you review it, I think it'll make itself clear once you actually have a peek at the SCP. But go on, Thomas. Yeah. So, as we're developers, I'm just going to draw our attention to what this application looks like from a more programmatic view. View. We have the diamond factory, that we talked about. This is what we use to actually deploy. And we have all these facets, that we've deployed. And these are going to be used in a way, that allows us to keep track of KYC. So in this application, we have a set of compliance rules. So we have some say base requirements, that a person

[53:00] identity must pass. They have extended KYC requirements. And then somebody could come along and say, "Well, hold on. I was just told by some regulatory agency, that we need rule 54b or something." So, we go ahead, we add, that in. We have. Now the set of constraints, that one must pass in order to pass KYC verification. Verification. You have, that on the ledger. Right. Now I'm pointing at says Stellar test net. But really it's pointing to a local quick start docker image for development purposes. You have trusted issuers. In this case, we just have the company

[54:00] name and the trusted issuer has an address and they have defined a set of compliance rules. And. If you look here, we have these rules and say want to add rule 54b, we can go ahead and do, that. And we update the trusted issuers's information. And. Now the trusted issuer manages these compliance rules. We have identities. These are individuals. In this case, several of us on the call, Uber and Sebastian are identities here. And. If somebody wants to go through the KYC process, they would come here and they would add in information, that allows us to

[55:00] keep track of what's going on. So, organization admin, this is called the admin portal after all, allows one to keep track of this in a way, that increases public trust. As far as how this relates to the diamond proxy, well, you can just imagine a case where we want to change the data structure. Let's say we want additional columns here in the data. If we just had an immutable smart contract, we couldn't actually just change it. What we would have to do is several things. We would have to create a new smart contract, redeploy it, take all the old data from the first smart contract and copy it over and, that's not fun. But with this approach, you can go ahead and you can upgrade it and it's still going to point to the same information.

[56:00] the only sense of migration really is just you keeping track of okay am I changing the shape of the data internally in any way and then, that comes down to the burden as always is placed on the developer to consider carefully their data structures inform the architecture of the overall program. So right So. So just wanted to address some questions, that came up. there was a question by Green here about us validating the demand with Stellar developers. U, no, we didn't, we the target audience for this wasn't initially the Stellar developers. We once we actually showcased this to the internal foundation team, they were excited about it. They wanted us to showcase it to the development community to be used in other Art of Leo tokenization frameworks where we did see a significant demand for it come from was from asset managers

[57:00] themselves people, that were actually. If you're asking someone to do RWA tokenization and you're asking them to transition millions. If not billions of their assets on chain this is something, that they felt comfortable getting behind and secondly with respect to Nomics ID what Thomas just showcased to you is a digital identity framework. We'll also be filing an SCP for, that. And creating a standard for anomics ID on the Sora network. What the Nomix ID would allow you to do is create digital identities on chain, that you can. Then enforce these compliance rules on a token. Just cut off. Oh, hello. Can you hear me? Oh, yeah. Uber we can't hear you. I can hear you. Oh, okay. U Yeah. So. So what it would allow you to do is create these digital identities, collect the appropriate documentation, that you need against each one of these

[58:00] compliance rules, that's being set against a particular identity, and then. If you actually we're running short on time here. But I'm happy to showcase this demo at a later stage. When you actually go to create or issue tokens, that are part of this diamond proxy standard, that also include the identity storage as well as the token storage itself. You're actually able to superimpose individual tokens with prerequisite compliance rules. So it gives DeFi a somewhat centralized flavor, which is mandated by regulators in order to facilitate the transition of RWA onchain. Right. So, so. So to answer your question in a roundabout way, I am green. The entire intent was. If we want asset managers, that have not interacted with blockchain technology, that are have no clue about the underlying tech. But they want to get on board with the tokenization bandwagon and they want to come into RWAS. Telling

[59:00] them, that their contracts are actually upgradable in a very modular manner gives them peace of mind. While still preserving the audit trail, that already occurred on the previous transactions in the previous iteration of, that contract. Great. Yeah, I think it makes a lot of sense. U this may not be a good fit for all projects. But I think you had some good use cases where this makes a lot of sense to build it this way. Right. No, it would all be article ways. Because otherwise you are adding unnecessary complexity unless you're creating a DeFi protocol, that you is more experimental and you're expecting to update it on a regular cadence, maybe, that would be a good fit. But. If it's just a oneanddone deployment project, yeah, you're better off just doing it the old way. But. If you are doing RWAS and. If you are trying to win clients in the RWA space, giving those clients this peace of mind. Because legislation always

[01:00:00] trails innovation. There's going to be more legislative rules and policies, that are going to come in place, that these smart contracts will eventually have to comply with. Yeah. Great. I don't know. If there's any last minute questions before we end here. Here. Yeah. Now you get it. My apologies. We should have started with, that shared. The entire purpose of the shared storage is. Because if you upgraded a contract and you tell me all of my historical transaction data is gone, the SEC is going to be banging on their doors and it's gi well played. Game over. They will never adopt. This is a way to soften the blow for asset managers to bring them on check. Yes. By a whole lot. Yeah. Because before, that they didn't even want to talk to you. You. Neil, you say you have a question. What is your question? Is it related to the topic here?

[01:01:00] , yeah, I don't think we have any more questions. Well, oh yeah, learn American language. Okay, Okay, it's more of a statement than a question. Question. Yeah, I agree 100%. Learn Soroban. Yeah, great. Thank you. So much for joining today. This was super interesting. I'm looking forward to see the progress and see how this will play out. I think it's it there's definitely some use cases where I see this has massive benefits. So yeah, super exciting. Thank you all for joining and thank you for everyone who viewed this live stream. We'll be back again next Thursday. Thank you. Bye. Bye. Thanks, guys. And look out for comments from both Wald and Silence. Thank you

[01:02:00] guys. Guys. Thank you. Have a good one, guys. See you. Take care. Bye.