In the last couple of years the entire framework spanning across something like 30 repositories from chain integration to build tools was developed by 8–10 software engineers, supported by marketing, HR and operations colleagues. Together with our funding partners ICF, Neutron, AADAO and Axelar, we were able to secure the funding for H1 2025. Thank you for making that possible! This bought everyone involved valuable time to adapt to what is coming.

In the meantime, Interchain Labs decided to not host a CosmWasm maintenance team in-house. However, they collaborate with Neutron by funding CosmWasm maintenance efforts embedded into the Neutron team. Also Thorchain and Axelar signaled interest to contribute to CosmWasm’s ongoing maintenance.

From July onwards, the Confio team members Darek and Pino will be the first developers working on CosmWasm full time. Darek was focussed on MultiTest before and Pino is the maintaner of wasmd. They used the last couple of weeks collaborating with the rest of the team to gain knowledge of the entire stack. Darek and Pino become owners of the CosmWasm GitHub organization. The primary point of contact to them is the existing CosmWasm Telegram channel which is open for messaging again.

To reduce the maintenance burden for Darek and Pino, the Sylvia framework will be moved out of the CosmWasm organisation and is continued by the original author Bart as well as the long time Sylvia maintainer Jan.

Security wise, the Cosmos bug bounty program on HackerOne keeps the CosmWasm scope such that security issues can be reported there. The security contact at Confio will be removed.

What’s next for CosmWasm is not for Confio to decide anymore. Users need to come together and collaborate on priorities, roadmaps and funding. There are many things that could be done or would be great to have. But keeping up with Cosmos SDK and IBC updates, following the evolving Wasm standard as well as adapting to the Wasmer Singlepass license change are certainly on the agenda.

Over the years, many people suggested to release CosmWasm under a restrictive license. But this is something we never agreed with. Not only would it be a legal nightmare, harm the network effects and risk ICF funding. It would also be against the spirit of decentralized user owned systems and free innovation. Defending the Apache 2 license was a tool to create a meaningful piece of software that has the potential to outlive its original creators.

Confio brough CosmWasm into existence and made it grow 6 years old. As it moves forward past its 3.0 release, we’re proud of what’s been built — and excited to see where the community takes it next.

Confio ends CosmWasm maintenance was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

However, as we look toward 2025, it’s time to address the future of CosmWasm and Confio’s role in its ongoing development.

The roadmap overview

In Q4 of 2024, we spent some time planning what items to include in the 2025 roadmap, focusing on the direction of Cosmos, blockchain trends, and CosmWasm users’ needs — both recognized on our public communication channels and those we know from directly speaking to people we know or met at various events. We ended up deciding that in 2025, we want to deliver the following:

1. Eureka (IBCv2) integration
2. ICS20v2 implementation
3. Feegrant support

Eureka is the uncontested top priority for this year. This is a complete refinement of how inter-blockchain communication is handled, simplifying it a lot. As CosmWasm focusses on being IBC-friendly, we need to make Eureka-enabled CosmWasm smart contracts as easy to build as possible for both standard and custom protocols. This feature involves a lot of work and it will take most of our resources in first half of 2025. We would need to implement the entry points for incoming Eureka messages and provide a robust API for sending messages to other chains with this protocol. We would also provide the bindings to the most common protocols over Eureka — for example, the ICS20 token transfer protocol.

We would also like to add two smaller features in addition to that. ICS20 has its 2nd specification iteration with some additional features, and we would like to expose its functionality. That is a simple quality of life improvement.

The other small feature we plan is support for feegrant. Currently, we are able to send feegrant messages only with the Any messages feature, allowing the user to manually protobuf serialize them. That is annoying, and as feegrant is part of the Cosmos core, we want to expose the feegrant messages via a dedicated binding.

On top of that, we want to take a closer look at feegrant types. With built-in types, we cannot really create useful feegrant to cover smart contract execution costs. The best filter we can provide for now is covering the cost of executing any CosmWasm message by a particular address. Such constraints are typically not enough. We want to implement additional fee grant types that will allow the creation of an allowance for executing a particular message on a given contract.

Stretch goals

There are obviously more things that we would like to include in the future CosmWasm releases. In particular, we are looking at:

• ZKP verification
• Scheduler/Cron utility
• IBC aware common deployment tool

ZKP has been a hot topic in blockchain ecosystem for a long time. Verifying proofs directly in smart contracts is very useful for building ZKP-base applications. It is already possible, as CosmWasm smart contracts are written in Rust, developers can easily use any ZKP dependency that would help them to implement proof verification. There are two downsides to that. First of all — those dependencies would need to be included in the final Wasm binary, which would increase their size, often significantly. It may by itself make it impossible to deploy the contract on the chain if it exceeds the size limit. On top of that, ZKP verification tends to be computationally heavy, which would also affect its execution cost. We believe that by moving it higher into the stack — above the virtual machine, the gas overhead would be lower.

Unfortunately ZKP verification is a complex topic — it requires refinement of the type of cryptography we actually need to implement, what the API should look like, and it will probably raise more questions than we have so far thought of. Still depending on events, we might decide to push towards ZKP verification to some extent.

Another utility we plan is the generalized Scheduler/Cron utility. This is already implemented on several chains, which proves there is a need for such a solution. The idea is to allow executing smart contracts in a scheduled way — either as one-shot delayed execution, or periodic execution of some functionality. This question is often addressed within the context of specific chain design assumptions. However, we aim to develop a general implementation that provides an API-based solution to tackle this issue across various designs. With our feegrant support design, we may also have a universal fallback solution to rely on.

