Submind YouTube summaries
Thumbnail for Open Tokenized Asset Standard (OTAS) Community Call - 2026/08/25

Open Tokenized Asset Standard (OTAS) Community Call - 2026/08/25

Watch on YouTube

Video summary

The August 25th, 2026 community call for the Open Tokenized Asset Standard (OTAS) focused on advancing a protocol-agnostic layer designed to streamline the tokenization of real-world assets across different jurisdictions and blockchain networks. The primary objective discussed was to create a standard that allows bonds or tokens created on one chain to be utilized, exchanged, or managed on another without duplicating compliance processes, thereby improving capital efficiency. The meeting highlighted the development of a white paper that defines four key layers: settlement network, identity, compliance, and asset metadata. Participants emphasized the need to incorporate specific technical nuances into this document, particularly regarding how different chains handle finality and the integration of existing standards like ERC-3643 for Ethereum or permissioned models for other networks. A significant portion of the discussion centered on practical implementation challenges, including privacy, confidentiality, and the management of private transactions between entities. Contributors presented a tool called "Otro," a read-only conformance probe that maps deployed chain data to the OTAS model, though it currently lacks complete adapter support for all chains. The group debated mechanisms for handling private assets, with suggestions ranging from zero-knowledge proofs to hash-based verification, weighing the trade-offs between infrastructure complexity, cost, and scalability. Additionally, there was a lively conversation about the appropriate communication channels for an institutional working group; while some participants expressed concerns about using Discord due to corporate network restrictions, the Linux Foundation team clarified their multi-channel approach involving GitHub for formal work, mailing lists for updates, and Discord for immediate community interaction. The meeting concluded with actionable steps regarding the evolution of the white paper itself as the project moves toward version 0.2. The team agreed on a branching strategy similar to Ethereum's model, where a main branch will be maintained while changes are merged periodically from working branches to ensure historical records are preserved without creating redundant versions. Participants also identified gaps in the current documentation regarding the identity layer and verifiable credentials, assigning specific tasks to members like Harris to address these areas through GitHub issues. The consensus was reached that as the community grows, more concrete discussion points should be generated and posted on the project's discussion board to shape the final standard, ensuring it remains robust enough for adoption by major financial institutions while remaining accessible to the broader developer ecosystem.
Read the full video transcript
All right, welcome everybody to the August 25th, 2026 open tokenized asset standard community call. As with all Linux Foundation events, this is held in a Linux Foundation antitrust policy. If you have any questions about these matters, please contact your company council or if you're a member of the Linux Foundation, feel free to contact Andrew Upgra of the firm Guestmer Upgra LLP, which provides legal counsel to the Linux Foundation. In addition, this is held in a Linux Foundation code of conduct, which can best be summed up as be excellent to each other. We're going to get a ton of work done. Uh, with that, our next meeting, and I'm just going to do this real quick announcement to start. Our next meeting is scheduled for Tuesday, September 22nd, 8 a.m. PT, 11:00 a.m. ET, 5:00 p.m. C. And I'm going to turn it over to Sarvesh and Mul. You guys are up. >> Perfect. I'd let Mul start, but just wanted to kind of give a quick um thank you for first of all heads up for everyone. Thank you so much for joining. Really appreciate it. Um there is there are a few good things that have happened in the past. We've had a few good calls with the Me team, Me Lab. So um they are also very much involved. we had a good um you know we give him a good understanding of what ODAS is. So I think Harris is here as well. >> Yeah. >> Hello everyone. >> Awesome. >> He's from the uh Miston lab and um has worked closely with the Sui blockchain itself. So he's you know he's one of the people we work very closely with um for our other projects as well. So welcome Harris. Um that said here. Yeah. >> Oh Maria's here as well. Hi Maria. how you doing? >> Um, great. So, uh, Mul, I'll let you take over and and go over these questions that we had. I know when we had a call the last time with the Miston lab team, they had a few questions which they felt was very important which I also felt was very important for our um overall uh white paper that we have. uh maybe it's it's good to have those as questions or discussion points within our white paper so that we can either incorporate them or at least tweak the paper accordingly so that you know those changes are available. Yeah. >> Right. Sure. Uh so actually I yeah before I start actually I prepared this as a uh presentation where we show the DVP flow of entire OTAAS but >> uh since lot of people are here I think uh and I assumed it would take a lot of time since a lot of people are here and should we introduce Otas again or how how do we start this uh and uh and I I think we should take the questions first because it might take some time later. So uh I think questions are important. So we should ideally spend some time before on questions. Uh if uh if we could do that. Yeah. >> Sure. So before that I I just want to kind of you know quickly ask if people have actually gone through our white paper and what do you you know is is there anything that you feel is missing or do you feel that you know we have it's very generic and we need to add more meat to it. Right. >> It's an open question. And uh Makul and Svesh, you've got control. So if you want to share your screen, go right ahead. I stopped sharing because it sounded like we were going to get into a presentation. >> Uh I'm sharing my screen. Yeah. >> Yeah. Go ahead. >> Yep. Yes. Can you see my screen shish? >> Yes, I can. >> Okay. Okay. Got it. Uh so one of our contributors basically uh shared probe with us in one of our discussion uh about privacy and confidentiality. So uh we wanted to decide what direction we are heading right I mean uh in terms of implementation side as we are writing the white paper. I thought this I spent some time with OTAAS probe and I think it was a uh it is a good attempt. Basically it it is a readonly implementation. It checks whether uh token of different chain follow the standard the standard which we are defining. So I initially so it has adapter for EVM and it has some uh implementation for Solana and SUI but it's not complete. So I initially started to make that part but later I basically tried to visualize everything uh simulated uh the entire DVP cycle for two chains right now EVM and SUI between EVM and SUI. So uh well that's what I assume we would take some more time on but since we have a lot of people so we could either if you have if if people don't know what is maybe we can start with a broader introduction or maybe if you as mentioned you guys have some questions or ideas maybe we should spend some time on that before uh because then uh the later part might take some time so and if you have any questions about or any suggestions Uh please feel free to point out uh s my audio is right correct right? >> Yeah yeah yeah I can I can hear you. I think everybody else can hear you too. >> Okay. >> I'm hoping. >> Yeah. >> Awesome. I know Michael uh sent a a message. Michael, can you just elaborate what exactly is that a question or are we trying to kind of get to the discussion point as such? >> Oh, no. I was just linking it in the chat. It's great to see everybody again. Yeah. >> Awesome. Awesome. Thank you. >> Uh yes, Michael. Link the thread correct. >> Ah, okay. >> Mhm. >> Uh right. >> Okay. So I think let's just give a quick update on on OTAAS itself uh you know the white paper and then uh you know Yeah. >> Sure. Uh you can see my uh my tab right current tab. >> Yes. >> Okay. Uh so open tokenized asset standard OTAS we are trying to make a white paper make a protocol agnostic layer where uh you can basically check whether uh essentially we have these four layers uh settlement network identity compliance and asset metadata where uh our primary goal is as a tokenization is being uh used in different industries uh uh and tokenized and basically tokenized assets are being used as a stock assets for different uh for for real world assets for properties and so on. So to make a standard for uh different uh jurisdictions if different regions uh different uh protocols different companies can follow where they don't have to uh where a bond which is being uh created on one chain can also be uh utilized or exchange or uh managed another chain without having to uh without it having to uh being created again and duplicate the entire compliance process entire uh token itself. itself uh so to uh improve the capital efficiency through this. So that's uh the primary goal uh and I'd recommend to go over the white paper if you already haven't. It's not that uh big. Also uh Sish I haven't mentioned I spoke with Ivan uh after our last call. Uh we exchanged couple of emails. Uh his time zone is he's from Australia, right? So this is really late for him. So uh we are planning to schedule a short call this week later uh to discuss. He had some pointers on finality uh as uh uh so is Amit in the call? >> We yeah we explained some uh chat in our channel open asset channel about the finality part. Uh so he also uh uh so basic basically Ivan also had some point on technical finality itself that it being not clear. Mul what I would suggest is instead of the open asset channel we should start having all these discussions on the discord channel for the larger audience >> uh it will help them >> I'm saying the same same discord channel >> oh okay that same discord channel okay >> yes yes yes >> good >> uh uh so yeah I I lost my chain of thought sorry uh >> go ahead red one Yeah. Uh >> I'm just Are you saying like the conversation for these standards are happening on Discord? >> Uh most of us >> Yes. >> are you on that Discord channel? Uh Redwan if not >> I'm I'm more surprised. I felt like this was an instit in institutional like working group uh for really like you know um financial instrument for adoption and discord seems like the worst uh tool to actually have those conversation like none institution if you want to have some actually people joining are going to go on discord to engage with the work that we do and so if we to if even like I would say like the work is being done on discord right now I would say it's not even worth like spending time like to to to do this. I'm I'm I'm really like but justice it's this is a this is a gamer like social media platform and we talking about uh assets for DTCC Euro Clear and the financial world that's just not going to work out. >> So this is uh Sean please go ahead. >> Yeah I was just going to say thanks for that. um LF decentralized trust for the the communities that we have. We use Discord for the in the- moment conversations like hey where can I find this that sort of thing. We also have mailing lists as well. Um we also want to give a uh a community like Otas some some room to find its legs and get to where these discussions can happen. A lot of this work is going to happen in GitHub, but we also want to give folks a chance to raise their hand, say, "Hey, I saw this. Can I do this?" That sort of thing. So we we we tend to have three main channels. Discord for in the- moment conversations, the mailing list, which not a lot of folks have signed up for. We're going to encourage that as well, but also in GitHub itself, whether you're going to do an issue or file a PR or actually, you know, dive into the white paper and start answering some of the questions in the discussion board of the white paper. Um, I I'm I Michael said he respectfully agrees with everyone. Cool. Um, this is what we do with a lot of our other communities like Beu, like Lenith, and others. And and in some cases, like with OTAAS, it's new and we're helping them get their feet. Okay. >> But it's it's awesome feedback and we appreciate it and and we can we can take that to heart and think about what we're doing. >> Is is there anyone from uh working from a bank or any institution on the call right now? >> Uh yes. Do we have we have >> Yeah. Yeah. >> Can you access can you access Discord from your network? >> No, I certainly do not need to access it from my bank network. I do it on my personal capacity. Well, so that's that's could be like a pretty big bridge of your of your your your privacy and what you're supposed to be doing on on your work at the Bank of England or in your I'm not trying to create trouble, but just I've I'm I'm saying that from my experience, you know, I've I've run working groups with JP Morgan and some other banks. Just Google Doc is a is a problem and see if we choose tools that they cannot even access from from their network and from the the way they operate. I'm just saying like that's going to be an issue but also in the meantime you've run like some other like working group at Linux Foundation um that involve institution and and just say like very wary of the tools that you want to use for for this type of engagement but I I'll stop here just my my my kind of like red flag here. >> No, appreciate it. I appreciate it. Red one. Yeah, but that depends on the kind of documentation and communications you are opening. So if it is a formal and definite conversation you want to have you can use the mailing list on LFTT what Sean already mentioned right so and it all depends so so yeah definitely taking your point but you know there are nuances to it >> and even if you do do it on GitHub right I mean not all your repos are accessible through institutions right so yeah it's always going to be there are going to be some you know challenges but I think From what I understand, um, you know, most of the people who have joined here are on Discord and they're able to, uh, you know, respond to these things. We have the mailing list, you know, Red One. So, I I think you're on that mailing list. If you haven't, just subscribe and you should start getting um, you know, weekly updates or or monthly updates based off what your settings are and then, you know, whatever changes and whatever updates you're doing would be really, you know, would could come to you. So um and everything is on the on the GitHub page itself. So you know it's pretty self-explanatory how you can do that. Yeah. Cool. Um yeah go ahead. Uh Mul you you were saying about um >> yes >> the finality and >> right correct. Uh so we were having debate about this technical. So we want to separate technical finality with the legal finality in in the paper and the implementation. Right? So so basically uh he suggest I was talking about uh my conversation with Ivan. So he suggested uh even as we discussed on our last chat with Amit that also technical finality is quite nuance it is very different in different chains and since we uh technical final and as we proposed a committed state uh in our next issue which we want to work on. uh so that also uh technical finality is also uh something we should more discussed on uh more more study upon and uh try to see how we can do that. So as um was saying uh the so the to for more people the as we know the fix standardize how trades get negotiated. Swift standardized how financial institutions uh can talk uh bank message and coordinate uh TCP IP standardized how completely different networks talk to each other without anyone rebuilding uh the post trade layer for tokenized assets uh so don't have any standard yet so we are trying to make the standard that uh make that standard with uh if we and also we uh in the paper especially we try to uh we try to do the comparative analysis of different uh already existing standard. We try to make a we want to make a standard which covers those standard as well. Basically there are technical standards for each chain right. Uh Ethereum uh or wider EVM family has a chain has a standard ERC 3643. It is not it is more of a technical standard not the entire compliance identity complete standard but uh they have a standard. Solana tokens have standard uh different different permission networks have different standard. So he has object model and so on. So we try to uh study them try to identify the con identify the common denominator in them and try to see how we can basically make a standard out of them based on token based type different behavior different canonical event schemas and so on. So uh that's the goal. Uh can we uh uh >> so I want to kind of >> yeah mul I just wanted to kind of see Harris Maria I know Harris you were with a on the last call with Manos as well and you had a few questions more related to identity and how we can manage um those things correct me if I'm wrong do you have those discussion points as such or would you prefer putting it on the um discussion board as such Maybe we'll put it in the discussion board. But >> yeah, I'd appreciate because um Redwan, he comes from that um that world more mostly more on the identity. Red one, correct me if I'm wrong. The last conversation we had, I think it was more related to identity and you wanted to kind of be more closely related to that, right? >> Yeah, I've done a few deep dive on that, right? I'm still doing some actually work on even um general like specification for tokenization um standard. So >> yeah. Um >> yeah. Yeah. So maybe you might be able to kind of you know um you know at least pick those questions if Harris and team put them there mostly more specific to identity right um since they're coming from the SUI group and you know the mist lab. we might have they might have specific questions which they're going through right now which we can then you know leverage in our white paper itself. Uh yeah actually we see we see verifiable credentials as uh like keywords in the white paper and we're trying to understand how this going to be uh like the identity layer of the RWJS >> uh sorry uh proposal as part >> uh we see verifiable credentials as keywords in the the white paper and we're trying to understand how this going to fit with as identity layer in their WA's assets. >> Uh okay. Uh so basically by credentials you mean uh uh by credential you mean the terminal in general terminologies used or do you mean anything else? >> Yes. >> Uh we saw VCs as as keywords in in the white paper. Maybe I will take it more more in detail and I will add a specific question in the discussion board. >> Yeah. So let's do that. Right. I think what we have done Harris is um just to give you a little >> so by terms do you mean these uh events or I I can't seem to hear anyone. I'm sorry. Uh, hi Sish. Can you hear me? >> Yeah. Yeah, I can hear you. I think we lost Harris for a bit. >> Okay, got it. Okay, >> that's all right. So, let's let's proceed. But I think we have an overall understanding what what the next steps would be from Harris's side is just go through the documentation for white paper for and u you know specifically um see what is there for identity. We might have not covered the entire identity portion for the simple reason we were looking at it from the perspective of settlement layer. Uh we wanted someone to pick up the identity layer as well. Correct me if I'm wrong mul right. So it might not be in the best um it might not have all the information that we are expecting but ideally what we want is have these questions so that we can start putting those um you know make it more uh identity specific as well and then maybe red one and Harris can work together to kind of um tweak the white paper or come up with suggestions on how we can add those in the white paper right >> yes of course also >> ah sorry go Yeah, >> go. >> Yes, please go. H of also we have some uh fixes about the SUI stuff like the SU specific >> but yes this is the the tech the technical part that uh because we are using a a new standard we're using the permission tit standard >> so >> okay got it >> to put that >> perfect so we should actually update this by you know with those u changes right let's put those changes in and uh update that as well so that we have the latest Okay, got it. Perfect. >> Can you create issue for it when possible? >> Exactly. Uh sorry, I didn't hear it. >> Can you create an issue for it if possible? Uh so that we can track the changes uh in in the issue and PR uh for it. >> Yeah, of course. Of course. >> Okay, perfect. Uh right. uh a service you were saying something. >> No, I I lost my chain of thought right now. I think you can proceed. >> Okay, got it. So, yeah, that's about the standard. Uh so, we had some other items in the uh uh basically our agenda today. So, you can see the probe, right? This one. >> Yeah. So I spent some time with it and it was actually a good contribution. A community contributor shared a tool uh this tool in the privacy versus composibility thread called Otro by uh so it's a readonly conformance and normalization probe for Otas's version.01 white paper. It reads deployed I mentioned some of this right. uh reads deployed on chain and reports how its observable surface maps on to our model base type behaviors canonical event uh reason codes and flags. What it can't determine is uh basically uh it not uh it is not functional for uh all the chains right now. So it has a uh it has a architecture of different adapters. So we can add some adapters to it but uh it will still lack some uh implementation for some of the chains. Also one thing within settlement and this privacy composibility and also settlement discussion came up is how we are going to treat the treat the networks with private chains or transactions which are supposedly private. So for that I mean the right we can maybe open some discussion around that or maybe we can discuss it right now how we would deal with uh the tokens which are supposed to be private and between two entities which are uh which want that this token or asset to be private for some reason. Uh there could be many reason of course for that and how we should how we would verify or standardize that part. Do people have any opinions on that? We would do that. Uh right now the only discussion which came up with is either some people suggested ZK as a tool or uh some as some hashes related to that or different kinds of mechanism. So do people have opinions about that? >> I mean of course proofs are helpful here Mul. But then depends what kind of implementation we are looking at. If you're looking at some zero knowledge systems or adapters in between, there has to be different setups involved in recipient and the source part. Right? So that includes a lot of infra complexity and add a bit of cost element to that as well and implementation as well. And if you're looking into hashbased verification uh it also depends it adds to scalability and then you know uh the scalability basically because how fast the hash is going to reconcile and and validate the inputs other other verification mechanism could be a universal proof mechanism where you generate one proof that can be verifiable on any kind of setup and I know it it's a far-fetched idea but then we can look into some of the implementations already existing in the market. >> Right. Right. Right. Uh right. That makes sense. Uh so we can work on our own probe and um try to make it available for as many public networks as possible. Uh that's uh we can start doing that also. In order to do that I basically created a uh flow entire flow state of the test. So to make it more possible to visualize how these uh different things and different ideas can be can be converged into one. So I prepared a run for it but I think we have spent the uh yeah we we have reached the timing. So before we can maybe make it public later uh and uh then we can discuss it and it discussion uh but for now uh I think we are almost done but I wanted to discuss another thing. So uh as we are moving towards uh version uh B0.2 uh so I wanted to discuss how how do we handle the branches? Do we branches on GitHub? Do we make a white paper B 0.2 two branch or we make a main branch and weekly or bi-weekly uh merge the main branches changes to white paper v 0.2 branch. Uh do you have any ideas or any opinions about that everyone? >> [snorts] >> I think uh in that case if you know let's let's go with what your approach is um a weekly merge to master would be okay uh ensuring that you know we drop the branch once it's done or else it's another redundant branch that's available once >> no I think I think we should uh keep white paper uh white paper B 0.1 branch as a historical record of the last version of it. But as we are merging into white paperd the main white paper white paper file we should maintain another white paper v 0.2 as we want to make changes to that but uh for that we might have to maintain make that branch again and again. So uh so uh instead we could do what ethereum.org or does essentially is we maintain a main branch and merge merge main branch to the latest branch of white paper white paper 0.2 two or white per 0.3 periodically over a week or over a over a week or couple of weeks would be better for us I think for our P >> so you're you're working out of two two branches right one is your master one is your working branch in this case correct >> no right now our >> no no I'm talking about ETH if you go with the ETH uh mechan right okay right >> all right cool yeah I think that works too I mean as long as you know uh we don't lose anything and and if everybody's okay a thumbs up would be fine. Um if you know and then we can take it from there. I think that would be a good idea for us. Uh let's start there and um you know as and when we make more progress we will then uh you know keep updating the master and then we can push a some kind of a notification to all our users that you know there has been a new version out. >> Right. >> Yep. >> Cool. I think uh that's that's good. So I think we are uh I think [clears throat] above time. This should be a good uh stopping point. Guys, do you have does anybody have any questions related to this? I would suggest if you have anything more concrete towards the white paper, let's start putting more discussion questions around it and then we can start, you know, I mean now that the group is growing, we just had two last week or the week before and there are a lot more people now. I'm guessing you know I'm seeing a lot more traction which is great. So um you know let's try to kind of build those questions and respond if you feel that you know if any of these questions relate to what you're doing today it'll be great if you can start picking those up. It'll definitely help us with how the how how we shape our uh white paper eventually. Yeah. >> Awesome. Thank you so much for your time. Uh Mul this was great. Yeah. So let's talk later. Uh but otherwise thank you so much for your time guys. >> Thank you sir. >> Thank you everyone. Thank you everybody for joining us today and participating. Let me stop the recording.