Video summary
The Paladin Community Call for September 2026 primarily focused on recapping recent progress and outlining the roadmap for future development, with a significant emphasis on performance optimization and versioning strategies. The team highlighted that version 1.1 will largely consist of non-functional enhancements aimed at improving system efficiency rather than introducing major new features. Key achievements include reaching triple-digit transactions per second (TPS) through optimizations such as reducing memory allocations to minimize garbage collection overhead, optimizing lock holding times, and improving data transmission between nodes for co-located queries. These efforts established a crucial performance baseline to ensure that future releases do not regress these gains while preparing the codebase for more architecturally significant improvements in subsequent versions.
Looking ahead to version 1.2 and beyond, the discussion centered on two major functional areas: multi-tenancy support and enhancements for private smart contracts within the Pentec layer. Multi-tenancy aims to allow a single Paladin instance to serve multiple users with distinct identities and access controls, addressing organizational challenges where running separate instances for every user is impractical. Additionally, the team plans to address scalability issues in Pentec where single-account state changes involving large maps currently result in inefficient state diffs; future updates will refine this mechanism to make private smart contracts easier to use and more scalable. The community also discussed the importance of clear versioning across different components like domains and domain factories to ensure backward compatibility and transparent sequencing rules for transactions.
A notable topic addressed was the integration path for the Java SDK, which has been developed independently but is intended to be merged into the main Paladin release once it reaches maturity. The speakers debated whether the SDK should be released separately or bundled directly with a specific Paladin version, such as 1.2, depending on when the mentorship program concludes and the SDK is ready for production. To accommodate the project lifecycle of the Java SDK without constraining its development timeline, the team proposed aligning the Paladin release schedule with the readiness of the SDK, ensuring that the Maven artifacts are versioned alongside the main software. This flexible approach allows the community to support independent contributions while maintaining a cohesive ecosystem, with further details on timing and integration plans to be discussed offline via Discord.
The meeting concluded with an agreement to continue using GitHub issues under the governance repository for community call agendas, replacing the less structured wiki format to better organize minutes, action items, and policy reminders. The hosts emphasized that while this month's agenda was light due to the focus on internal optimizations and planning, the next call is expected to feature a detailed roadmap visualization and further updates on the Java SDK. By maintaining open communication channels and documenting versioning rules clearly, the Paladin team aims to foster a robust ecosystem where various components can evolve independently yet remain compatible, ensuring long-term stability and growth for the decentralized trust community.
Read the full video transcript
Hi, Divian. Great to see you.
>> Hi. How is it going?
>> Very good, thanks. Yeah, very good. Um,
how are you?
>> Yeah, I'm good, thank you.
We're um uh probably just going to wait
another minute or two. We may or may not
get other people joining. I didn't put
anything on the agenda today uh around
the SDK. Um
>> yeah.
>> Um so if there's anything you do want to
mention, then feel free to let me know
and I can put it on the agenda, but um
otherwise Anna and I were just going to
recap a couple of um couple of things.
>> Yeah. Okay.
as if like nothing from my side also but
yeah let's see
>> sure sounds good I'll go back on mute
and we'll we'll start in a couple of
minutes Okay.
Okay. So, um it's nearly 5. So, um I
think we'll start now. We'll see if
anyone else joins. Um I guess mainly for
the I guess for the recording. I think
everyone in here is aware of the
antitrust policy um which all of the
Linux Foundation decentralized trust uh
community calls are run under. Um uh so
just bear that in mind please and also
that um this meeting is recorded. Um so
uh please stay on mute when you're not
talking all those kind of things. Um so
there's not not a huge amount this month
to cover. We had a really good update
from DVM last last month on the SDK
progress and I know we got some more PRs
um to review from you DVM on on the the
next round of improvements. Um
uh yeah, like I said, we didn't put
anything on here to talk more about the
SDK this month. Um maybe next month
would be a good time to to do another
update on some of the latest stuff and
maybe demo some of the newer things if
that's okay.
Yeah, we'll see. I think next month will
be interesting stuff coming.
>> Great. That that would be really good.
>> Um so the other thing to note is that
we've moved to the community call
agendas being um under git issues under
the governance repo. So um at least one
other LFDT project started using this
mechanism kind of scales better than the
wiki which doesn't have a lot of
structure at least the default wiki
doesn't have a lot of structure in in
GitHub. Um so it's just be becoming an
endless list and this way doing it means
we've we've got a template. So when we
create new community calls in the
future, um you can choose the community
call agenda template which adds in the
antitrust policy links uh the reminders
and so on. Um and this is a good place
for people to drop comments. We can drop
any actions minutes into here and then
close the issues. So um I've put a note
in the wiki pointing at this first one.
Um so um uh yeah, we'll use this going
forward and see how we get on.
Um, so we just put a few small updates
on here for this uh month. Um, a quick
update on performance. So Anna mentioned
this briefly last month, but um, we
thought it' be good just to mention a
little more, just a smidge more detail,
just a couple of minutes um, on that. A
bit of thoughts around what we might
want to get into 1.1. So what we're kind
of waiting for. Um, this this title here
I think is kind of a bit too simplistic.
Let me just edit. I think
um I think we've got
I'm just going to tweak this.
[snorts]
Uh I think that is a little better. Um
uh so yeah bit around 1.1 when might we
get it and what are we waiting for and
then what what might be the features
coming next. We haven't got um like a
road map chart for for these two yet,
but maybe next month we'll have a road
map roadmap picture with a bit more
detail on um and then I just wanted to
mention some discussions Anna and I have
been having it having in person because
I think it's good for the community to
hear some of that where we don't have
them in the open because we happen to be
kind of working colloccated.
Um so Anna, do you want to just give us
a smidge of an update on performance in
a bit more detail than we had last
month?
So I think I mentioned last month I've
been looking at some noto scenarios. So
specifically the performance of no mints
and no transfers. This has all been
stuff we're looking at within a single
domain instance.
Um we've largely wrapped up that work
now. Um there's still some code working
through the pipeline. Um but at a rough
target for what we've been aiming for
here, we've hit triple figures in TPS.
Um which is a big step forward from
where we were. It's probably worth a lot
of the Paladin code. This is the first
time that we've actually performance
tested Paladin code. Um so this round of
testing and optimization has really just
been about um establishing a good
baseline. I'm sure in the future we will
have more work to do where we do more
architecturally significant work to
raise performance. Um
yeah, so a lot of the changes this time
around have been areas like really
reducing allocations
so that we don't have the garbage
collector hampering our performance.
I would work around optimizing when
we're holding locks.
>> Um
um
work to reduce how much information
sending between nodes to co um allow
querying to happen colllocated where the
information is that's assembly time um
and yeah that's y some really good
results. So now moving on to trying to
achieve the same sort of effects for
pente
um and at the end of this we should have
some baselines established which mean
that as we go with future releases,
we're making sure that we are not
regressing these levels.
>> Great. Thank you. Um, and that kind of
leads into to a little bit because I
think we certainly wanted version 1.1
when it comes out to benefit from a
bunch of this performance work, which I
think it will do. Um, and that's why I
think functionally if we move on to item
two a little bit, functionally u 1.1 is
probably going to be kind of it's going
to probably seem a bit light in in the
amount of time between v v1 and now or
when we put it out. Um, but I think
that's because a lot of it is kind of
non-functional performance enhancements
and
um, uh, refactoring existing logic so it
performs and and is just structured
better I think in a lot of the code. Um,
so the main thing I think that we will
probably be getting in for version 1.1
is ZTO's multi- version support and
backwards compatibility with existing
ZTO tokens um to get it in line with
noto um there are some fixes around not
coming in as well but but they're really
kind of bug fixes business as usual to
an extent
um and then so so stuff that we'll talk
about in more detail as we have time to
kind of design and plan around it a bit
more for like maybe a 1.2.
So this is kind of item three here.
So the I think two of the main items
we've been talking about are
multi-tenencies. So if I have a an
instance of Paladin and I have several
users who um are going to use different
identities or they um have no need to
have visibility of each other's uh
transactions but there is a kind of a a
tenency benefit to just running one
Paladin instance but having different uh
users uh with different um access
control, excuse [clears throat] me.
um that's kind of all hung under this
banner of multi-tenency. At the moment,
we've had some users kind of express an
interest in that um where they have a
large number of discrete users who um
running an an instance for every one of
them would be kind of organizationally
challenging. Um so that we are going to
be giving more more thought to it. Um
and we'll have maybe some some thoughts
around that for future calls. And then
one of the other things that we'll
probably look at because I think this
has come up on Discord and we were kind
of aware of it but as as people start to
to use Paladin a bit more in earnest
it's going to come a bit more um is
around excuse me again um the way that
uh private smart contracts in Pentec
changes um are implemented. Um so a
single account um which means a single
contract and its storage um is
represented by a single state. So
changing one entry in a map um where
there may be hundreds of other entries
in the map uh result in one very large
state change diff um as the input and
output UTXO behavior. So that doesn't
scale very well. Um and I think that's
something that we'll be looking to
improve. Um, we've had some minor kind
of chats about it in person. Um, but I
think that's probably one of the
functional changes that will make Pente
much easier to use in certain for
certain types of contract.
Um, okay. And then yeah, the only other
thing that this item four here was
really um again partly just to relay
some of the thoughts and discussions we
we have in person because you know as an
open source community um we benefit from
Anna and I benefit from from being loc.
So some of the things we've been talking
about which may may kind of come up in a
more concrete fashion in the future of
our PRs and issues are just generally
around versioning.
One part of that is um forwards and
backwards compatibility between in
versions of Paladin. So we have version
one we have put out a statement around
the point at which we will endeavor to
have
uh new versions of Paladin always
compatible with previous versions for
sequencing of transactions.
Um so that's one area. Um but also as
we've been having conversations we
realized we're talking about many
different categories of version be they
versions of domains um versions of
domain factories um how that how they
relate what kind of what rules exist
today for our existing domains in terms
of supporting for example noto tokens
that were created from an older version
of a factory as well as creating new
tokens with a newer version of that
specification. and so on. So I think
we're going to just try and partly maybe
some docs, partly some guidance around
what the different versions relate to.
Um not all domain implementations will
follow the rules that the the reference
domains have used. Um
but it's useful I think to be really
clear in the documentation
um the kind the different versions that
exist and the current behaviors we we
endeavor to have for the reference
domains at the very least um so that we
can have conversations that are nice and
clear which ones we're talking about. So
just general versioning um discussions
because there are lots of not not
plugins in the traditional sense yet but
there are lots of discrete components
that could arguably um be used
independently of each other and they all
have tended to have versions that sound
very similar but actually maybe quite
different version one being a good
example.
So um fairly short but sweet. Um
maybe we will aim next month as we said
Divvam to have maybe another update on
the Java SDK which I know is kind of
going going really well. Um
uh I don't think I had anything else for
today. Um
any other business either of you aware
of?
Okay,
great. I think that's uh that's good.
>> Hey, I have a like question to ask.
>> Yeah.
So, uh since like you guys are uh have
you know discuss discussion of like
versions on this call. So this thing
came into my mind uh like the Java SDK
that I am working on like we'll be
launching it independently
uh or like that will be included in the
next version of Paladin only.
>> Yeah, that's a good question. Um so
currently the SDKs are shipped within um
um as part of Paladin's build and
release process.
So my thinking around this have been
that when we're happy that the release
branch is is pretty close to complete,
we would align that with a release of
Paladin to merge the release branch into
to main. Um
>> my my kind of gut feel is that that
might be around the time that we would
cut 1.2 of Paladin.
Um, no, no, we we we could
try and align a release just around the
timings of the one of the Java SDK being
ready because I think it would be kind
of a substantial new contribution to
Paladin
that also because I know your your
mentorship program runs for a period of
time and and we don't want to
necessarily we don't want to pin your
kind of your project life cycle to other
work we're doing necessary. So it might
be that we plan for let's say Paladin
1.2 is released when the Java SDK is
ready and then the SDK would be just
part of Paladin 1.2. I think that's
that's my thinking and and then the the
Maven artifacts would be kind of
versioned along with the Paladin
version.
Um
>> okay
>> does um but I may maybe um offline of
the call if if you have any kind of kind
of comments or questions or thoughts
around that Divian do do give me a shout
on Discord if um if you want to discuss
that in a bit more detail particularly
like the timings of when the mentorship
program ends when you think you you're
going to be aiming to wrap up and then
we can maybe pin pin down some proposed
dates a bit more closely to help you out
with your planning.
Yeah. Yeah, sure.
>> Great.
Okay, cool. Thanks everyone. I think
that's everything for today. Thanks for
joining. Um, and we'll catch you on next
month's call.
>> Yeah. Bye.
>> Bye for now.