Finally, a common need expressed by CosmWasm developers is the creation of a unified approach to smart contract deployment. Currently, each chain tends to have its own tooling and workflows for deploying smart contracts. While this approach works well for applications deployed on a single chain, it becomes complex when deploying an IBC application across multiple chains as a unified solution. We would like to provide a solution that would ease such cases, simplifying deployment and initialization of cross-chain applications. Such tooling, however, might require more work than we can do to reach the feature-complete state. While we cannot make any promises, we can consider it as a stretch goal.

Maintenance Work

Feature development is pointless if the software itself is not well-maintained. For the first half of the year we will provide the highest standards of CW maintenance. Our highest priority is addressing any ongoing security reports promptly. Additionally, we are committed to making sure that the recently rebuilt documentation remains comprehensive and up to date.

We will also keep maintaining Tracing — the CosmWasm tool for smart contracts on-chain debugging, collecting and visualizing execution information. Up until recently, the only chain enabled with Tracing was Neutron, now Cosmos Hub is joining the party. It will be enabled with Tracing soon and we will work on improving the way the collected information is presented to the final user.

Out of Scope

One feature deserves honorable mention, even though it did not make it into the final scope for 2025: the linear runtime. We recognize that actor model-based design sometimes makes it challenging to implement more complex workflows. We have an idea on how to hide the actor model and allow the smart contract builder not to worry about it. Instead of designing smart contracts as a stack of execute-reply ping pong, it would be possible to call the contract directly from another contract execution — the same way we do with queries, interrupting the execution process. The actor model would not go anywhere — the whole contract state would be frozen, and execution would be restored as the implementation of reply execution.

We find the feature a very helpful quality of life improvement, making the learning curve easier. Unfortunately, it is too complex for us to approach in the first half of the 2025.

Funding Confio for CW development

Due to ICF strategy changes, the foundation has decided to discontinue the funding for CosmWasm development in 2025. They will continue to support day-to-day CosmWasm development in January and February and basic security support funding will be extended until the end of June. Additionally, ICF will fully fund implementation of Eureka. As the years of cooperation with ICF end, we want to say thank to the ICF for all their contributions to the ecosystem, and CosmWasm in particular.

We would also like to express our gratitude to Neutron and Cosmos Hub (through AADAO) who have decided to support us significantly, ensuring we will be able to continue our work on CosmWasm for the first half of 2025.

What about the future?

While the first half of 2025 brings good news, it is followed by an uncomfortable announcement for the second half: Confio’s maintenance of CosmWasm will end after June 2025. Due to recent developments, including the ICF’s strategic shift, we are unable to provide the level of development we aspire to. Rather than deliver a substandard product, we have made the difficult decision to conclude our maintenance. That said, we remain committed to delivering the best value we can until the end of June.

This raises the question: what happens after June? CosmWasm is an open-source project licensed under Apache 2. Confio is historically the only long-term maintainers group, but it doesn’t need to be that way. We are looking forward for potential development paths for this project, which may or may not involve people working on it so far.

What do we do for CosmWasm in 2025 was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we announced the purchase of 25% of Confio shares by Neutron last December, everything felt done. All parties were on the same page and we wanted to use the opportunity to get in an additional shareholder who deeply cares about Confio’s work and destiny.

However, it turned out the execution was not as straightforward as anticipated. Taxation questions, token valuation, as well as the complications around a multi-level shareholder structure in an international context delayed things for multiple months. Over time, circumstances and motivations changed. In hindsight, this is a good thing as we realized that we can collaborate well without being shareholders. A partnership built on trust, meaningful conversations and appreciation for each other’s work emerged. As a result, Simon from Confio and Avril from Neutron agreed on July 11th to not execute the planned share deal.

Looking ahead

Co-Founder and long-time CosmWasm maintainer Simon Warta remains committed to permanent leadership and development of the company.

Instead of looking for other buyers or investors, the founding team is on a path toward self-ownership for Confio. The company should exist in its own right, independent of who founded it originally. We want corporate governance to be decoupled from economic ownership, allowing profits to remain within the company. Following famous examples like Bosch or Patagonia, Confio aims to be self-owned and not for sale. This will be a multi-year endeavour. The first step has been completed by adjusting the articles of the company as well as an initial buyback of 13 % of the GmbH shares.

So, whilst we may not become joint shareholders, Confio and Neutron share a commitment to continue working together on exciting projects such as CosmWasm and the tooling ecosystem around it.

Confio remains in the hands of its founders and aims for self-ownership was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Confio, it’s not just about the code — it’s about the people behind it. We believe every journey adds value to our team, and today we’re spotlighting Tomek, one of our talented developers.

His journey from traditional software engineering to innovative blockchain projects shows his passion for pushing boundaries. Let’s hear about his story and find out what makes working at Confio so unique.

From Telecom Towers to Rust Mastery

Tomek began his career working in the telecommunications industry, starting at Nokia as a software integration engineer. “I was knee-deep in massive codebases, dealing with high-latency networking challenges,” he recalls. Later, he transitioned to a software engineer role, working on 4G networks before moving on to help develop a 5G cloud-based core network. During this time, Tomek discovered Rust, a programming language that quickly became a cornerstone of his skillset.

Before joining Confio, Tomek worked at a startup, where he had the chance to build a core library for a distributed storage system from scratch — his first full project in Rust. “That kind of involvement from day one is rare,” Tomek explains. This hands-on experience set him up for his next big adventure: Web3.

Diving Into Web3: Innovation Meets Opportunity

So why make the leap to Web3? For Tomek, it’s all about the potential. “Web3 is like the Wild West of tech. There’s so much to explore, and we’re shaping the landscape together,” he says. The potential of blockchain technology excited him, and he was drawn to the opportunity to contribute to groundbreaking solutions. His advice for anyone considering a similar move?

