Hi, Sandy. Hi, Alex. How are you doing? Hello, hello. Not too bad. Good. Okay, I think that we have everyone here so we can
slowly start this AMA while new speakers are joining. So thanks everyone for coming here for this Twitter space today with San Diphatic, the CEO of Kalimera Network. And we are going to discover about
the private charting infrastructure that Kalimero is currently building for near and Aurora and the opportunity that this will open up for the ecosystem. So welcome here Sandy and let's get started with an introduction about yourself.
So just short brief, I'm Sunday, the CEO of Kalimero Network, which is building a privacy-based/scallability-focused site chain on top of Nier.
that I worked two years at New Protocol as the first infrastructure engineer. And before that, I worked at Facebook on releasing Facebook web and spend some time at Google and some other companies.
Cool, so you've been around me since the very beginning and in this sense what inspired you to start working on private charts, where did you see the opportunity?
I mean not very in the not since the very very beginning but quite some time. So essentially like as I worked on the infrastructure project I wanted to have a 20% project to work on and I was thinking about like several ideas I tried to pitch to Elias you know some federated
system some other ideas about gaming ahead and then he had this idea about you know building private charts so we discussed a bit more and like kind of my idea and his idea got into what like Kalimero is today and I mean he started his at 20% project
project, it grew into full-time project and then it will be a proposed spin-off into a separate entity and race external capital. That's how it happened. I think it's very similar to how Aurora happened. So I mean Aurora started similarly.
And if you could explain what private charging is in a very accessible way, how would you describe it and why is it important for the adoption of Web 3? I mean, let's start with
So like the biggest problems in the blockchain space right now are scalability and privacy. So any transaction you send to the public mainnet network, it will be visible to everyone as well. If you have your contract on mainnet,
It's bounded by a number of transactions which may not be executed. Obviously, with charting you can have much higher throughputs, but if you have a very specific use case which needs more than that, then side chains are perfect use case for you. We try to solve both of these problems.
one side privacy as the network is owned by one entity, a set of entities or like a DAO, and only these members can see what the transactions are, and they can set permissions to who and how can external parties interact with the chart.
On top of that, because you own the network, you don't have to pay gas fees, so there's no monetary value to the token, it's just used for a proof of stake. So essentially just for the consensus, you can say who owns how much of the network. So that's kind of like a long story short.
Okay, great. And maybe we can discuss a bit more in details what kind of use cases this can open up. And yeah, whether you are already starting to see some of these use cases come to life.
Yes, I mean there's kind of two verticals we are thinking of when when we go to mark like we're not thinking about go to market one is Web 3 companies who are either looking for running their own up chains with higher scalability or they're looking for more privacy. So that's
kind of Web 3. On the Web 2 side we are targeting more companies who are trying to come into the Web 3 space, but they have very sensitive requirements about how do they store the data. So these are kind of the main verticals. Just to touch on Web 3, a good example would be a DAO in
of having a multi-sig on mainnet where you know multi-sig is public. You could have a private chart run by the Dow, which is essentially a better multi-sig because then you can deploy smart contract between Dow members, all the transactions between the Dow members are private, but then it's still secure
by the stake of every down member inside the private chart. And on the other side, we enabled companies like Imagine you want to have replacing the brokerage, replacing the broker inside trading of like a guy a lot of oil.
microchips, you can have some of these data privately held inside a private chart but then have a public marketplace where these NFTs representing the assets can be bridged onto mainnet. So this is kind of the main two cases bridging the gap between Web2 and Web3.
Okay, so before you mentioned that there are some specific requirements for web to index sense for
a little bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit of a bit#
Can you elaborate a bit more on the question? Oh, before you mentioned that Web2 businesses have some particular requirements when it comes to storing of data. So I was wondering
what you mean by death if you can elaborate more on that point. Sure, sure, sure. I mean, imagine you're building a marketplace which sells, you know, imagine you want to build an Amazon on private
like on mainnet. Every single transaction you bought on Amazon would be public. You probably don't want to know everybody what are you buying on Amazon. So in this case you could have an off-ramp private chart,
there just one entity can run it and then accept crypto and just you know use some functionality of it or in down member cases you maybe don't want to make all the votes public you just want to make the end vote public or you want to have treasury management for departments how the resources allocated
inside the DAO, this shouldn't be public. So these are kind of the use cases. Anything you didn't want to store on mention, but you still need some kind of decentralization. It doesn't have to be full decentralization, but you know, like a federated system, it would work with us.
does that make sense? Yes, that does make sense. Or like OTC trades for example, like you wanted to have a dark pool run by market
where people can trade privately and only the market makers can see the information instead of everybody out there. I think that is kind of a good example as well.
And I was wondering if a company is building a private chart chart through with Kalimero. Can they decide which data they want to keep private and which data they want to keep public or transparent? How would that
So we built, we have several layers of permissions. So for example, we call it the firewall. On top of the bridge, you can define which contracts can call which contracts from Mainnet and the other way around. You can also specify which wallets
public wallets can interact with the private chart. You can also specify which RPC calls and contract calls can be executed by certain users. So this kind of builds the firewall between the private chart and the public. On top of that, we have obviously like, we have the same four
bridge permissions and then we have RPC permissions and then we have like fine grain permissions for querying data from the indexes as well. So you could have like, you know, external developers using the data you allow them to use inside the private chart without exposing some others.
Go on, Alex. Yeah, hello, everybody. I just wanted to jump into this conversation really looking forward to everything that kind of matter is doing.
Just to make it a little bit simpler, can we say that Kalimero is the framework for L2s that are working on top of Nier?
Yes, yes, yes, so it's like a yeah, let's say a site chain framework slash management tool for Lairt was building on
top of near. And this is not on, so that's not the as single kind of L2 that is on top of near, but using Kalimero anyone in the world is able to launch their own L2 solution, right?
Exactly, exactly. So in theory, you could have infinite number of layer tools running on top of Nier. Okay, that's cool. And what about the, if when people are talking about scalability, now they also talking about, you know, L2s and that they are able
to process more transactions than they can source chain, the mother chain. Does Cali Merer deployments are able to process more transactions than the near original blockchain? And if so, have you done any tests with this regard?
I mean, so it's very simple. If you run an app, so there's like two takes on the scalability. One is like, as it's less decentralized than the public network, you can really, you know, do some infrastructure tweaks on how do you run the network. So you just get higher throughput based on that.
But also you're not competing with anybody in the public for a compute time. So instead of you know having one contract which computes with everybody on mainnet, you can have your own contracts inside the upchain which doesn't have to compete with anybody else. So there's like kind of two ways to scale the network.
You also can put more beefy machines like Salana, Salana type of approach. You can put very powerful machines and you will be able to have more compute. Exactly. So anything from infrastructure, machines is customizable to the
network itself. So like you can tweak even the block times the number of gas you are able to execute inside the private chart. So if you have a use case which you know doesn't care about finality that much, you can have higher lower like slower block times with more compute for example or you can just be
the machines, you can do anything you want. Also we kind of removed some of the things needed inside of Nier, like storage costs and all of these things are removed. So you don't have to think about some things you have to think about in public work chains.
Okay, that's pretty cool. I know it is about one use case that is super super sensitive against the block times and this is the ordinary payments, you know, the usual payments that people are
to come back to the point of sale terminal within three seconds. The answer, whether the payment was successful, was accepted or not. And then these three seconds is just the time out. In case there is no answer, then the terminal believes that
It just means that the payment was unsuccessful. So like three seconds, you know, push and finality in three seconds. What with Calamero we will be able to create something like, and as far as understand the near finality is two blue
So can we do the block time like every half a second? So then the finality is reached within one second and then you know a couple of seconds is just to to navigate all over the world, you know, all of the calls. Is it something possible? I think it is. And I think
think like one of the reasons why finality in decentralized networks is a bit slower than it could be is just because of you know slight speed is limited. So if you have servers across the world, you have to wait for a certain time for information to propagate. In our use case, for example,
you could have a collocated private charts for different use cases. So you could have a collocated chart for Europe. You could have a collocated private chart for America East, America West, for you know, Southeast Asia. Because that gives you lower networking times and probably will show
above some finality times on that X aspect. So I think it is possible. Obviously there is a limit of how fast information travels, but I think yes, you can get faster finality times. - I'm Sandy, passing back to Adiana.
Thanks Alex for these questions that provided more depth into Kalimero. So going back to to it then I would like to ask you about the the race the seed
The recently raised 8.5 million and I wanted to ask you what does it mean for Calimero and what are the activities that you're planning to focus on with this raise and by the way, congratulations for that too.
First of all, thank you. And yet to touch on the base, I mean, when we started last year, it was only Mario and me working on it. And obviously we got a few people who joined us early. But I mean, the raising the capital helped us expand the team and obviously
This includes anything from tech. We onboarded some marketing people. We onboarded Glep for business development and this kind of multiplies the things we can do inside the company. Obviously currently we are 16 people, which is still small.
we plan to hire a few more people to help us on the business side. But I mean, the race has significantly helped us improve the product and ship quicker. On the runway side, I mean, we want to, we understand that the market is not the
best at the time. So we want to keep the team small and very agile and do more with less people. So yeah, that's kind of like finding the balance of raising capital but not spending it too fast but have some sustainable growth.
Yeah, that makes sense. And recently I also saw that you have talked about partnership that you have with Spin. And I just wanted to ask you if there is other partnerships on the pipeline and how it has
in going on this side and what are the projects that have displayed more interest in private charts? Yes, so initially when we started we had a lot of Web3 companies from the New York system who started building on top of us and we had a lot of parts
partnerships in the pipeline in the web.t/a sector currently due to the market condition some some of them had hard times to raise and you know things got a bit slower and we kind of refocused on web too. So we will have few announcements on the web to side one really big announcement.
it if it goes through on the infrastructure side. But mostly currently companies building on top of us are like Web 2 companies who haven't been in the blockchain space before. So like we have probably like 60-70% of like standard Web 2 companies who never build in
Web 3 and then we have some others who are established Web 3 companies in the ecosystem who are looking for either scaling or privacy. But there will have some significant announcements in the following months, hopefully.
Cool, that's really nice that you're working with a lot of web2 companies. It's really a good way for attracting them to web3.
Keeping on these notes of partnerships, I would like to ask you what are the plans with building the infrastructure charts in honorora.
So can you repeat building the infrastructure? Yes, bringing private cards on a roll. Okay. Yes. I see. I see. So I said you like, I mean, we obviously understand that you know, near ecosystem and wasm is pretty good. And obviously,
We see near supports, rust and JavaScript contracts. But the reality currently that most of the web three projects currently in the space are solidity based and just bringing our around to like, you know, bringing our all a crowd to be possible to be running on Calimera provides us like
expansion to new markets, which means that we can deploy contracts which are written in solidity, we can expand our partnership network, we can also bring new companies who are asking specifically for EVM solutions. So I think that's going to be a win-win for our aura.
And for us, because on our side people are asking for EDM, I think for Aurora enterprise customers who are looking for a more scalability/privacy solution can deploy Kalimero and I think it's like a win-win on both sides.
Definitely. And do you already know, or is there ready like a plan, or when is this happening?
So essentially, we internally tested how it would work. Obviously, we don't want to run every single part of Aurora Cloud infrastructure by ourselves. So we are working closely with the Aurora team. On, you know, once Aurora Cloud launches publicly, Kalimero will be like one of the first offerings.
So kind of, you know, instead of us rebuilding everything we want to leverage our RORS technology and just be the integrator. Also leaks, you know, you know something that nobody before this or at least from RORS teams, nobody's
you can communicate it outside, these words or oral clouds, but now you did it. I am very sorry. I thought I am pretty sure I saw it somewhere, but my bed. I'll fullyx everywhere.
Yeah, just the rule, that's a standpoint, right? I would like to, you know, I don't know to kind of also answer this question. So, so Kalinero deployment is very, very similar to the Neuroblock chain as this, right? And as everybody who is listening to this,
So hopefully everybody who listens to this knows that Aurora itself is not something, is not like a core change to the protocol. In fact, Aurora is a smart contract that works on top of here, right? It is written and rust, it utilizes all of the
libraries that I available in near ecosystem. So what it means is that in order to kind of have private charts with Aurora there we just need to calibre or to deploy the private charts. You have this settlement
near infrastructure and then on top of this on Aurora smart contract can be deployed and thus inside of this infrastructure there will be an Ethereum virtual machine where people would be able to execute their smart contracts. So that's
That's one of the most straightforward integrations, one of the most straightforward and extremely beneficial partnerships that can possibly happen in between different technology companies. So this solution is for anyone who is interested in this.
We are able to start working on this and you know deploying your particular private chart with EVM runtime there literally today. It's going to take us just several days to set things up and make it fully operational.
And I also think that on one side we are like our horizon layer two for Ethereum on top of near. And I think now with private charging and Aurora together we can also say that we are building layer two's
Ethereum as well, which are privacy-based like Polygon Edge and Avalanche subnet. So I think together we kind of expand the total addressable market, which we can target in the Ethereum ecosystem that we're doing. Yeah, absolutely. Like I see it.
In my head, I see the following way, there is a person, he wants to have his own blockchain or a personal company or a DAO or a community, they would like to have their own blockchain. And then there is a question there, the form, let's say,
where they are just picking up the options. There is one question, do you want your blockchain to be public or private? They are picking up private, it means that they are going to use CaliMarrer's infrastructure. The next question is, do you want your blockchain to have only near
a native runtime or also EVM. They pick it up EVM, it means that there is Aurora that is deployed on top of it. So that's just like options that people are collecting for themselves and then you're just going to work like that. Actually I do believe that it is going
to be much, much smoother and much, much more straightforward than in other ecosystem. So I would say that with Aurora Cloud and with Calimero the launch of
for your own blockchain with your own token, with your own additional features, like some advanced field logic, some access control lists, you know, and all the stuff, and maybe, you know, custom
because some machines that you're working on, the blockchain is working on top of, all of these together with kind of a Aurora, floor the EVM compatible runtimes, this never been possible before, so it is going to be extremely, extremely fast.
I agree. And I think like one thing to mention once you said on the interoperability side, like, you know, if you take, for example, some solutions in the space, which are kind of on like Calimero competitors, let's say, like interacting between Maynet and the private chart, in this case,
is pretty smooth less. Also the bridging time and executing cross-shared contact calls is essentially instant. I think this brings also a set of new use cases which probably weren't possible right now. I mean even with Aurora now having the fast bridge, I think bringing liquidity
to and back becomes much easier. Yeah thanks for mentioning this we also and in Aurora labs we also during the near-con we released the new tech that is called cross-contract calls which sounds strange but this is
set of pre-compiles that allow Aurora developers or the EDM developers to call smart contracts outside of an Aurora instance. We are currently finalizing all of the documentation for this. They call this testing for like four months. We have
running the really thorough testing of the functionality and also waiting for the final results of the audit of it. And once they are there, it's going to be released to the mainnet and indeed with the bridges with Kalimero bridge that is there, such a solution will
will really, really broaden and make interactions, cross-interactions in between Kalimaro sharps and near native runtime, or for example, of the private instance of Aurora and the public instance of Aurora extremely fast and straightforward.
Great, these all sounds really exciting. And moving on, I'd like to ask if someone would like to get started with Kalimero, like either a web tour, web tree companies, what are the steps to follow?
What does it take? So essentially next week we are launching our developer plan, which will be available through the console. So I use anybody from the public health will be able to create an account register.
spin up their private shard in matter of seconds and start developing. So it's going to be like a very streamlined process, few steps, you get your shard running under a minute, you start developing and that's it. After that, this is going to be only test, test net at this moment for
the next few weeks until we battle test everything. After that, once they have deployments running on TestNet and they want to migrate it to Mainnet, they will just create a separate chart for Mainnet and that's it. Very simple few button clicks and you're there.
Awesome. And I also noticed that there are different, I think it's plans that Kalimera provides or options to choose from like Kalimera business enterprise and Ancliffe and I would just like to hear a bit more about
about these different plans. So essentially we have like let's say three three plans for private chart customers. One is the developer plan, which gives you essentially a small instance of the Cali Meron network, the Cali Meron private chart for development purposes.
This means you can deploy contracts, you have a limited number of nodes, a limited number of throughput. And then, I mean, if you need more, let's say, more professional deployment, you would move to the professional plan, which means that you can customize the
number of nodes, you can customize how many bridge transactions you will do, how many cross-shark contract calls you will do, and you pay what you use. On top of that, for enterprise customers and big deployments, we offer custom pricing where we can either deploy
on your cloud when we do the groundwork or we can deploy it for premise as well. So kind of, you know, we expect people to start with the developer plan, build their products, move to professional production as it on mainnet and then eventually move to an enterprise deployment.
or just start with enterprise if they're really big.
Okay, that's clear. Thanks for for the explanation. So I think since we covered quite a lot already, I would like to ask to the public if they have some questions that they would like to ask.
you directly otherwise I'll ask the final questions on the future plans of Karimero. So don't be shy, you can just ask to speak and ask your question.
Can I ask one question to Bowen? Since we have here Bowen from a near-prodical team, the lead of the near-prodical team who is listening to this, Bowen hopefully you will be able to connect.
So I see that there is this new standard that is evolving in the near ecosystem. As far as I understand it is called NAP 488. And this is the standard
that maybe I'm wrong with the number, but this is the standard that allows to create a zero balance addresses. Does it mean that that near also understands and can I follow in the path of Kalimero?
of allowing people to not use this storage stake and mechanism on the level of the protocol, but rather steer it into kind of free storage in some way.
And Bowen, you probably need to click the button of asking to join as a speaker. Yeah, I sent a request, but it hasn't been accepted. Oh, yeah, okay. Okay, but I think, oh, yeah, Bowen. Oh, here it is.
Yeah, so that's a very interesting development. Yeah, so I think there has been a lot of discussion around the storage-staking mechanism in general. I mean, it definitely has pros and cons and one of the main problems
The starting staking is that it makes onboarding quite difficult because in order for someone to onboard, you have to acquire enough near tokens to essentially stake for the account storage of the new account that you're going to create.
which obviously for a new user that means it first have to somehow get near tokens and they cannot actually even do that in like an unseen way of like let's say first having the count of them somehow do something to acquire tokens. They have to pretty much have that ready.
even beforehand that mostly means that they need to have some centralized way of doing that through exchanges or whatnot. So yeah, we think that's a major problem and this zero balance account proposal is attempt to
I would say not fully solve the problem, but I'll leave it the problem to some extent. Now that we've with a proposal, basically, you can create a account with a limited number of keys without having
to pay for starter sticking. Well, you're paying other ways, but basically you burn gas for storage, but you're not having to be subject to starter sticking, and that will make onboarding much easier.
Okay, can you do think we would be able to get into the near protocol, some of the tech that Kalimero developed in this regard, make sure to allow for other ways of calculating for the storage.
Yeah, I mean, I'm all yours. The Karamaru team has the proposals. I'd love to see them.
I mean, the zero gas storage for Kalimero specifically, I think you've proven approved. And it has landed. But it's only for the deposit storage zero.
I don't know if this will make sense for me in it because people could have used it.
I believe that actually just zero out all the gas costs, right? It's not just storage, it's complete. It means like all the gas costs become zero in that in install related to Ecos. Yeah. So I think obviously that
That is very dramatic because Sandy already mentioned it's a abuse factor. But if there are some other ideas on how we can think about storage, it would be a lot of the care of them.
easy to do this because we have for this permission management build on top of the private chart which means that you can define how this data will store and that you can prevent people from abusing it on mainnet you would not really be able to do so which means that you know could bring some
malicious arc actors, but the code change itself is landed in near corn. It just behind the Calimera flag. So we compiled separate flags for making our network work and probably we will have some other proposals in the future. Just like mentioned, one of the things which like Bobo and Steam
protocol has worked on, which is like a significant room for us and could be for Aurora. Like near now supports precompiled verification of signatures, which is in landed in master. It's not all out to test that at the moment, but this will mean that you know the signature verification will be
maybe even more efficient, which makes our bridge even more cheaper. And also, like, Kalimero team is actually working on contributing to the near SDK to support this. So, like, we are also contributing to the protocol itself. And hopefully in the future, we do this more. Which signatures?
is this about BLS signatures? This is for like ID-2-5. Yeah, this is a little bit less relevant for the rainbow bridge because on near we need to check the theorem signatures.
But yeah, yes, yes, yes, yes, yes, yes, yes, yes, yes, that's the difference. Yeah, I also would like with this regard with this regards also and thanks Bowen for for jumping in this discussion. So I would like to mention that to everybody that throughout the development of many different contracts on
We figured out that there are some specific, you know, kind of used plugins that are required for the smart contracts. And by saying plugins, I mean almost everyone need to have their smart contracts upgradable.
almost everyone need to have an ability to pause the execution of some of the methods of the smart contract. Almost everyone needs to have delays in the upgrades, right and stuff like that. So, this set of the plugins we are at the moment finalizing the
So they are developed by our relapses and are taken into some kind of library, if you will, or an SDK. We are finalizing the audit for this, or SDK, and we are happy to contribute it also, as a standard, as some kind of NAP standard in the near protocol.
So everyone with this already audited implementation, so everyone in the new ecosystem would be able to use these primitives. So this is one thing and another thing that is pretty connected with the fees, you know, since we've touched this topic.
I would like to highlight and I would like to encourage everyone to go and take a look at the Aurora Forum, forum.or.dev. In the section engine there is a new discussion that I started just recently. It is about a pretty novel feature
of enabling the arbitrary ERC-20 to be used as gas payment medium or gas payment token inside of Aurora. There are some specifics and we believe that we are
the first one in the EVM world who is coming up with this concept, with this idea that you are able to pay for the gas not only in the base token but also in some other tokens. So we believe that we are one of the first or like just the first one who is coming with this concept.
it heavily relies on the architecture of Aurora and near. So I'm not sure whether this is kind of easily replicable on other blockchains, but at least for us it will be delivered in more versatility and
more advanced risk management for the relayers that are working with Aurora. So I encourage everyone to go there and check out this. Obviously, I'm going to appreciate opinions of Sunday and Bowen on this particular topic. I think it's a pretty cool new development.
Sorry Alex, I didn't fully get what the senior talking about it. Yeah, I mean, like at the moment, Aurora users are paying for gas for the execution of transactions in East, which is the base token of Aurora, right?
And imagine if the user can choose which token he wants to pay for the gas. It might be USDC, it might be near, it might be Aurora, it might be something different. So with this new development, this would be possible.
I think this brings a lot of great things. First of all, if you can paint an aurora in Ethereum, it gives aurora the utility of being one of the payment systems there. But also if you use stablecoins, then you can get more predictable costs of
how much are you paying for the dust fee? So I think that's one of the good things. The only question is which ones do you accept and how do you prevent stockpiling some shit coins? So you really have to be careful of what payment for once you probably don't want to accept everything.
this new proposal, but in short it is up to the relay or the RPC node to choose which tokens they are accepting. One relay can say, "Okay, I'm accepting stablecoins only." Another one says that I'm going to accept
East and Aurora and third one can say I'm accepting my own token You know to pay you know you know for for the users who are connected through this real air to access or or option This is all possible this mean that but that means that the relay will be like swapping no no no to it here
And then paying in it. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no,#
layer that needs to occur and within this payment, this payment can be settled in any year's seed money. At the moment, this payment is settled in ETH in the base token, but we are allowing for this settlement to be done in any current
That's really or is okay with
Yeah, I think it's very exciting because now you can pay our road transactions in our road token as well, which are over three. I have a lot more utility to the or token itself.
great for the Aurora ecosystem. And I think, yeah, so a similar single company here pretty similar as well, where you can users don't necessarily have to pay their transactions in near, I mean,
Obviously, it's still probably a lot of people would, a lot of people would do, but we can imagine people playing in stable coins because they want more predictable costs are like paid in like sweat for sweat coin users.
Okay, that was a very interesting discussion. I think in this phase there was a lot of alpha being drawn.
then a lot of new ideas for the future. And if nobody has other questions regarding Kalimero, then maybe I can ask some final questions to Sandy.
And yeah, so I'd like to ask you what are the next steps for Kalimero? What are you focusing on right now and what can we look for in the near future?
So obviously as I mentioned, we are launching the console. So that is priority number zero or minus one. Then we will be attending ETH dendr. So we're going to have some presence there.
And then after that, like I mean, we are working on getting EVM on Cali Mero Shards as soon as possible. So that's one of the things we would like to do as early as possible. And we have some other new features which we want to integrate inside the console, which we'll enable using private shards more easily.
So we are building this system which we call Oracle's as a service which will provide either integration of external or or a cause or provide the ability for users to deploy their own Oracle services. Also we are building an events as a service optionality which
provide you know have custom alerts triggers events happening on the private charge itself based on you know certain action triggers. So I kind of these are the main two things. Also we are working on this thing we currently workspace
So that's going to be kind of the ability for private charts to be like for users to have consortium networks inside the console easily. So you will be able to start a private chart by yourself and then invite other people to join the consortium as they go.
So yeah, that's kind of the roadmap for us in the next few months. But yeah, that's pretty much it. And obviously, business development, generating revenue, bringing more customers and projects. That's like a evergreen for us.
Yeah, I can imagine of course. Okay, then I thank you for coming to this space today. Thanks Alex and Bowen for joining the discussion and adding your thoughts and comments and questions to
to tweet and will be waiting for private charts on Aurora. Really exciting and really exciting news about Kalimera and what it's building in the ecosystem. So thanks everyone.
Great development, sending your rocket. Bowen, you have been rocking it before us also and continue to rock. So super glad to see all of these great people joined in a single-anchor system and moving things forward.
Thank you for the kind words. Yes, thank you for the kind words and thank you for inviting me here. Hopefully you know, we'll have few more of these and some big announcements coming in the following months and yeah, let's keep shipping.
for sure. Keeping that chained, have a nice day everyone. Bye bye.