Open Tokenized Asset Standard (OTAS) Community Call - 2026/08/25
Watch on YouTubeVideo 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.