“Embrace the unknown and dive in — there’s a lot to learn, and even more to build.”

Life at Confio: More Than Just Code

For Tomek, what makes Confio stand out isn’t just the tech but the team. “At Confio, ‘trust’ is more than a word — it’s how we work every day,” he shares. “Whether it’s developing code, brainstorming new ideas, or improving existing solutions, every team member’s input is valued.”

“We’re small but mighty, and every person has a real impact on our success.”

One project that Tomek has been particularly proud of is Sylvia, where he worked on improving the user interface and adding new features. “Improving the UI and adding new features was rewarding, but the real game-changer was user feedback. It’s one thing to code — it’s another to see how people interact with it.”

Confio isn’t just about building top-tier tech; it’s about building each other up.

“We’re a tight-knit team where everyone plays a big role,” Tomek says. Trust and communication are foundational, especially in a remote-first setup. “While Slack and Zoom keep the team connected, it’s the in-person meetups at events like Devmos and AwesomWasm Hackathon that forge stronger bonds.”

Advice for Future Confio Developers

“If you’re thinking about joining Confio, go for it!” Tomek encourages. “The interview process is friendly and focused on finding a mutual fit. While having experience in Rust or Go is helpful, you don’t need to be a Web3 expert to succeed. If you’re curious and eager to learn, you’ll do great,” — Tomek assures.

As Tomek reflects on his journey, it’s clear he’s found a strong fit at Confio.“It’s about trust, teamwork, and the excitement of what’s next in Web3. I’m thrilled to be part of a team that’s driving meaningful innovation, and I can’t wait to see where we go from here.”

Don’t miss out on the next installment of our Confio Series — where we’ll dive into more stories from the frontlines of Web3. Until then, stay sharp and code on!

Join Our Community

Twitter | Website | LinkedIn

Confio Developer Spotlight: Meet Tomek — From Telecom to Web3 Innovator was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

This release does not introduce any new major features but rather improvements in the API.

What’s new in Sylvia 1.2.1

Refactoring Entry Points in the Contract Definition

In the recent release, the handling of generics in the entry_points macro underwent a refactoring to simplify and streamline the attribute syntax.

Previously, the entry_points macro required the user to explicitly specify concrete types used in place of generic custom types with the
, custom(msg=.., query=..) parameter. This caused redundancy as the same types had to be passed to generics<...> parameter.

Since version 1.2.0, Sylvia can deduce which concrete type passed to the generics<..> parameter is a custom type and the , custom() parameter is deprecated.

-#[entry_points(generics<Empty, Empty>, custom(msg=Empty, query=Empty))]
+#[entry_points(generics<Empty, Empty>)]
#[contract]
#[sv::custom(msg=E, query=Q)]
impl<E, Q> Contract<E, Q>
where
    E: CustomMsg + 'static,
    Q: CustomQuery + 'static,
{
}

Emit error if contract macro is above entry_points

Because the contract macro removes all of the Sylvia attributes, it should be placed below the entry_points macro so that the contract macro is called last.

Unfortunately, the compiler errors were not very helpful, so we decided to detect the wrong order of the macros and provide a hint leading directly to the problem:

error: Missing instantiation message.

         = note: `sylvia::entry_points` requires exactly one method marked with `#[sv::msg(instantiation)]` attribute.
         = note: Make sure you implemented the `entry_points` macro above the `contract` macro.

  --> tests/ui/macros/entry_points.rs:69:5
   |
69 |     #[entry_points]
   |     ^^^^^^^^^^^^^^^
   |
   = note: this error originates in the attribute macro `entry_points` (in Nightly builds, run with -Z macro-backtrace for more info)

Add CustomMsg and CustomQuery to ContractApi

Although the ContractApi is mainly intended for use by Sylvia macros, users can now access custom types defined on the contract through it:

// Generated implementation
impl sylvia::types::ContractApi for Contract {
    ...
    type CustomMsg = SvCustomMsg;
    type CustomQuery = SvCustomQuery;
}
// Usage of assigned types
let _: <Contract as ContractApi>::CustomMsg = SvCustomMsg {};
let _: <Contract as ContractApi>::CustomQuery = SvCustomQuery {};

Fix: Forward attributes to struct fields

Forwarding attributes to message fields worked for the enum messages like ExecMsg or QueryMsg but not for the InstantiateMsg and MigrateMsg.
Since 1.2.1 below is possible:

#[sv::msg(instantiate)]
pub fn instantiate(
    &self,
    _ctx: InstantiateCtx,
    #[serde(default)] _desc: String,No
) -> StdResult<Response> {
    Ok(Response::new())
}

The #[serde(default)] attribute would be forwarded to the structure field generated out of the _desc argument:

pub struct InstantiateMsg {
    #[serde(default)]
    pub _desc: String,
}

Other changes

Deprecate InterfaceApi in favor of InterfaceMessagesApi

Since 2.0.0, the InterfaceApi will be removed from Sylvia.
The generated InterfaceMessagesApi serves the same purpose, but instead of containing all of the generics defined on the interface it’s generic over the contract type.

// Construct using dynamic dispatch
let msg = <dyn Interface<
    ExecC = SvCustomMsg,
    QueryC = SvCustomQuery,
    Error = (),
> as sv::InterfaceMessagesApi>::Query::admin_list();

// Construct using contract type
let _ =
    <Contract<SvCustomMsg, SvCustomQuery> as sv::InterfaceMessagesApi>::Query::admin_list();

Update examples to use generic custom messages and queries

