Yral: Cleaning up canisters left over from previous per-user multi-subnet multi-canister architecture

Developers
33

We had 5 phases of major architecture changes:

  • single monolithic backend - motoko codebase here
  • multi-canister per user, single subnet - here
  • multi-canister per user, multi-subnet - here
  • creator dao’s where every user would get their own SNS backed token - here
  • microservice approach, specialized canisters holding multiple user data - here, specifically this commit onwards. I can see these 2 microservices here in these 2 commits

image
image1384×173 11.6 KB

image
image1337×110 8.09 KB

There are link to github commit ranges above because these are not individual changes but a group of changes made over a timeframe.

I’ve pointed you to the exact code timeframes. You’ll have to run them through the LLM yourself.

35

My bad. Just made it public

38

It’s not entirely unfair. It’s subjective, depending on how you look at it.

We didn’t “migrate the data” in July 2025. We started in July 2025, and made progress towards that AND a significant boatload of other endeavours.

Off the top of my head:

  • We launched native mobile apps, again, a FIRST in the ICP ecosystem and put our entire focus on shipping user facing features. We are currently the only SNS to have native mobile apps calling into ICP canisters on both the Play and App Store
  • We reached a million downloads on the Play Store
  • Made significant improvements to our app experience
  • Enabled AI chat on the app
  • Enabled Sora like AI videogen
  • Enabled monetization and in app payments
  • Iterating on p2p payments
  • Iterated on a bunch of different experiments like
    • daily tournaments with leaderboards
    • bitcoin rewards

All the while, defending constantly against all the attacks a large whale in the ecosystem was helping further the narrative on.

This is my Github with which I make contributions to Yral. Since, July 2025, contributions dropped significantly since I was personally spending a significant amount of effort and bandwidth just trying to defend ourselves from the barrage of attacks and accusations coming our way. However, since January, we have our mojo back and we will continue to make progress at the pace we’ve currently been.

image
image1312×844 208 KB

So, instead of repaying technical debt and cleaning up canisters, we chose to prioritize user facing features what were lower hanging fruits and was much more likely to lead to wins in the short term that could help demonstrate capability.

Also, as has been claimed before about “clogging up subnets”, that’s an incorrect understanding about how compute allocation on the IC works. Inactive canisters don’t really get charged compute unless they are being actively called. That’s because, just like a serverless platform, an inactive canister that’s sleeping isn’t actively occupying memory and is booted from memory in favor of active canisters. Think, like a LRU (least recently used) cache. So, inactive canisters only pay for the resource they use, which is storage which is on disk.

So, they wouldn’t clog up subnets as you so claim. And they pay for the storage they use.

But with rising cycles costs and some breathing room in terms of team bandwidth available, we are now repaying techincal debt and cleaning up unused canisters

39

There’s nothing for us to drop. We are “nice” people.

If you’ve been here the whole time, you already know everything there is to know. There’s no “wool pulling”

I also wanted to say “I get it”. I do understand why things played out the way they did.

40

Distrikt shipped native iOS & Android apps years ago, Plug Wallet has had a mobile app on both platforms as well, and Me Wallet (AstroX) has been on Google Play too. So, you’re first - right after those guys.

41

No, I mean native mobile apps. Not Dart/Flutter. Not TypeScript/React Native.

From what I remember seeing before, here it is:
Plug is React Native.

https://github.com/Psychedelic/plug-mobile

image
image372×318 4.06 KB

Distrikt I’m not sure of. I couldn’t find their Github. If you have a link to their repos, I am happy to be corrected.

AstroX I’m aware is Flutter. They’ve done significant work to make the Dart agent work there. Another IC project (Rubaru, if I recall correctly) also based their mobile app on AstroX’s work on the Dart agent

https://github.com/AstroxNetwork

Native as in Kotlin on Android and Swift on iOS

It requires figuring out how to interop and call the IC Rust agent from native code.

We figured out the engineering to do this because we did not want to compromise on the performance required for a native infinite scrolling video player experience

42

I’m not sure I fully understand this.

43

The problem is not that you are cleaning up old canisters. That part makes technical sense.

The problem is the narrative.

For a long time YRAL used the per-user-canister model as a scale flex. Hundreds of thousands of canisters, massive user infrastructure, big ICP-native architecture, etc. Now the same architecture is being reframed as technical debt that had to be cleaned up because it became expensive and inconvenient.

You also said parts of the old infrastructure are still being called by current apps, which means the original framing of “no longer actively used” was not the full picture.

So let’s stop with vague explanations and publish the numbers:

How many individual user canisters were created in total?

How many are still active?

How many are empty?

How many will be deleted vs uninstalled and reused?

How many cycles are currently sitting in them?

How many cycles will be recovered?

Where exactly will those cycles go?

Which DAO canister receives them?

Will the full cycle movement be publicly verifiable?

Because without those numbers, this looks less like transparent technical cleanup and more like another YRAL narrative cleanup.

You had this microservice direction in GitHub since July 2025. That means this was not discovered yesterday. The community deserves exact numbers, not another polished explanation.

44

distrikt isn’t open-source, but as far as I remember they were planning to build a native iOS app, though they may have scrapped that idea, idk no time to fact-check rn. Either way, claiming “We’re the first!” is something you say only when you’re 100% sure about it. And especially when it actually means something imo

45

The above is completely true. We are the first ones to achieve this milestone.

The takeaway is that we were frying bigger fish and trying to focus on end user facing features and spending effort there and that is the exact reason to the question why we’re doing this cleanup now and why not earlier

46

To answer all of this comprehensively, would essentially mean implementing a canister native product analytics suite that we then have to publicly host and maintain.

Which doesn’t further our goal of user acquisition or retention for Yral and hence would make NO sense for us to build or implement.

However, whatever code we write and ship will be fully open source, so you are more than welcome to check our open source repos to figure out the answer to your questions

48

4k daily active users

100k monthly active users

1M downloads till date

Approximate values

50

We just started monetizing a month or so back.

I don’t see a problem. I see potential.

But to each their own

53

Kinda.

We are founders. We don’t stop. Even if we don’t have employees on payroll, we will still keep working on this.

We are operating a startup and that means do whatever it takes to make it.

Having said that, we are also evaluating other options as well:

  • We are actively looking at new funding sources
  • We’ve already cut expenses significantly, looking at further cutdowns
  • Scale up revenue further to offset expense

We are and will continue to put in the requisite effort required to make this work.

57

Thanks Saikat, useful info.

59

thats a bad thing thats all i have to say about that