Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
DEV🕶️TIME: Patterns, Tools & Cross-Chain
Recorded: Aug. 28, 2025 Duration: 0:41:24Space Recording
Full Transcription
Music Thank you. Hello everyone, welcome to the DevTime.
Let me invite Dima to the stage, I hope you can all hear me.
Hi Dima.
Yeah, hi, could you hear me? Yes, I can hear hear you yeah hi how are you doing i'm good how are you
yeah me too thank you nice so uh we're gonna wait a few minutes for vatim to join
as second speaker and we're gonna start slowly uh So today's session, we're gonna talk about patterns,
tools and cross chain.
We are having here Dima and Vadim as the core developers
and we will go through some questions
and then at the end, if anyone has some question,
you can raise a hand and ask at the end.
Hi, Vadim, can you hear me as well?
Yeah, hi, Claire. Hi, Dima. How are you?
We are good. How are you?
I'm good. All good.
Okay. Yes, Dima?
Did you raise your hand?
No, no, it wasn't like raising a hand, it was like shaking it.
Okay, okay. So I think we can start. So as I mentioned, if anyone has any question, you can ask at the end.
And I think we can slowly start. Also, the whole Xpay is recorded.
So for those who couldn't join or will join later,
they can listen to the recording afterwards.
So let me start with the first question, which I have for you guys.
So could you tell us about what kind of development patterns
are emerging in blockchain applications these days?
And how does the VAR ecosystem support these modern architectural approaches?
It's still raising a hand by the Vadim, actually.
Oh, yeah.
Oh, yeah.
Yeah, you can stop talking if you want.
Yeah, you can stop the word if you want.
Actually, I know about asynchronous messaging implemented nowadays in different blockchains
and networks, and also in VAR networks, asynchronous messaging system, and even sourced design so you can make asynchronous calls and thanks to an actor
model you can asynchronously call different programs, different actors and there is not like a queue
there is not like a queue of synchronous calls and I see this pattern implemented in different
different new networks
uh it's also interesting thing yeah yeah uh I was about to say that uh that you just mentioned
I was about to say that you just mentioned, you just said is like indeed the core developer of some kind of L1 or L2 or something like this, because I think the most generic thing for all of them nowadays, it's like building something
which will be modular as it could be.
And that's because it helps you to support and maintain your code base.
It's support helps you to improve the security of the things, help you to implement some
like new solutions.
If something got released, for for example new the key algorithm or
something like this and it could improve your overall performance it's good to have it it's way
easier to implement if you have like different models which somehow interact with each other
for example as a different actor so that you just mentioned so um i think from the bar perspective it helps um we have kind of
a lot of things to help you to develop something and then we help you to build in the most
appropriate from the tech perspective way so for example speaking of modularity if you take the
sales as a primary of the primary component for a water ecosystem, it's super easy to reuse components,
take some program from somebody else and adjust it for your needs.
It helps you to build new interfaces.
It helps you to build the clients on the different languages.
So it's also extends and scales you across different toolings,
different languages, different languages and different
approaches how to do something.
For example, query states.
So you could use just HTTPS queries.
You could use some improved things like if
you would like to call RPC calls from the
from the RPC notes or something like this.
Yeah. call RPC calls from the from the RPC nodes or something like this yeah I'd
like to add I remember such a thing it's called on-chain wallet and in
different blockchains you can have a world like an on-chain program like a
different like yeah like a different actor for For example, Tone blockchain, or I think
a new Ethereum upgrade has it.
Like your wallet, it's an on-chain contract,
and you need to interact with other tokens or other contracts
via your wallet contract.
So to sign a transaction, you need to call your wallet contract so to sign a transaction you need to call your wallet
and i think it's a new approach on how to secure your stuff your wallet and make it
more safe to use so you need to approve every uh no maybe it's the same ux as it
as an old world but it has a different use cases i can't come up with the
ideas I need to look it up yeah but but as far as I know there is a place of the protocols that
ideas i need to look it up
provide access to your private phrase which is do not exist actually for the for the thing as
an on-chain wallets but you could go with the like easiest key way see like you log in with
your Gmail account and go and do your things on chain as you used to do
all right so i guess we can move to the next question uh which may be gonna give some advices
to developers so when building a cross-chain applications, what architectural decisions should developers consider?
Meaning, like, how do different patterns affect scalability or user experience, etc.?
I'll not only say that there is some architectural or tech considerations that you might that you may want
to think of building something cross-chain but there is much more important things that are like
more conceptual things uh like having it super transparent as much as it is as it's possible
just because there is a blockchain space and we all used to have some transparency in the operations.
It's also super important to develop some fault-tolerant soft.
It's super important to do it with some proofs, like having your compute or any actions or events secured by some bulletproof company,
bulletproof algorithm of verifying this overall security of your system so I think there is not exact like set of patterns that you
may want to use but there is a couple of them in the industry so for example if you want to build
something cross-chain and you want to build it all alone without any already existing solutions like bridges and stuff, just because you don't want to like trust them, you is also economical sense, like, you know, consoles.
So for example, you have like 20 validators that have their stakes on this deal
as it does at Wormhole.
For example, Wormhole Bridge works exactly this way.
So you have like a network of the validators.
They have their stakes locked.
So you trust them just because they
could be punished for something misleading or incorrect actually
oh i know a few common question are patterns like mirrored apps where you have the same logic same contract on
different chains and the it's like a simple way but it's complex to upgrade
each contract and another pattern is like you have your main chain one
canonical state like Ethereum Ethereum, for example.
And you need to synchronize this canonical state
to your other chains by some governance or some ZKs,
cross-chain messaging.
And these two are two different patterns
how you can solve your cross-chain deployment.
And yeah, you can use something like wormhole to pass different messages.
All right, thanks guys. So what does the typical development workflow look like for modern blockchain applications?
And if you could describe how has this involved with the new tooling and infrastructure?
Yeah, I think it doesn't differ from the, you know, common sense, typical programming for Web2,
No common sense, typical programming for Web2, just because it's a software that you develop and you must follow some classic rules how to do this.
So, for example, everything starts with an idea.
Then you choose the most suitable environment for you.
You consider some options how you could solve your problem.
You think of other options, some alternative that you may follow.
If there is somebody else on the market inside the industry who already solved
your initial initial issue.
So and then you start doing something on already chosen exact chain, exact tooling and stuff.
And then you should have thoughts about some optimizations, about security concerns
of usual. So I think the infrastructure and tooling place the primary, they have
the primary role of your developing process just because you better to choose
something, some environment that is much easier for you to implement your solution.
Just because you may spend, for example, a year building something on, for example,
Tone or maybe even Bitcoin, like roll ups on the the Bitcoin which work with the messaging inside
the Bitcoin transactions and stuff or you could come to Vara and build your application of the
dream in like one or two weeks having a couple of developers which will solve your issue like
like the way you mentioned it from the very first place
the way you mentioned it from the very first place
yeah basically you need to choose your network and then you after it can be
Ethereum for example EVM or VAR network gear protocol and your workflow will look like you
Your workflow will look like you can look up any existing project on these networks and just look at how they done things, how they manage their infrastructure, deployment.
For example, for EVM, you can use Foundry, Anvil, and deploy your test environment.
And for VAR network, you can use can use sales etc and gtests for
example and yeah you just look up the different projects that are already exist and maybe you can find already a solution for your ideas.
And yeah, that's how the modern workflow works.
You just set up your project infrastructure, testing, deployment, and et cetera.
And you go. And also, of course, you need to look up at different solutions
yeah it also worth mentioning that there is always economical sense uh in a blockchain space just
because there is a money everywhere the money you may want or don't want to spend there is
the money that your customers uh may want or not want to spend and there is a money that your customers may want or not want to spend.
And there is a lot of things about this just because the tokenomics as usual is super important
question inside the L1s or L2s and every single protocol just because you may want
not to use something that is better from the tech perspective or more safe just because they're all humans or or they're all just person that want to have some
subservice so we don't want to overpay for things yeah it economics is very
hard concept for who coming from web to space and it's just mind-blowing how to plan, how to manage everything in Web3.
So you guys mentioned that people or developers should check out the projects and see what
kind of tooling they have and kind of kind of just like started with that would you be able to provide some
examples of blockchain ecosystem you think are the easiest to start with or you think have a lot
to offer yeah you mean just an example so for l1s or l2s to start with? Yes, if you have some, you know, which you keep an eye on and you know,
would recommend. Yeah, speaking of me, I personally keep an eye on the VAR network.
Actually, I think it's a great project just because there is like, there are a lot of guys,
awesome guys developing it. And to be serious, I would say that the answer to this question is somewhere nearby top 20 most used chains in the world.
So for example, if you're looking for some high liquidity, it's better to go to Ethereum.
If you're looking for some kind of things like fast finalization, it's better to go to the Solana just because they have this this kind
of thing of distributed wallets and the wallets for the programs on their chain um and speaking
of vara so if you if you are looking uh some high performable and um almighty solution I would say
like something like this just because there just because there is no limitation.
There is just the Rust code that we compile into wasn't there is like four
gigabytes limits for each single program and you could have plenty of them.
So you could store like a really huge data on the chain.
You could operate with it.
You could update it.
You could maintain, for example, some kind of database on chain only related to your protocol with
the right permissions.
There is a good thing about VAR that you could develop something hard and actually do not
think about how to do it on chain.
You only think how to do it as a common common program as in the like the courses inside your university
when you're just solving some algorithmical tasks you develop something on vara the same
way and then you come to us uh have already your code prepared um adapted for our tooling
for example for sales and it just works for you without you needing in knowing a lot of
concepts about the blockchains, how it works, why and how.
So you only develop your primary business logic and deploy it in a minute.
Do not waste a lot of money.
Do not waste a lot of time for understand what's happening just because it's works
like almost out of the box.
Great. I would like to mention Solana but just one thing sorry I just forgot about
only mentioning Vara but there is also gear X as a layer two for ethereum it gives you the
same opportunities is in Vara but helps you to operate with ethereum liquidity so for example
if you want ethereum, you could go to
GeerXe just because it's like better or almost for all of the
cases that involve some computational.
So it's option.
It's always option for new newcomers to the crypto.
It's always option for developers and business owners to migrate or start
their business inside Ethereum using GearXD.
Yeah, by learning GearPotical, you can deploy your smart contracts in VAR network and then
you can come to GearXD and it will be like an easy way to start something in Web3 coming to Ethereum ecosystem and to VAR ecosystem.
But I would like to mention Solana as a great chain. For example it's just one of
the top chains but actually development and deploying on Solana was a nightmare.
I tried it a few times and just to get it compiled,
tested and deployed, it took me like a week maybe to just dive in how to operate on Solana
and comparing to Gear Protocol it was a nightmare. Gear Protocol wins. And yeah, I would like to mention Solana as a top comparable chain to Gear Protocol.
And it just sucks.
That's it.
All right.
So Dima, as always, tooting up for bar and gear.
And Vadim giving us also another examples.
Love it.
So let's move to the next question.
What are some most common architecture pitfalls
developers encounter when building cross-chain applications
building cross-chain applications and how this can be avoid.
and how this can be avoided?
I think there is no some there is also no some unified solution for this problem just because
it depends on what kind of application you build and what kind of cross-chain tooling you use for
example is it wormhole is it the key bridges is it like the wrapping bridges
like for example in ethereum and arbitrum and stuff um but i think the main the primary pitfalls
for developers it's security it's the pricing for relaying something from one chain to another
and there is always a time uh thing just because may want to build, for example, some speedy applications.
It could be like ZK Poker, for example, but you cannot achieve the same speed on the destination chain.
And you could play the game, for example, on chain one and then proxy the results to the destination chain with the economical sense.
results to the destination chain with the economical sense but if it like took from you
maybe two or three hours to wait until your request will be breached it's super bad for you
and you could consider some other options how to do this maybe you could use the key on the first
chain just in place or reconsider the environment you use to build something.
One of the most common pitfalls, I think, is just finality mismatches.
Like you need, you should wait for economic finality to be sure that your
transaction could not be reverted.
And this pitfall, I think, can spoil everything. You should wait for finality on each chain that you work with.
Like, for example, maybe some error or maybe some number of blocks.
And you just want to be sure that everything goes as you expected.
And another pitfall, I think, is message ordering or duplicates.
So if you have different chains, you operate on different chains,
you need somehow to track your unique IDs or nuances to your contract.
For example, if you have some user base or some tracking system and yeah you
just need to be in sync in different chains and of course maybe you just need to watch for
to look for different replay attacks on different chains you just need to keep this in mind you
need to secure your stuff i think it's just related to the economic reality you just
want to make sure you don't miss anything
Yeah.
All right.
Thanks, guys.
So another question.
How do on-chain and off-chain execution patterns complement each other in modern application
architecture?
And what kind of opportunity does this hybrid approach create?
That's a simple one, just because the thing as off-chain computation, they appeared in the world when we had a need to do something like huge computational,
maybe refining something or rolling the game around or something like this and inside the on chain which is highly
limited with highly limited with the computing power of your validator it's highly limited by
time just because the blockchain must produce blocks time to time so some kind of constant
time actually and um i think this hybrid type of building some application it's because it's gonna become
uh some kind of gold standard in future just because you don't need to do everything on
chain because the on-chain part is for your settlement it's for your operations that
shouldn't be somehow reverted it's all about the data availability and stuff.
All of these high pink words we hear every day actually in Xspace.
I think the off-chain part is super important right now.
And there is a lot of protocols working on building trusted environments off-chain with some kind of validations on chain so for example the
same for gear x and the future plans of the gear xd moving all of the computes uh to the zk thing
and we're gonna have um you know kind of uh recursive proving for proving for proving some
computes so it will take like only a few a couple of seconds or a couple of
milliseconds on uh on the settlement chain for example ethereum to prove that we made for example
100 seconds work off chain so and it's still be trusted it could be trusted it will be and we could operate the same tokens from ethereum but
off-chain with some kind of uh guarantee for settlement
yeah i i agree you can think of on-chain is like a commitment and settlement for the
database like blockchain is a database and off-chain execution is more like
in usual databases you have something like cursor and you can make changes to your
database overlay and you need to commit changes only after you've done everything. And you actually commit the new changes to your database.
And I think Gear X works the same.
You just make some of chain executions
and for on-chain parts you just need to
press commit button. You just commit your changes
and that's it. i think yeah that's
the future of hybrids cross-chain on chain of chain things
all right thanks guys i love that today uh you guys uh come like complete each other and you
both take some time to answer each question.
I think it gives us good insights from both of your sides.
And let's move to the next question.
So framework selection significantly impacts development experience.
What would you say that makes smart contract framework effective for modern applications?
And what should developers evaluate?
That's exactly the thing that Vadim mentioned about the Solana development.
I don't have a lot of experience in it, to be honest with you.
But I had several friends doing some, you know know complex and complicated protocols in Solana and
all of them they said to me it's just a nightmare actually to develop something on vanilla Solana
so that's exactly the reason why they or not exactly they but anyway somebody developed anchor framework on Solana to work with it uh
just because with anchor you could have some kind of normal uh programming experience using vanilla
Solana it's super hard to understand what's happening it's super hard to understand uh how
to do something there is yeah of course there is always some guides. So there's some videos on the on the net. But anyway, it's just, it's just
hard to use. And from a framework perspective, what
should they cover, they should cover your costs for
understanding for first thing. Second thing they could give
you some, you know, stability for you. So if you update from one version to another,
maybe like a couple of versions bump, it should make your code more secure or performable.
So the frameworks abstract the logic from you and helps you to do the right thing. If you have like
some good idea, it's also applicable to the web tool world.
It's also applicable to some huge core development,
for example, using substrate instead of building something
on your own when you want to release some layer one
or something like this.
So for example, in Vara, as I mentioned before,
we have a sales framework that helps you it's it covers
all of the boiler plate from you and you don't need to think of the unimportant things yeah
okay good uh what i think would make a good smart contract framework of course it's about your understanding of what are you doing and
understanding of what actually the network do and you would like to look for of course
safety model determinism like rust wasm and you need to look for
and you need to look for something that is...
I missed my point, but you need to look for something that has already a big user space. For example Rust, it has a lot of users and WebAssembly has a lot of documentation
and users. And what else? You need to look for good testing and simulation like Foundry in EVM or
EVM or sales in VARA.
And it's just simple to use.
And it's like one-to-one simulation
to the actual on-chain logic.
And what else?
You would like to look for good SDKs, CLIs,
or for example, GS SDKs, so you can easily work with your development outside of chain, like for an off-chain part.
Yeah, that's it.
Actually, if you don't mind, I would like to make a joke from your speech.
make a joke from your speech. It's not about you. I'm not some kind of bad guy here, but
I just realized that the point of having some frameworks, some trusted and complex frameworks
and fulfilled with the tooling and SDKs with the deployment things, with the testing features
and stuff is to help you to not to miss your point when you develop.
Okay, so I guess we can continue to the next question.
So my next question would be, since multi-chain architecture are becoming standard these days,
what does it really mean for developers?
And what they should think about, like regarding the application design and user experience,
like what it should have and maybe if these days you need to think about applications in different
like what it should have.
way to attract people if you could maybe share some insights regarding this yeah i think not
some exact insights but uh from my point of view uh the initial take of multi-chain uh things
becoming standard in an industry.
I would say it's kind of controversial just because there is plenty of them there.
It's IP and it's always good to have for any protocol, some bridging or cross-chain
solutions, but I'm not sure if it's like must have for somebody.
If you cover your special need uh if you cover your primary features
and they are unique and they help people they help industry to grow in like in the future uh you don't
actually need to focus on something like cross chain if it doesn't fit your needs so um I think
application designs uh in these terms always require always require you to have the reason to build something multi-chain.
And then you just also come to some common sense.
You should provide some good tooling to use to interact with it.
You should have some guarantees.
It's good to have some support groups.
So, for example, if you develop something by yourself, it's good to have some support groups so for example if you develop something
by yourself it's not good just because you may sleep time to time but the blockchains never sleep
and you need somebody to cover and support it while it's running you may want to build strong
community of believers in your protocol you may want to do not only the tech
stuff because the crypto is not only about the tech it's about the market it's about the people
and and it's always was and always will be about the ideas
Badim, would you like to add some comments as well?
I'm fine.
I'm taking a break.
Okay, okay.
So, to wrap it up to this session, I just wanted to ask, so, as the latest update or new guide which we have in the wiki is about the VFT standard.
There's a full guide explaining how to set it up, what is it for.
But I was wondering if you can maybe share a few words about that as it is the latest updated guide in the wiki.
share a few words about that as it is the latest updated guide in the beginning.
Yeah, just something new, something fresh and more
detailed explained, I would say we're going to have in the near future,
we're going to have the significant improvement to the sales, helping you to
build much more user friendlyfriendly and web tool-like interfaces so the whole our SDK
gonna build your SDK automatically as usual but it will make it like much more easier to use for
your customers not only for you so I think that's it and we're gonna have uh also updates even on these updated articles about the vft
just because the vft actually is kind of simple standard it's total copy of the year c20 and
everybody is familiar with the what is fundable tokens and i'm not sure there's something to add
all right and one more question are there any updates you would like to share what is the
development team working on currently or some news something you are excited for
is there anything you would like to share with the community i would like to share my worries
because on our sessions we like usually share some insights from the core development, but never you share some updates for us.
So, for example, if you're planning some new dev time or we are planning to have a real-life AMA session without some exact topic with the community or something.
without some exact topic with the community or something.
But yeah, speaking of our insights, I'm going to share this time,
but I'm going to consider it in the future.
Yeah.
I think there is a lot of things happening during the summer
for not only for us, but also for each, like,
like at least medium sized protocol just because everyone wants to
wants to release something after after the summer so and we also cooked and baked a couple of things
I'm not sure if it's okay to put this or with exact points what did we do but um there is for example there is our testnet stage of the bridge and it's I think
coming to the end uh eventually it's gonna end I I think it will be kind of pretty soon and it's
super nice to have the mainnet bridge uh there is also gear exhibit was developing already for
more than a year uh and it's worth mentioning just mentioning just, uh, that it's like, you know, it's kind of
super complex and super, um, tech project, um, that was built almost from scratch by
us and it's nice to have all things from the security part covered and we do cook
it, we do cook it every day and I think
I think that's all all the other things is up to you it's up to our listeners actually
I just shared already a lot
yeah to follow up this session is technical so for community and ecosystem updates you guys would
have to join other x spaces i don't want to interfere but if anyone from the listeners
would have some question for you for the for you guys uh now would be the time to raise your hand
i think we still have uh maybe for one two time. So if anyone would have a question, if not, thanks a lot, guys.
Yes, maybe next time we could do full AMA with questions from the community only
to kind of get back in what we started before.
But we will see.
Maybe not.
Maybe yes.
We never know.
But thanks, Vadim. Thanks, Dima, for coming
today.
Yeah, thanks.
Thank you for hosting us.
You just inspired Vadim so much.
He just did drop
the mic so many times
during this dev time.
So I think it's worth mentioning, it was like you know
some approvals from our side to you. I think if someone evolved from this X-Basis it's definitely
Badjian. Like a foolish speaker like so I think you did pretty well job actually
all right so uh with any other prolonging thanks everyone who joined today thanks you guys uh
thank you guys again and see you in next month yeah see you next time bye bye bye see you
Host
Vara Network
from
Vara Network