Making contracts and interfaces use generic custom types is a good way to give other users the flexibility to reuse your code. The Sylvia examples were updated to showcase this.

Summary

The 1.2.1 release brings multiple minor improvements that set a good direction for the development of the framework.

It is also preceded by work on new documentation that we will be very happy to share with you soon!

With this release we had to yank the 1.2.0 as it was a non-semver complaint due to the removal of support for , custom() in the entry_points macro and removal of the InterfaceApi.
The 1.2.1 is compatible with the previous version.

We are very excited to continue working on the Sylvia framework. Stay tuned, as future versions will include features such as semantic support for reply, migrate, and IBC.

You can learn about the changes in the CHANGELOG and the MIGRATING.

Sylvia 1.2.1 was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every year, our motley crew at Confio ditches the digital world for a few glorious days of real-life bonding. In the past, we’ve hit up sunny Malaga and picturesque Porto. This year, we set our sights on the charming streets of Ljubljana, Slovenia. Spoiler alert: It was epic.

The Magical (But Not Really) World of Retreat Planning

Company retreats can be great fun — you finally get to meet and know the whole person, not just that disembodied head you see on Zoom. And if it all goes smoothly, then that is because behind the scenes, in the months leading up to the retreat, a lot of hard work takes place.

Our team, representing 10 nationalities, is distributed over 8 countries, and finding a location that was (reasonably) easily accessible by train & plane is crucial. Endless research into travel and accommodation options, as well as our desire to find somewhere with great outdoor activities — we spend enough time indoors at our desks as it is — led us to choose Slovenia.

As the sole, annual, opportunity for all the team to meet, there is a lot of excitement and expectation, and it is, frankly speaking, certainly ambitious/a challenge to try meet those expectations in four days. The list of ideas is quite broad, and the activities we end up organizing depend very much on the actual meeting place we pick as a destination.

For us, it started with deciding on the purpose of the retreat, which is all about connecting and getting to know one another (and ourselves) better. We wanted to organize activities to encourage team spirit and bonding that we cannot do online, and a balance between indoor and outdoor activities, soft skills and technical training, and some free time to explore the city or to go and check out the independent coffee shops with colleagues — this last point is fundamental, it is something most of us have in common in our team: our weakness for a good cup of specialty coffee 😉.

We prefer to work with local facilitators and suppliers, when possible, as a way of supporting local businesses in those places we visit. This time, we opted for a Lego Serious Play workshop focusing on improving teamwork & collaboration, and a more technical workshop on Security. The outdoor day was spent in Triglav National Park hiking, white water rafting and boating on Lake Bled. The sun was not shining on our day outdoors, but the landscape was so breathtaking that the weather mattered little.

We work for the people, so the well-being of “Confians” is at the core: it is not just about choosing the most appropriate workshops or a well-located hotel to facilitate logistics, but also about ensuring that we eat well and get enough rest during those days away. Carefully choosing the places to eat and knowing the food preferences of the team play an important role. Sometimes, the list of requirements cannot be fully met, but we try our best, and this is much appreciated by the team. We have people from many different cultures working for Confio, and we always joke about the eating times — central Europeans may start dining at 6 pm when southern Europeans are still digesting their lunch 😀; so we must meet halfway and find suitable eating times for the team. And this is just another challenge of working in a multicultural environment: the concept of “meeting halfway” is pretty much extended in Confio, and we can feel proud of having embraced it wonderfully.

And after all these months of research and planning — what were the outcomes, and why was it worth it?

Cohesion, Connection, Belonging

Our team had changed since our last retreat, half of us had not yet met in person and meeting in Ljubljana offered the opportunity for team members to build relationships, get to know one another and share experiences. For our newest member of the team, it was a great way to onboard and strengthen the sense of connection, and be part of the Confio team. Meeting in real life fosters a sense of community and belonging in a way that is not possible online.

Cross-Team Understanding & Collaboration

We’re not just a bunch of developers at Confio. Meeting in person helped us understand each other’s roles and challenges, fostering a spirit of collaboration. It’s amazing what a difference it makes to discuss projects while hiking a mountain or sharing a meal.

Serendipity

It is the casual conversation you have with a colleague whilst hiking in the Triglav mountains or walking to a restaurant that sparks new ideas. Overhearing a conversation with those around you at lunch can spark unexpected new ideas and plant the seeds for upcoming projects. During our most recent retreat, there were a couple of these moments, and because everyone was together, it was easy to quickly decide to progress with the new ideas that came out of a casual conversation walking along the Ljubljanica River ice cream in hand.

Nuance & Depth

Retreats allow for more nuance and depth in communication, which can be lacking during Zoom calls, when reading someone’s mood or body language isn’t always easy. Despite the fact that we invest much time and effort in ameliorating the way in which we communicate digitally, meeting in person is highly valuable, and we know these moments together can take us further.

Magic

Our post-retreat feedback was a treasure trove of highlights and takeaways. Everyone had different moments that stood out, proving that while remote work has its perks, there’s something truly magical about meeting in person.

How valuable has the retreat been for you, and why?

David Komer, Tooling Dev: “This experience was incredibly enriching because it allowed us to engage in meaningful interactions and share experiences outside the usual work environment. The bottom-line is that it was really, really cool to meet everyone and get a sense that this is a group that’s full of integrity, honesty, acceptance, and sensitivity. Pretty rare combo!”

Blanka Trojan, Finance Manager: “The moments we shared, such as walking and eating together, were what really helped me get to know my colleagues better. These informal interactions allowed us to connect on a more personal level and appreciate each other’s personalities and preferences. These moments remind us that behind our screens, we are collaborating with real, wonderful people. I think the retreat has fostered a more harmonious and productive work environment.”

Chris Otter, Rust Dev: “The retreat is incredibly valuable to me because it’s one of the few opportunities to get to know everybody on a more personal level with less focus on work. It was especially great for me to meet the people I hadn’t met in person yet before that. It’s always a bit of a special moment when you meet someone you’ve only seen on screen in real life. I also loved the rafting and hiking! Having these kinds of shared experiences is very valuable, as it binds you together as a team.”

What was the highlight of the Ljubljana retreat for you?

Chris Otter, Rust Dev: “The rafting experience. It was very engaging because everybody had to stay in sync, but also some pauses in between where we could chat and make jokes. Also, the nature was just beautiful.”

David Komer, Tooling Dev: “The day out was probably one of the most memorable experiences of my life:
- First time seeing a real mountain
- First-time whitewater rafting (outside of a school trip in high school, which was different.)
- The overall experience in nature.
- Opportunity to connect with the team outside of work domains.”

What helped you to get to know your colleagues better?

Chris Otter, Rust Dev: “The free time where we could chat. The Tuesday workshop also helped with that since we were talking about struggles with our groups.”

David Komer, Tooling Dev: “Their attitudes. The same exact circumstances with different people wouldn’t have resulted in the same degree of openness and positive curiosity/sharing. Really great people.”

Aumetra Weisman, Software Dev: “Just being together, spending time during the activities we had together, and talking. There isn’t really anything specifically I’d highlight here; it’s just the possibility of just coming together and talking.”

Tomek Kulik, Rust Library Dev: “Time spent at tables together during dinners gave us a chance to get to know each other better and to realize we are all people, even though we work remotely.”

And there you have it! Our Ljubljana retreat was a whirlwind of connection, collaboration, and, yes, a lot of coffee. Can’t wait to see where our next adventure takes us!

From Zoom to Slovenia: Behind the Scenes of Our Annual Company Getaway was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

The third floor was like the calm before a storm. That’s what I thought when I caught a glimpse of it on my way up. It was the place where the hacking would happen, but there wasn’t anyone there to be found yet. The way the tables were arranged, however, hinted at something inspiring: the challenges that would be faced there would be tackled with team effort.

If the third floor had been the hacking part of the AwesomWasm Hackathon, the fourth floor had to be the awesome. It was readily apparent that this was a place optimized for communication. The projector took the spotlight of the room as soon as you arrived, with dozens and dozens of chairs in front of it that would soon be filled with hackers, whereas the rest of the floor was comprised of stools and tall tables, refrigerators with drinks, comfy couches, and even some sleeping tents if you cared to look on the most isolated section.

Right when the room was boiling with people, and a few shy glass bottle clinks could be heard — interweaving with the continuous laughs and chatter — Simon Warta and Vicktoria Klich kickstarted the event. The applause they received segued into three more presentations: a look at the future of Wasm by Ethan Frey and the introduction of both Kujira and Neutron’s challenge tracks by Hans and Andrei Zavgorodnii, respectively. The first two workshops took place just after that, in which Serdar Turkmenafsar and Amit Prasad gave their all to spark that creativity the hackers would need to succeed. Serdar — from the Interchain Foundation — showcased the use of Interchaintest, which helps make the testing of IBC-Enabled CosmWasm apps more streamlined; whereas Amit — from Entropic Labs and himself a judge of the hackathon — provided a masterclass on building DeFI. As soon as the clock ticked past noon, the following 48 hours of non-stop innovation and fun started.

During the rest of the event you could definitely see a hurricane of ideas swarming the venue. Either if you went to grab a bite or have a drink; either if you had some pretzels for breakfast or some pizza for dinner; either if you went for a smoke, out on the balconies, or to play some foosball — you could really feel the gears turning. As ideas began to settle, tamed by passion and hard work, hackers were happy to share how their little projects were doing — on the little downtime they could afford — proud and giddy as parents witnessing their baby’s first footsteps.

Three more workshops took the spotlight on the fourth floor at later times. First, Ivan Gavran demoed the usage of Quint for practical formal methods, and it was as enlivening as the speaker’s own attitude. Then, while Adair and Robin — who ran their own bounty — showcased Abstract Money’s capabilities for building an interchain mail service, Gjermund Garaba shared some well-received awesome use cases for CosmWasm + IBC.

Fourteen projects were submitted to the DoraHacks platform for judging before the countdown ended on the third day and were then given a presentation. It became immediately obvious that each piece of work was an honest reflection of its builders. AutoKujira showed the ambition to look at what’s working and take it to the next level. An emotional and artsy way of living was unmistakable when checking out CosmonautJukeBox. The presentation of Telegram Connect CosmWasm conceptualized the determination of trusting well-known tools and integrating them together. And a witty and playful attitude was the whole raison d’être of Rugs and Candles.

All of the above are just some examples of what transpired during the two hours that were dedicated to the demos when also some exchanges were made between the speakers and the audience: “Thank you, that is so awesome!” or “This hackathon has made me a better person” were some of the compliments that could be heard among the crowd. The joy continued after the judges’ deliberation and well into the winners’ announcement, which was celebrated with faces of a job well done.

Simon Warta directed the closing ceremony by thanking the always helpful organizers and emphasizing the always welcoming Berlin, the city of CosmWasm, that saw it be born and has continued to nurture it with love and code.

All of the recordings will be shared here. You can see the winners here and do not hesitate to see the other projects here.

Now I know what kinds of projects could be born here, what kinds of people could be met, and what kinds of vibes filled the air.

If you want to know them, too, stay tuned for the next one!

AwesomWasm Hackathon 2024: Code is in the air was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro

In the fast-paced world of DeFi, efficiency is paramount. Every transaction executed on a blockchain incurs gas fees, and as the popularity of DeFi platforms grows, so does the demand for cost-effective solutions. Contract pinning, a lesser-known optimization technique, has emerged as a powerful tool to reduce gas usage and improve transaction speed. This case study explores how CosmWasm contract pinning was leveraged to optimize gas usage on Astroport, a leading DEX built on the Injective, Neutron, Osmosis, Sei, and Terra blockchain.

Contract Pinning Mechanics Overview

Contract pinning, a pivotal feature of the CosmWasm virtual machine, expedites the initiation of previously stored compiled contract codes by accessing a dedicated in-memory cache. This process significantly reduces startup time to approximately 45µs, compared to the 1.5ms required when loading from disk, marking a substantial 33x acceleration. Unlike the node-specific Least Recently Used (LRU) memory cache, contract pinning ensures uniform performance enhancements across the network, guaranteeing a streamlined experience for users. Notably, this efficiency allows wasmd to levy discounted gas costs, presenting a compelling incentive for utilizing this innovative functionality.

Problem Statement

Astroport was experiencing rising gas fees due to the increased price of the NTRN token. Complex transactions on the platform were becoming prohibitively expensive for users.

Neutron Governance Proposal

To address the rising gas fees, the Astroport team proposed using contract pinning for the most frequently used smart contracts on their platform. However, implementing contract pinning required a governance vote on the Neutron blockchain, so proposal A-31 was submitted and passed.

Result

Since the proposal passed, contract pinning was successfully implemented immediately. The Astroport team collected on-chain data to analyze its impact on gas usage, as shown below.

The analysis revealed significant improvements, with gas usage decreasing by 15% to 50% across the pinned contracts.

However, one anomaly was detected: a contract showing increased gas usage. Further analysis is underway to better understand this anomaly.

Best Practices

For further information on contract pinning and its implementation, refer to the documentation provided by the CosmWasm project: Documentation Link

Conclusion

Contract pinning emerges as a simple yet powerful tool to optimize gas usage on blockchain platforms. By caching frequently used smart contracts, developers can achieve up to a 2x reduction in gas costs on the pinned contracts, improving efficiency and cost-effectiveness.

Neutron’s active involvement as a CosmWasm Subscriber allowed for a direct communication channel with Confio, enabling timely issue resolution and proactive support.

We thank the Neutron team for providing valuable insights and collaboration throughout the contract pinning process. Additionally, we would like to express our special thanks to the P2P team for their contributions to data analysis through their Lambda analytics platform. This is the link to the early alpha version of the P2P Lambda tool a link to the early alpha version of the P2P Lambda tool we can refer to https://lambda-demo.p2p.org/.

For more information on CosmWasm Subscription, please visit here.

Neutron Case Study: Optimizing Gas Usage with Contract Pinning was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

This text provides an explanation for the decision of reverting support for generic traits in Sylvia and focusing on associated types instead. Along with the explanation, a method for handling generic interfaces in a different way is described.

The article is written based on CosmWasm v2.0.0 and Sylvia v1.0.0.

Why are associated types sufficient for contract development?

The common scenario for using associated types in Sylvia interfaces is shown in the following example:

pub mod interface {
    use cosmwasm_std::{Response, StdError, StdResult};
    use sylvia::types::{CustomMsg, CustomQuery, ExecCtx, QueryCtx};

    /// Custom query method's response
    #[cosmwasm_schema::cw_serde]
    pub struct ResponseStruct(pub u32);

    #[sylvia::interface]
    pub trait Interface {
        type ExecC: CustomMsg;
        type QueryC: CustomQuery + 'static;
        type Error: From<StdError>;
        type CustomInput: CustomMsg;

        #[sv::msg(exec)]
        fn execute_method(
            &self,
            ctx: ExecCtx<Self::QueryC>,
            input: Self::CustomInput,
        ) -> Result<Response<Self::ExecC>, Self::Error>;

        #[sv::msg(query)]
        fn query_method(
            &self,
            ctx: QueryCtx<Self::QueryC>,
            input: Self::CustomInput,
        ) -> StdResult<ResponseStruct>;
    }
}

The following associated types were added in the example above:

1. ExecC — Represents the type forwarded to the CosmWasm’s Response<T> type. Each contract needs to provide the concrete T. By introducing ExecC type in the interface it is possible to implement that interface on many different contracts — independently from the Response’s custom type they use.
2. QueryC — Analogous case to the one above, but related to the Context type that is one of the arguments for the messages.
3. Error — Every contract needs to specify a concrete error type. It should be possible for the interface above to be implemented on various contracts, no matter what their error types are.
4. CustomInput — It is also possible to use associated types as placeholders for the types used in the methods.

The ExecC, QueryC, and Error types are special for Sylvia. These three types are treated differently and are provided solely for the purposes specified above.

An example implementation of the above interface for a contract:

use sylvia::{contract, entry_points};
use cosmwasm_std::{Empty, Response, StdError, StdResult};
use sylvia::types::{ExecCtx, InstantiateCtx, QueryCtx};

/// Some custom input type
#[cosmwasm_schema::cw_serde]
pub struct ContractInput(u32);
impl cosmwasm_std::CustomMsg for ContractInput {}

/// Custom context's Query type
#[cosmwasm_schema::cw_serde]
pub struct ContractQuery;
impl cosmwasm_std::CustomQuery for ContractQuery {}

/// Simple stateless contract type
pub struct Contract;

impl interface::Interface for Contract {
    type ExecC = Empty;
    type QueryC = ContractQuery;
    type Error = StdError;

    type CustomInput = ContractInput;

    fn execute_method(
        &self,
        _ctx: ExecCtx<Self::QueryC>,
        _input: Self::CustomInput,
    ) -> Result<Response, Self::Error> {
        // [...]
        Ok(Response::new())
    }

    fn query_method(
        &self,
        _ctx: QueryCtx<Self::QueryC>,
        _input: Self::CustomInput,
    ) -> StdResult<interface::ResponseStruct> {
        // [...]
        Ok(interface::ResponseStruct(0))
    }
}

#[cfg_attr(not(feature = "library"), entry_points)]
#[contract]
#[sv::messages(interface<ContractInput>)]
#[sv::custom(query=ContractQuery)]
impl Contract {
    pub fn new() -> Self {
        Self
    }

    #[sv::msg(instantiate)]
    pub fn instantiate(&self, _ctx: InstantiateCtx<ContractQuery>) -> StdResult<Response> {
        Ok(Response::new())
    }
}

The #[sv::messages(interface<ContractInput>)] has generic brackets with only one type specified. Developers need to specify all associated types beyond ExecC, QueryC, and Error.

What if I need to implement a generic interface?

To understand the reasoning behind reverting support for generic traits, one must consider the constraints of procedural macros and the CosmWasm environment. For the purpose of this article, a simple example is prepared. It demonstrates an interface defined in two different ways: using generic types and using associated types:

pub mod interface_generic {
    use cosmwasm_std::StdResult;
    use sylvia::types::{CustomMsg, QueryCtx};

    // #[sylvia::interface] - Sylvia does not support generic traits
    pub trait InterfaceGeneric<InputT, ResultT> 
        where
          InputT: CustomMsg,
          ResultT: CustomMsg {

        //   #[sv::msg(query)]- Sylvia does not support generic traits
        fn state_dependent_op(&self, ctx: QueryCtx, i: InputT)
          -> StdResult<ResultT>;
    }
}

pub mod interface_assoc {
    use cosmwasm_std::{StdError, StdResult};
    use sylvia::types::{CustomMsg, QueryCtx};

    #[sylvia::interface]
    pub trait InterfaceAssoc {
        type InputT: CustomMsg;
        type ResultT: CustomMsg;
        type Error: From<StdError>;

        #[sv::msg(query)]
        fn state_dependent_op(&self, ctx: QueryCtx, i: Self::InputT)
          -> StdResult<Self::ResultT>;
    }
}

Below are two contracts prepared for the interfaces described above. The first assumes that the contract type is not generic, while the second one utilizes generics:

use cw_storage_plus::Item;

pub struct Contract {
    state: Item<u32>,
}

pub struct ContractGeneric<T> {
    state: Item<u32>,
    _phantom: std::marker::PhantomData<T>,
}

The first approach is to implement InterfaceGeneric<InputT, ResultT> for the simple Contract type:

use sylvia::types::{CustomMsg, QueryCtx, StdResult};
use std::ops::Add;

impl<InputT> interface_generic::InterfaceGeneric<InputT, InputT> for Contract
where
    InputT: Add<Output = InputT> + CustomMsg + Clone,
{
    fn state_dependent_op(&self, ctx: QueryCtx, i: InputT) -> StdResult<InputT> {
        let mut result = i.clone();
        let upper_bound = self.state.load(ctx.deps.storage)?;
        for _ in 0..upper_bound {
            result = result + i.clone();
        }
        Ok(result)
    }
}

#[sylvia::contract]
#[sv::messages(interface_generic<bool> as InterfaceGenericBool)]
#[sv::messages(interface_generic<u8> as InterfaceGenericU8)]
#[sv::messages(interface_generic<u16> as InterfaceGenericU16)]
//    ...  etc. for all the types that should be implemented
//         for this contract.
// 
// In order to generate the dispatch method for each message type,
// Sylvia needs information about all interfaces implemented for
// a given contract. If an interface has generic or associated
// types, they have to be listed.
//
impl Contract {
  // [...]
}

Let’s analyze the above contract. The state_dependent_op adds the input to itself self.state times and returns the result. It is reasonable to use generic types for this interface in such a case.

There are two problems with that approach:

1. It’s hard to make the generic part of the interface truly generic in the contract implementation. Even though the produced messages are generic, once the code is compiled there are only concrete types in the contract’s binary code due to contract monomorphisation in the entry points. Sylvia cannot arbitrarily choose which types of generic messages should be deserialized.
2. Sylvia prevents collisions between method names for every interface implemented within a given contract. This decision aims to maintain the contract’s messages API flat. For example, an interface’s query message variants are added to the one set of all query variants in a given contract implementation. Specifically, developers cannot implement the same interface twice, even with different generics.

Let’s try to achieve a similar goal using ContractGeneric and InterfaceAssoc instead:

use cw_storage_plus::Item;
use sylvia::types::{CustomMsg, QueryCtx, StdResult};
use std::ops::Add;

impl<InputT> interface_assoc::InterfaceAssoc for ContractGeneric<InputT>
where
    InputT: Add<Output = InputT> + CustomMsg + Clone,
{
    type InputT = InputT;
    type ResultT = InputT;
    type Error = StdError;

    fn state_dependent_op(&self, ctx: QueryCtx, i: Self::InputT)
      -> StdResult<Self::ResultT> {
        let mut result = i.clone();
        let upper_bound = self.state.load(ctx.deps.storage)?;
        for _ in 0..upper_bound {
            result = result + i.clone();
        }
        Ok(result)
    }
}

#[cosmwasm_schema::cw_serde]
struct Operand(u32);
impl cosmwasm_std::CustomMsg for Operand {}
impl Add for Operand {
    type Output = Self;

    fn add(self, other: Self) -> Self {
        Self(self.0 + other.0)
    }
}

#[sylvia::contract]
#[sv::messages(interface_assoc<InputT, InputT>)]
#[cfg_attr(not(feature = "library"), sylvia::entry_points(generics<Operand>))]
impl<InputT> ContractGeneric<InputT>
where
    InputT: Add<Output = InputT> + CustomMsg + Clone,
{
    pub fn new() -> Self {
        Self {
            state: Item::<u32>::new("state"),
            _phantom: std::marker::PhantomData
        }
    }

    #[sv::msg(instantiate)]
    pub fn instantiate(&self, ctx: InstantiateCtx) -> StdResult<Response> {
        self.state.save(ctx.deps.storage, &0)?;
        Ok(Response::new())
    }
}

The very important thing to notice is the entry_points macro. Several entry point types are defined by the CosmWasm standard. Each contract's binary can export, at most, one method per entry point. There's no difference in Sylvia’s contracts. The problem occurs when there's a generic contract. To provide the compiled contract's binary with one method per entry point, developers need to decide which monomorphisation of the contract should be used for this purpose. In the code above, a new Operand struct is defined to be used for this contract.

Conclusion

Recently, Sylvia v1.0.0 was released. A lot of effort was put into forging all the ideas behind that tool into a stable library. During the dynamic development phase, a lot of ideas were tested. In the process, generic traits turned out to be troublesome in Sylvia’s contracts for the CosmWasm environment. If the two problems mentioned above are addressed, the generic interfaces could potentially be implemented in the future. In any case, most situations involving interfaces can (and should) be addressed using associated types.

Generics vs associated types in Sylvia traits design was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.

My recent journey to Seoul was a multifaceted adventure, driven by two primary goals: to expand the reach of CosmWasm and gather market insights for potential subscribers and to promote the upcoming AwesomWasm hackathon.

CosmWasm Families

I gained valuable insights from CosmWasm chains and projects, delving into their individual focuses, concerns, pain points, and future trajectories. Moreover, I received invaluable advice and feedback on our nascent business model, the CosmWasm Subscription plan, from experts within the community.

My Takeaway Around “Modular” Trend

In Seoul, the buzzwords “Modular” and “Real World Asset tokenization” dominated discussions. Many chains were either integrating multiple Virtual Machines (VMs) or planning to do so, showcasing a trend toward versatility and interoperability.

While several projects were leveraging both CosmWasm and Ethereum Virtual Machine (EVM), it was evident that Ethereum held sway in the “money-making” realm due to its larger market size and preference among venture capitalists. Despite CosmWasm’s technical superiority, there existed a disconnect with its commercial viability.

This experience prompted me to broaden my perspective beyond the Cosmos vs. Ethereum dichotomy. With the emergence of projects like Hyperlane and MilkyWay and the attention garnered by Initia and Mitosis, the boundaries between platforms have become increasingly blurred. Some individuals are shedding their exclusive focus on Cosmos, recognizing the need for a more inclusive approach. With this ongoing modular trend, I am curious to see how the CosmWasm ecosystem will expand with Inter-Blockchain Communication (IBC). Some concerns arise about the fragmentation of expertise and the ability to manage the complexities of hyper-interconnected systems by a non-tech person like myself.

These reflections led me to consider the implications for our CosmWasm Subscription service. With a diverse audience and varying needs among CosmWasm-integrated chains and projects, devising strategies for inclusivity, resource optimization, and scalability becomes imperative.

I do not have the answer now.

One thing remains certain: Confio remains committed to building the infrastructure for CosmWasm, adapting to the evolving currents of the blockchain landscape. Regardless of how the tides may shift, we are steadfast in our resolve to navigate these waters, persevering beneath the surface like we always have.

Promoting the Upcoming AwesomWasm Hackathon

After the success of last year’s CosmWasm hackathon, we’re organizing the second version, AwesomWasm hackathon this year, co-hosted with our Gold subscribers, Kujira and Neutron. A good opportunity to connect with industry veterans and CosmWasm experts, including Confio developers and representatives from Kujira and Neutron. During my time in Seoul, I aimed to promote our hackathon and attract more participants, encouraging interest from past attendees like Jesse from New Metric and Sooyoung and Yoonsu from DSRV.

Korean Corporates in the Blockchain Scene

I had the opportunity to connect with Korean corporations engaged in blockchain endeavors, such as Line and Neowiz, gaining valuable insights into their strategic approaches and future plans. Their distinctive strategies and actions are pretty different from most projects I’ve encountered in the ecosystem, showcasing the diversity within the CosmWasm audience and providing me with further insights.

Something More

Korean social media and news outlets were abuzz with excitement when Vitalik was sighted casually strolling through the streets and cafes in Korea during the event, embodying the image of a “billionaire engaging in everyday activities.”

The Near marketing team shared a tweet mentioning that Illia, co-founder of the Near blockchain, had his arm touched by Nvidia CEO Jensen Huang. This quickly transformed into a humorous meme during BuidlAsia, with many jokingly expressing a desire to experience the “touch of Illia,” leading to the creation of the “Touch me Illia X” account. Such incidents highlight the amusing and vibrant culture within the crypto community.

In short, my Seoul tip was more than just a conference visit. It was also a deeply personal journey of self-discovery and growth. As I reflect on the memories made and lessons learned, I am filled with a renewed sense of purpose and excitement for the road ahead.

BuidlAsia and EthSeoul 2024: A Journey of Reflection and Exploration was originally published in Confio on Medium, where people are continuing the conversation by highlighting and responding to this story.