Swarm Community Call — November 2025
Swarm·Tue, Dec 9, 2025, 12:00 AM
This month, we will track the final stretch of Bee 2.7, get a fresh report from Devconnect in Argentina, and dive into Swarmonomics with a guest from Shtuka Research – a topic that’s sparked plenty of community-wide debate. What to expect: - Core Development Updates with Niki Papadatou and Callum Toner - In Focus: Devconnect Recap with Dániel Wéber - Community Talk: Swarmonomics with Andrew from Shtuka - Research, Ramesh Pallikara, and Callum Toner
Transcript
Okay. Hello and welcome to Swarm Community Call. For everyone tuning in on X, please know that the call is being broadcast from Huddle. And if you'd like to post a question or join the conversation later on, you're kindly invited to join Swarm's Discord server and post your questions in stage chat as X is audio only for you. Uh in today's November's call, the agenda is as follows.
First, as per usual, we'll start with core development updates. Next we'll move to defconet recap and after that I'll leave the stage to Callum Romesh and Andrew from Shuka research who will dig into the research outcomes on swarmomics the tokconomics in swarm network. All right let's kick things off uh core dev update first and I would like to ask Nikki and tell us more about that. Hello. Can you hear me?
Hi. I can
Amazing. So, hello Mina. Hello everyone. Welcome to the November uh SW community call. It's great to see you all again and thanks for joining.
Um this month on the engineering side, uh we've done huge progress towards uh B2.7 release. So, let's dive into where we are and what's uh been going on. So we are happy to share that the latest uh 2.7 release candidate is now live on the public testment and it includes all the important lamp features and fixes.
Two of the key features multiple underlay address uh support and TLS have both both been fully tested by the B team internally and we are now live for publicly testing both for public testing. These two changes are essential for improving uh node connectivity especially in complex environments and for uh enabling uh secure websocket connections. A key building block for uh the big browser um experience. So if you haven't yet uh we encourage you to test the latest RC and send your feedback especially if you are running uh browserfacing uh integrations. Um this month we've also upgraded um our uh dependencies including Golang uh version li2P to ensure B remains relevant with the broader ecosystem and stays uh secure and performant with whatever uh this means with testing with adapting with all the changes and everything.
And alongside that uh we've been heavily focused on improving uh the testing suite. So fixed laty tests uh the extensive new human tests and uh ongoing work on integration tests particularly around web sockets and autoTLS. Uh all of this helps us um ensure the quality and reliability of what we are shipping uh with 2.7. Um one thing to to flag um our recent uh FITSPR has introduced some backwards incompatibility with field uh fits uploaded uh using um legacy formats.
Uh the team is aware of this and we are already looking into possible work arounds to mitigate any disruptions for DS relying on older uh feedback behavior. And we will share more as soon as uh we've looked into the approach and have initial positive sides. But for now, I only wanted to bring um heads up uh to you explaining um what we are working on. So to summarize, please try the latest RC covering the majority of our 2.7 features and fixes which is set also now public testment.
We are testing, hardening and finalizing quality. um across the board and compatibility is under review to ensure smooth upgrade path for everyone. We're getting really close and this release is not just about features. Uh it's about raising the quality and reliability of Swarm um in general. Thanks again uh to everyone for testing, contributing or just staying uh tuned.
Your feedback is always essential and we deeply appreciate this. Until next time. Thank you everyone. Back to Humina.
Thanks Nikki. Uh I would like to just uh once again repeat that if you have any questions be that for Nikki or later on you're free to post them in discord state chat. Uh now let's move to our next section which is defconnect recap uh related. So last week uh Defcon connect landed in one of the most cryptonative places on earth uh Argentina and the local ecosystem had long long been asking the Ethereum Foundation to bring Defcon or Defconnect to Buenosiris and they did and it's fair to say that the community there more than lived up to the expectations. Uh on the content side, I mean the um I'd say the dominant themes were privacy, ZK stuff, so ZK related uh stuff and AI meets crypto.
This last thing being actively pushed as the next wave for the Ethereum ecosystem. And yet there was a visible gap between idealism and reality, I would say. So the marketing seems to be way ahead of the tech. maybe a topic to discuss at one of the upcoming community talks perhaps. Yeah.
On the other hand, privacy seemed to be one of if not the key word of the dev connect hand inhand with trustless. Uh Vitalik released a trustless manifesto during dev connect. Uh all of which kind of aligns perfectly with swarm's values and position. Privacy is privacy as default not a feature. We heard permissionless systems as the way to the free internet all sounded like swarms manifesto.
And indeed this return to core values and ideas was kind of obvious. Be that as a result of market changes, global politics or the more narrow Ethereum ecosystem on itself. It all sounded like wind into our sales. Uh I do regret the fact that this community call is happening so closely after the deaf connect while some key members of the our team are yet to return from LATAM and the impressions and takeaways and actionables are not entirely formed yet. So I'll use this opportunity also to say let's maybe take another deeper look into this on a separate call perhaps hosted in Discord.
Please let us know what you think about this uh in the state chat in Discord. Uh as for our team's engagement, we were active throughout the conference, listening, getting in in conversations and moving perhaps less noticeable to the outside observers, but all the more thoroughly behind the scenes this year. We were also present at the very successfully hosted second cipher punk congress a day before Defconet began. uh Swarm's founder and architect Victor Thrawn was speaking there at the panel on cyberpunk values from infra to apps. Uh this congress was hosted by web free privacy now the loudest actors advocating for privacy in the ethereum space and uh this is also an initiative supported by swarm foundation from their beginnings.
uh they were also the coordinators so the web3 privacy now fellas of the ethereum privacy stack on Friday just before the closure of defcon connect the next day and we had swarm foundation COO Sandor Nagi there to deliver a speech on swarm as part of the original holy trinity of Ethereum uh right after that Shander and the rest of the team headed to a side event hosted by our ecosystem allies Solar Punk and at this point I'll hand the mic over to Danny here with us today to report on that to also go into more details of the key takeaways from that very busy week. Uh Danny, can we hear you?
Thank you, Mina.
Great.
Let me know if you can hear me.
Yes, I can. The stage is
okay. So uh yes as Mina as Mina mentioned security, privacy and AI were the key uh three focus areas of of of this uh of this week a little bit more than a week. Uh and in fact uh AI was uh seemed to be very much in the focus of the of the Ethereum Foundation. Um there are new standards announcing um being announced to support the the the end vision which is the agentic economy. uh and this is where where swarm is uh brilliantly well positioned.
Uh we have already announced our uh our MCP connection. Uh and uh and also we have access control on the protocol level and both both of these uh these are essential to realize a trustless communication layer for the uh agentic economy that is envisioned by by most of the members of the uh of the community. Mina has already mentioned that there has been a side event organized by solar punk uh with close to 100 participants uh and that included uh decentralized uh AI panel. In fact, I think I forgot to mention that that uh that there were three separate uh AI side events u during the conference. This was most probably the fourth one that was organized by uh by solar punk.
It started with a uh with a round table uh panel discussion uh featuring swarm uh solar punk data fund and morphose AI. It was a great discussion. Uh it was um uh it was moderated by Migler from uh from uh women in web3 privacy and and both the panel participants shared the same vision uh of this agentic economy that is about to follow uh the current uh the current wave of uh of uh of the AI agents. uh and um everybody believed that uh that uh in order to get a proper uh a proper solution for the end users in the future different AI agents needs to work work together. uh and that calls for decentralization uh and that calls for uh for uh to protect the uh the context uh of of the users and uh and it needs a temperroof trustless layer for for the agentic interaction and as I said uh we all believe that swarm is brilliantly positioned there.
the the panel discussion was followed up by uh three educational workshops uh one of them uh being actually uh actually showing how anyone can integrate Swarm uh using MCP uh and the second one was how to decentralize any front end on Swarm and also how to realize uh how to realize streaming on Swarm. Talking about streaming, um uh we have just announced a partnership with Crypto Mondays and in fact uh uh the streaming site that was uh that was created for Crypto Mondays to stream their various workshops around the globe. Uh it actually debuted uh with a live streaming from this Solar Punk side event. Um and um and we are ready to on board uh new partners. So we are starting um um actually solar punk is starting the sales activity to find new partners who would uh who would love to use uh decentralized um u decentralized streaming for uh for their own purposes.
Back to AI, we have uh we have actually a a hashgraph plug-in developed for the convers so-called conversational agent desktop uh which is basically uh the the one that ensures that uh whoever is part of the hashgrapher ecosystem can uh can develop an agent and that agent can interact with other agents. So we have a uh we have a swarm plug-in uh approved for that uh and it is being uh it is being u um integrated into the into the desktop uh of uh of this conversational agent and there is communication to start very soon on that. We are just working on the on the details of the announcements and uh and communication also. We continued uh um on behalf basically building on our MCP on the swarm MCP and we had a discussion with Eliza OS and we agreed that we will be uh developing an MCP integration with the Eliza OS ecosystem as well. um going on with uh with uh with what was happening around AI um the size seems to be so decentralized science seems to be also an emerging area uh that's sort of a special use case where uh where users can share their data for scientific purposes.
Uh this is a developing area and we have a uh we have a partnership forming with uh with an Estonian university partner and um and um the the aim is to uh to create a secondary health data marketplace uh for users. The MVP is scheduled for for end of 2026. So we are really excited on uh on on that one. talking about other uh other areas where uh which which we which we which we are focusing on. One of them being uh one of them being we call it file management but call it storage and file management.
Uh we have uh we have established a uh a partnership with Remix the smart contract coding platform. Uh and we have planned uh together with them a two-phase uh basically a two-phase project plan. Uh the idea is to integrate the swarm nodes into uh into the remix desktop so users can um can manage their storage uh on on swarm and uh at a later stage uh we are aiming to realize collaborative edit editing with access control as well. Um talking about managing managing data in general, we had a discussion with uh with blobscan. Uh we had a testing period with them uh so far and uh and we both realized that there is a massive amount of data that that would need to be uploaded from uh from blobcan to to swarm and we have found a theoretical conceptual solution how to uh how to support that and that would be a great use case for anyone uh who wants to upload a massive amount of data continuously uh continuously to swarm.
So we will continue the discussions uh there. Uh we have also identified a couple of IPFS users uh who are not satisfied with uh with uh with the tech that they are using. Uh so we have discussed uh the particular advantages that we could bring uh to the table and we are planning um we are starting the planning of integration projects with uh these ones. uh some of them uh are Claros and Gainforest and on top of that we also continue with seven more other projects with uh with meetings agreed. So all in all, yes, it has been a very very busy week.
Uh and as Mina said, uh we still need time to uh time to summarize all of the all of our uh experiences, follow up all the leads, but uh we as as I mentioned at the beginning, we very we are very sure that uh that we are very well positioned with all our features to uh to support AI as a as a booming economy and also we have identified many of uh many of these key uh areas where we continued with these key partners the discussions and the project uh plannings. So back to Mina.
Thank you. Thank you Danny. Uh if you have any questions for Danny uh please post them in stage chat in Discord. Um please stay with us Danny in case uh you would be needed to answer anything. Uh but let's move now to community talk uh which is Swarmmonics this month.
Uh the team sees Discord. We are listening and we are taking the concerns about all of what the community writes there seriously. They will be addressed thoroughly and right, but that requires some time. The so-called revival plan is being worked on um as is crucially delivering and improving the product the production ready network because only with substance can we resolve the frustration around financial and marketing markets. Uh there are many interlocking factors and this call isn't the place to unpack them all.
But what is on today's agenda though is a research focused look at swarms to economics for a start. Uh that said I'm inviting to stage Andrew from Research. Uh Callum and Romesh guys please take it over.
Hi Amina. Um yeah, thanks for the introduction. Um let me just share my screen and you can see uh I've prepared a presentation.
A click and a clack. Oh, and here it is.
Okay, so yeah, so uh thanks for the intro. I'm Andrew from Stuka Research. I've been working on the uh with the swarm foundation on this swarmomics research project for the past 6 months. Uh we've been looking into basically research and suggesting improvements on swarm's economic design. Um today I've prepared a short presentation which presents a view of what swarm's economic and tokconomic design could be um over the next year or so.
Um just to disclaim this the content of this talk is not part of any official road map at the moment. It's my personal views. Um but it's something that I think could and maybe should be at least elements of which should be introduced into an official road map. Um but yeah, it's my personal views and uh there'll be a conversational element where Romesh and Callum feel free to jump in at any time and um engage me on this or wait until the end and we'll have a conversation at the end about it. And uh a second disclaimer is that um this is not meant to say that other areas of improvements are not as important as this like obviously onwarding users.
Um this is just purely focused within the co scope of what can be achieved with uh tokconomics and mechanism design which I think already there there's quite a lot of interesting stuff to work on. So let's dive in. If I were king of swarm, this is what I'd do. In summary, scale staking, ditch the utility token narrative, freeze the price oracle, stable coin fees, and announce the road map. Uh so these things I've emboldened scale staking uh because it's the most complex and I think also probably the most important.
Uh so let's dive into that one first. What is scaling staking and why is it important? Currently staking BTZ tokens is the only way for a BTZ investor to directly access a share of Swarm success. If you're a fundamental investor and say like a Warren Buffett type character who's buying the token, not because he wants to flip it to the next the next guy um who who who sees a tweet by Vitalic and gets into wants to ape in, but someone who wants to hold it for the long term and get value out of that. There's someone who wants to see a cash flow and they just want to sit and get rich off the cash flow, right?
And not sell the token. This is the kind of long-term investor which is going to really grow uh swarm sustainably in the long term and the measure of that type of investor are the because the way that they access this cash flow is to stake and there's a standard way to measure this right the term TVL total value locked that's the uh that's the amount of money that's being invested in this way into swarm so one thing that I think should happen is that uh swarm community and swarm um team needs to start recog recognizing and tracking TVL as a success metric of like these types of fundamental investors and then trying to grow it. So let's look at the numbers. Okay, so like not looking that good at the moment. Where can we what can we do to improve it?
Why is it looking like that? What's not good about it? And what can we do to improve? So of course as we know Swarm's market cap at the moment is not the biggest. Um but there's more to it than that at the moment, right?
even looking at as a percentage of supply only a tiny number of tokens are stoked to stake right now and um the reasons behind this are basically in my view um that staking is still currently it's too limited um it's not attractive enough even within the community of BZZ holders and it's too difficult to do so we got to pump those numbers up how are we going to do it basically there's two things to do, right? You have to make staking more attractive and you have to make it easier. Uh in more detail, that means enable withdrawals, reduce fragmentation, simplify node DevOps and uh separate the roles of uh operations and capital. The first one's kind of easy. Uh enabling withdrawals.
if you're going to put money into some kind of investment, uh it's much easier to decide to do that if you know you're going to get your money back at the end of it. So, the way that swarm staking currently works, you basically burn your stake and then you have to make that money back off the returns. Those returns are are risky, right? So, it's much easier to make a decision about a risky revenue stream if at the very least you're going to get your money back, your principle at the end of it. This one's also nice because it's kind of easy to do.
Um, the proposals are already PR. There's a little bit of work to do um like filling out the details and getting everybody aligned. I did a little poll in Discord and um asking node operators, what would you do if withdrawals were enabled tomorrow? And um I think unsurprisingly most people said they put more stake down uh because you know they were holding off and putting down stake because they weren't going to get it back. Right.
Obviously that's a very small poll so we don't really know uh what will happen but it's kind of like it seems uh clear from an incentive perspective. And then perhaps less obviously uh there's benefits of this for network stability which basically means that if you're going to give the state back to node operators, it also gives you more leverage over node operators to um behave in a way that's good for the network. Uh basically you can dangle the threat of slashing that they don't get all of their um collateral back. And that's how things like Ethereum already work. The next one's a little bit complicated to explain, but um it's due to a kind of idiosyncratic feature of Swarm staking system.
Uh it's very fragmented. Basically, when you run a node, you have to attach your stake to a particular neighborhood. It's not that's not exactly how it works, but it's a reasonable approximation for this discussion. You have to attach it to a particular address range in the uh trunk space. And um there's hundreds of those ranges, right?
512 at the moment. So that means all of the stake that we have is split into hundreds of tiny pools. The average TVL at the moment of those pools is just $30. So first of all, if you're talking about trying to make a civil resistance mechanism, um considered on a per pool basis, that's not very civil resistant. Um, but from more importantly from a staker's perspective, it means that if you're trying to put $1,000 worth of stake into um into swarm staking, you can't really put it all into one pool because you'll have a massive market impact and you'll kill the yield on that pool, right?
The only sensible way to do it is to split split your $1,000 up into say $500 $2 pieces and put it spread it across uh 500 different pools where you won't have such a big impact. um that's really complicated. Obviously, uh most people are not going to bother to organize that. Now, solving this problem is not super straightforward. It will require a bit of research.
Basically, uh the way to solve it will be to get it all into one pool for the purposes of sharing out revenue. Right? In other words, when you stake BZZ, um you're going to get a a proportionate share of revenue to your SH stake among all stakers and not just stakers in the same neighborhood. Um, broadly speaking, I see two ways to go about it. One way is you redesign the staking system um sort of fundamentally so that this is happening at the base layer.
Revenue sharing is happening in a global pool. Um there's some work to be done to figure out how one would do that. It's not totally obvious. Another way is kind of keep things how they are and then introduce an abstraction layer on top so that stakers have the experience of imagining like it's a like it's one big pool. Um and then there's some kind of layer handling in the back end the allocation of the stake and spreading it across um many different locations.
And probably what needs to happen is uh somebody needs to do a little bit of research into both directions to see what they look like and do a bit of triage and see what's the most reasonable way to proceed.
Andrew, if I can jump in if I can ask you a couple of questions on what your thoughts are here. Um
yeah, obviously of course in full agreement with withdrawal stake of course. Um that is a good idea and we have basically that prepared essentially already. um for this part where it comes to how do I actually allocate stake how does that get handled where is it most favorable and equally this it also has to be the most lightweight solution possible because as you say you know node operators find it incredibly difficult to do this therefore we get a very low percentage of BCT that actually ends up staked as a as a result right so it's about removing friction keeping it fair and then implementing it I guess as fast as we can reach consensus and do the work But what I'm interested in is the solution here is to redesign or unlink stake from the neighborhoods entirely. And I'm interested in what you think the alternative is. For me, my overall question is why not just distribute the stake more evenly across the honest revealers.
And then that also increases the cadence of payouts to individual nodes instead of the current problem that I also feel which is you may have to wait around 30 days before you even get your shot at winning a game and then god forbid there's there's a skip round um then it's not going to happen. So, what do you think of the far even split alternative?
Uh, so like I'm not sure I understood the uh the suggestion. Is it is your suggestion something like um when you have a round it's paying out to multiple stakers instead of just the winner of a lottery. Is that the idea?
Exactly. And then I think this makes your your current question or your solution maybe a bit more simple. I
I think that's kind of addressing a a different problem actually. like that's also a relevant and interesting problem. Um, and I'm I'm kind of like on the fence about that in some sense. I think the I think the lottery system was introduced first of all like mimicking um Bitcoin which kind of does it by necessity and also because of like a gas optimization issue like it's if you're have thousands of stakers and you're paying all like every single one of them um every single round then potentially you're like doing a lot of transaction traffic what you might not have to do um
yeah but on the
if you if you don't if you if you don't if you have the lottery system then as you say you very high variance of the rewards and if you're a small staker that's kind of a big problem, right?
Yeah. And I'll only allude to my other thought in which case the only obstacle to making it low variance high output of rewards is to minimize the transaction costs which could be done by simply being on another chain for much cheaper fees,
right? And and also like fees are just generally much less of a problem um nowadays than they used to be, right? Like even on Ethereum mainet, they've gone down a lot. We're all talking about scaling capacity. And um Nosis Chain, which is where Swarm is right now, has also historically had extremely low fees.
It has um perhaps less capacity than something like Bass or Arbitum, but like you know, fees have been at some points like down in like the whey territory, which is like you know, basically zero.
Um so I guess like I I just haven't done the calculations to see what that looks like. Another thing that can happen is that and and this is getting ahead of myself a little bit in the talk. Um you you end up with you you carry on with a lottery system and then they end up being like third party solutions like um basically stake pools. I I've used the word pool here but this is a bit different right like it's a pool in the sense of like a you know like on Ethereum
as a staker you do have a lottery like payout and there are like millions of nodes. So if you're running one node you are waiting a long time for a payout. Yeah. But then if you don't want to do that, you can go through a third party like Lido um who use some and I don't know how exactly they do it, but I believe they they they pay people out on an even basis.
Exactly. Let's call that generally like syndication is kind of the economic model of what that looks like.
Yeah, that's a good time for it. Yeah. So I I kind of haven't worked through the trade-offs of what that looks like for Swarm, but again it's like Yeah, that's something to work through. Yeah. Yeah.
And um yeah, I'll not go too far deep into that. Anyway, Romesh, you got your hand up. You want to jump in?
Yeah. So, um uh regarding the withdrawal, so uh I was wondering like um what your thoughts are on on how it could probably impact negative leader network and maybe what you think about some uh a minimal duration. Um yeah. So, have you had like any thoughts on that?
Yeah, so I mean this was I I kind of always I was expecting there to be some kind of like delay, right? Like some kind of controlled withdrawals rather than instant withdrawals. Um although the original uh swip that IP was uh the simplest possible version which is instant withdrawals, you know. Yeah, as kind of as expected, people thought like that's not a good idea. And indeed, yeah, it is a it's it does seem like a good idea to me to have some to allow the protocol designers some kind of control uh to throttle the rate at which withdrawals are happening.
At the moment, what we've been talking about is like um basically a fixed period delay um where if you unstake, then you have to keep on carrying on participating for a certain amount of time. Um I don't think we yet reached alignment on what that amount of time should be. Um but yeah, enough for certainly enough for uh if there's a mature enough node population to like see that somebody's exiting and say, "Oh, I'm going to queue up and I'm going to take their place um and like maintain the health of the network." Um that's they've got some time to do that basically. Yeah.
Right. No, it makes sense. It makes sense. Yeah. Um there is that
yeah question.
Yeah we can we can continue. Yeah thank you.
Okay. Yep. So um yeah scaling staking get fragmentation. Okay we've done we've done that.
Uh next one. Node DevOps. Pretty similar situation to fragmentation. If you want to scale, if you're a node operator, you want to scale your operation, you have to run hundred. Well, at the time of I wrote this slide, it was thousands.
The network radius just went down. So, it's hundreds now, 512 neighborhoods. Um, hundreds of processes and each node has to have its own wallet. So you also need to have hundreds of wallets and that associating with that is sort of a DevOps task managing all the uh processes and then a sort of wallet management task where you have to make sure all the wallets are topped up with gas and then sweep the rewards periodically. Okay, again that's hella complicated.
Um not many people are going to do that. Uh and this problem is kind of also not that difficult to solve. I think we we just need to make it, you know, enable getting more people providing more storage capacity on one single process and one wallet. And in fact, you can already do that. Um, you've got this reserve doubling now.
And I think it's been I I believe CH tested this up to 256 GB, which would be uh four, which corresponds to setting a parameter reserve doubling equals four on your node launcher. Um, I'd say like get that tested like more robustly and make that a baseline suggestion. Okay, if everybody on the network, first of all, everybody's got 25 gigs 256 gigs free on their computer these days, right? 16 gigs is tiny. So, you can it's totally reasonable to like you're not ruling out home stakers or home node operators by requiring 256 gigs.
And secondly, at the the network's current size, if everybody is running a 256 gig node, um you'd only need 128 nodes uh to maintain full replication of the network instead of 148. And currently, at least like last time I checked this, there was um the the the network's like slightly underreplicated, and this just wouldn't be a problem right now if everybody ran 256 gig nodes. So, uh, I think that would, um, yeah, im immediately give us a little bit of scaling and make things a little bit easier and it would allow people to have access to a bigger amount of rewards because the amount of revenue you can get from renting out 16 gigs of storage is not very much. And then uh the last part is uh maybe something I think that comes a little bit later further down the road. Um but you kind of see this in all of the larger cap projects which have staking.
It kind of always shows up in various forms. Um separating the roles of capital from operations, right? give BZZ token holders a way to not have to run a node themselves, but to hand their BZZ to some professional node operator who's going to run all the operations and do all the IT stuff, and then they're just going to give a kick back to the um to the BCZ capitalists. Okay, there's a bunch of different ways you can do this. Um delegation, state pools, BC lending, those are some buzzwords.
Um it's done in different ways in different projects. Uh there's also different uh ways that it can be organized like you can develop it at the core layer from the core team um with some like protocol level solution or you can just not have that and you can let the market provide um third party like higher layers. Again this is how they've allowed it to develop on Ethereum. Ethereum doesn't have any kind of delegation for staking built in. But people have built liquid staking solutions on top uh which allow people to access uh Ethereum yield without having any kind of IT skill.
Uh but like yeah so one one one thing I would say is that this is something that ought to come um further down the road than making it easier for people to run bigger notes because those that has more benefits as well as um making it easier for BCZ's investors. Okay. Um that's scaling staking. Next one utility token narrative. Uh my view is the utility token narrative has to die.
Um the first of all BZZ token has a good narrative potentially a good narrative. It's what I said at the start of this um presentation, right? You're holding BZZ, you can stake BZZ and you get a share of the network's revenue. That's an easy to understand narrative and it's like that's the narrative of of shares in companies and you know those have been going up since the uh beginning of stock markets. So let's just uh let's just keep it simple here.
Um the original idea of utility token was like BCZ tokens going to be used for payments. The unfortunate thing is that the users don't want to hold the token and that's kind of already been acknowledged because now with um Bport um you remove that friction and um customers don't even have to hold the token. They can just pay with a stable coin and the BZZ stuff gets abstracted away and handled by some market maker. So we've kind of already acknowledged that. Um yeah, so so that's that's not working.
Um yeah, I I could rant on about this issue for a long time. So, I'm actually going to try and keep it as simple as possible. Uh, yeah, we we we don't need this narrative because we've already got a good narrative of uh earning a return a share of the network revenue. And um the a lot of the one of the reasons you might think that we should we should be doing a utility token type approach is because if you look at the top 10 crypto projects by market cap, you'll see a lot of utility tokens. So if they're doing it, why shouldn't we do it?
Well, there's a number of reasons for that, I think. Um, one of them is that those projects are mega mega exceptions, which are very, very hard to achieve. And another one is because the fundamental design of those projects like uh layer 1 blockchain necessitates issuing your own token because that's the only way we know how to make a layer 1 blockchain. uh or you're something like a stable coin which is probably the you know undoubtedly the best um payment tokens crypto payment tokens that are out there the most popular ones the most widely used and um you know those ones are not ones that you sit on as an investment right they you move them around
and that's the point of them um yeah I I won't go through all the rest of these bullet points unless somebody wants to engage me in a debate about that it's just it's not fit for purpose anymore price oracle. So the price oracle is the thing that quotes the price of swarm of storage. It's quoted in BZZ. Um the main role it plays is that when the storage is under supplied and the replication rate falls below its target, um it's going to mark up the price of storage in an attempt to attract more storage operators to come and shore up the replication rate. Um, unfortunately it doesn't really work at the moment because in order for that to work, there has to be a plentiful supply of node operators waiting in the wings ready to come in when the price reaches an attractive level.
Um, and there just isn't that population at the moment. It's the node supply is very immature, I would say. Um, so all that's happening, and this has been happening for the last few weeks, is that when stuff falls below the target replication rate, prices just start shooting through the roof, um, and, uh, for basically no reason. Uh, that has kind of a negative side effect as well because, uh, it causes people's storage quotas to expire more quickly, uh, which ultimately kills revenue even further, uh, leading to some kind of vicious cycle. So, I would say price price oracle doesn't work in a a price oracle like this can work in a very mature market.
We're not there yet and it's worsening UX. Let's turn it off and just hardcode a fixed stable coin price. Um, since storage prices are currently dominated in BCZ, you'd have to have an X die to BCZ oracle to convert your fixed stable coin price to a BCZ price. um those are probably available but you don't even have to do that if you switch over to stable coin denominated fees um at the base layer but from the users perspective as I already mentioned um you basically there already users already pay in a stable coin and get it um the the bzz stuff sort of handled in the back end um so why not cut out the middleman and just allow users to pay XY directly to node operators and from a node operator perspective it makes it a lot easier to understand the value proposition of running the of staking BCZ right because instead of staking a risk asset to earn more of the risk asset you're staking the risk asset to earn cash from fees and then a minor point at the end is it also means that node operators don't actually have to sell any BCT they can just use the money they're getting as revenue to cover their operational costs
I have a couple points here. So I completely agree with you. I think this is the most important point so far that hinders revenue product and UX which is this price oracle. Um I am not a firm believer obviously in its mechanics at the minute for the obvious reasons but let's play devil's advocate for the rebuttals that I receive as well for it which is this is a completely decentralized project. Who are you to say what the fixed price is going to be for storage in any given period of time?
You don't have the right to do that etc etc. My argument is that even within a decentralized project that is also a scaled not absolutely every single value has to also arbitrarily be decentralized. Um and certainly in our current stage I would love to fix it or find something close to just fixing the price at a competitive rate. But what do you say to people that say, "Well, we need an oracle because no one here is qualified to set a price."
Well, it's I guess like um I I don't think it's it's really a being decentralized or not decentralized doesn't really distinguish the fixed price from the price oracle approach. A price oracle still needs to be designed and it still has a parameter which is learning rate. Um it also has a in in the case of form there's also a minimum price again that's sort of fixed by
um by by the the protocol designers and um even if this system were left in place would probably have to be reduced at some point right because if the value of BCZ goes up a lot that minimum price actually gets pretty expensive. Um, one one thing that a system like this does do is if it's working well, it can reduce how often you need to do an intervention in order to manage um, basically the market uh, fit of this. Um, if you really do want to make it completely decentralized and try to never do any interventions that that you know I I guess that does it does take away power from the protocol maintainers, but you could find your ending into a your decentralized like immutable protocol is going somewhere where you didn't hope it would go where, for example, the price oracles like price discovery ends up going into a tiny niche of extremely overpriced storage which is like um never going going to break out and never going to achieve um an in scale that makes it worth all the work working.
Exactly. Because even if you think about it as a product on an adoption cycle, you know, you would hope that you're one of the early adopters, you get the right thing at a low price and you ride it up and you say, "Oh, I remember back in the day when I had storage on Swarm and it cost me, you know, X BZ, which you know, in today's terms is actually, you know, some much larger amount, etc., etc." But here what we're doing is actually creating a system which is a much higher barrier to financial entry.
Yeah. I mean I I guess that that's like too right. So that's like um that's the that's the dynamics that are playing out at the moment. But like from a philosophical perspective like you we you are building a system which is you're hoping to target some kind of users, right? It's not it's not like completely up in the air and random like it's being built by some people to do to to serve some user some kind of service.
Um and the price is part part of that because the price will select those users and um you know if it's uh depending on where this thing goes if it's if it's like um if if it it's not working the way you want it to you'll end up selecting you know a very small number of users or no users right so I think I think it's better for to acknowledge that especially when the project is in its youth
um and has retreat reached a mature market that you can like give it like give it some training wheels, right? Let let it let it find the market that you actually care about. Um and then later on these kind of mechanisms can work, right? Ethereum base fee works on a similar price controller mechanism and it works pretty well. Um I think um but um again like Ethereum kind of really Ethereum has also had more requirements to be centralized even to like work at all.
it's much harder to do an intervention and change in the designer because of the um
vastly more uh like stakeholders involved. Um but yeah, like it's also got a mature market. So happily that their system kind of works.
I think I think it's a system that could be revisited later down the road, but like right now um I think training wheels are the way to go.
True. So um right
uh yeah so I actually kind of really like that I think the the three slides like the one that before and the one after are sort of um three different interconnected part where uh one is between the utility token narrative then the uh turning of the circle and the third one which was uh yeah the stable coin pricing right and and uh it actually makes a a lot of sense in the because right now as as as a user who wants to buy storage the the the kind of financial modeling that a user is expected just to store some data on the network because the non there is nothing that is actually constant somehow because then your if the basis token value is volatile and then your your stamp might expire sooner So then you're you don't know when or how long exactly you are buying your storage for. This is this is like way too much of financial modeling that we expecting from a user. and and uh I kind of uh I really agree that um making that into a stable coin sort of way would would sort of reduce this cognitive load that we are buying on the user and part of that reason I think we'll also see a greater adoption and uh when when the network is mature I think the price oracle can indeed work like it has planned but until then uh it does have this sort of a a vicious cycle uh where where it will it kind of gets um harder to get out of uh because also we don't have new users coming in and buying because the price is also again fluctuating. So it's sort of like interdependent on each other. So yeah, I I agree.
I I think uh these are very very good proposals
right and then even in like later on when you reintroduce the price oracle again you will have as you say there's this issue of a cognitive load like how much complexity is a user expected to manage at some point that is something that can be abstracted away by again an external third party who like manages complexities of um like pricing storm storage and then they just offer fixed price product to users and that's that is a cost like they'll have to take a fee on that because it's a middleman. Um but at the moment there's like first of all there's no one who's likely to do that right now. Um and secondly a more fundamental issue is that it's it's not it's not currently serving its purpose of stabilizing. So like that's that's a more fundamental reason that it it should be at the moment.
True. True. Andrew, my uh last question on this really doesn't have anything to do with the Oracle or or anything in that regard, but just in the sense that to users and to us, this is obvious, right? This is what we want. We you know, we talk about this internally, externally, everywhere.
We watch the price go up on the oracle, but I mean, let's have some hard talk. So why can we not change this immediately or sooner? Right? So what I mean by that is all of our tech is completely decentralized but equally so is our decision-m so if we're watching these things that are suboptimal that we love to change for tokconomics. How can we in your opinion expedite this to get the right result and the right tokcon tokconomic setup much faster than what we currently implement?
I mean, do we do community votes for this and then immediately start implementing? Because what we what we need here is ironically the opposite of of decentralization, which is serious ownership of who's holding these decisions up and then how do we flip it on its head? So, do we just offer these these choices up in this deck as community votes and see what the impact is or what do you think is the right outcome for your insights? Um, sorry I haven't it's not this is not something I've um actually my last slide is kind of going to be about that although I don't go into the I haven't got into the details of um yeah things like community votes or something like that. Uh again my perspective is it's kind of a it's kind of like a it's the time for training wheels right like going if if for example if we play take the example of like a DAO model which a lot of protocols go through where you have to go yeah a community you have to go through a token holder a staked token holder vote um on every change to the smart contracts and every allocation from a treasury um so that model has a lot of strength and it it's can be very robust but it's also very costly.
It's much more costly than going through a centralized decision-m process. Um because you have to do all of this. Um yeah, like it's a lot of work to get everybody aligned on stuff. Um I think that like potentially and also Swarm doesn't currently have any formal uh DAO model there was uh I think one token holder vote which I was um which I witnessed how that um played out. Um I I think that as a substitute for a uh token holder vote in a project that maybe needs to move fast.
Um I think massive transparency about what's happening can be a satisfying substitute in a sense. I think many you know even even in a Dow model many token owners don't really want to vote. They just want to feel like they know what's going on. They've comfortable and confident in the direction. Um and this is reflected by you know even among stakers extremely low turnout in DA votes.
Um and I I think in in you know from what I understand of the swarm community as it stands today um of course like this is an opportunity for anyone who disagrees with me to come out and tell me but um uh simply getting together the people who are um in a position to actually do something about this in the sense that like you know they're writing the smart contracts and they're doing research on the topic and they're contributing and they have the admin keys. um and getting everybody aligned and giving a clear explanation of what we're doing and why we're doing it. Uh that's going to be delivered to the community. Um I think that's just if I were in the community and well I am in the community but even if I were a passive community member um I would be I would be pretty satisfied with that. So yeah that's kind of that's kind of how I see things playing out in my head uh potentially.
Yeah. I I agree actually. I think it's hard to disagree there. So Kyle, yeah.
No, I think that's that is very very fair is just max transparency which I think would allow for course corrections or the right voices and inputs to be heard much sooner because I do feel that you know a lot of these things we watch happen um over a period of time whereas we could intervene much quicker with more voices. Yeah. And it's like it's always a tricky trade-off, isn't it? Because like you also there's like, you know, sometimes doing more research and thinking about it harder does uncover stuff that you didn't expect and unintended effects and that save you from doing a course correction and having to correct back again when you when an unexpected effect showed up. Um but yeah, just like something that you have to keep trying to keep keep trying to optimize and um also keep trying to uh engage people in the conversation in the like um you know yeah make sure everybody knows what what discussions are being had and allow people like explicitly allow people opportunities um even those who are like maybe spectating the calls instead of like speaking uh to jump in and like voice their opinion and have explanations to their answers to their questions delivered.
Um, and you know, you get may get some valuable ideas that way. So, okay. Shall I should I move on then?
Yes. Okay. So, this is basically basically the end now. Um, that's all the that that's all the changes I was going to talk about. Um, then there's a this coming back to the point about transparency.
Um, doing all that stuff will take some time. Some of it can be done, I think, pretty quickly. Um, and we it's not that complicated. Some of it requires a little bit of research to figure out what is the right way to go about it and how can it be done safely. Um, but we can still get everybody aligned about it like sooner rather than later.
And the good thing about uh markets is you can even bake you can even like fast forward the token price to um like if the um if the market c if the market is going to react to these changes and I think you know potentially it will because this is going to make BZZ basically into a more investable instrument. um you can back out all of those changes into the price today because people will um treat the token um by in terms of what they think it will become, what the intention is it for it to become. Um so yeah, the everybody should get together and figure out which of these things they want to do and they should announce a road map. Um and it's official that that's the intention of the core team. we're going to make it like this and then everybody knows what they're holding on to when they've got a BZ token and then that has the benefit then then there's more funding available as well if if that's um if that results in more investments you have more funding available to actually execute on those plans.
So tokconomics road map I think is a very important thing to um work out and announce sooner rather than later. Okay. So um that's basically the end. Uh we talked a little bit about this already. You sort of preempted this question.
Um how do we turn this from uh potentially just my sort of dream idea of what swarm tokconomics could be into something that actually is going to become a reality? Yeah. Get everybody who might be in a position to do something about it on board. Figure out which changes we all agree about and which ones um maybe we a bit more controversial. Um figure out which ones take longer to do and cost more and which ones are cheaper.
um and then put them in an order and um talk to the community about it and announce it. And um I just did a mockup here of something that that might like looks pretty cool to me. Um just to doubly like hammer like labor this point. This is not the road map. This is just something I made up which I think looks like kind of a cool road map and I didn't even think about it for that long.
But anyway, you you can maybe look at this and imagine what your own road map looks like and then we can talk about it and find something that everybody everybody likes. And that's the end of the talk.
Thanks Andrew. Um actually this was this was a really refreshing presentation. So I I want to uh thank you for for the effort and um all the work that went to into it. uh really really interesting proposals and um I do hope uh they come to fruition. Um Callum
likewise I agree with absolutely everything which is just uh a very easy presentation to to get through always instead of disagreeing with with a lot of things. So um I completely I would love to see a road map basically look identical to that if not just a a slight reshuffle but completely um and the main key takeaway for me is just to come to the the middle ground decision-m against decentralization as a you know as a dogma here to actually gain the benefit for what the protocol needs and that's what I'm I'm looking to see come to fruition as well but yeah thank you very much for your time Andre this was Thanks for having me and thanks for thanks for your great questions.
Thanks also from my side Andrew. I'm very very happy also that I see some somewhat of a agreement on the spot on something that kind of yeah might sound controversial especially in the framed against this whole decentralization narrative. Uh so yeah thanks for coming uh and sharing this with us. I think it was a super interesting call. Uh we are oh my god right or like I guess as a Swiss clock uh at 6:00 p.
m. central time. And I would uh like to conclude by again inviting everybody who wants to uh prolong this debate or ask questions for later time um like they will be picked up at some point to please go to Discord channel Swarm's discord server and go to either stage chat uh or continue in BZZ tokconomics channel. I'm not seeing questions in stage chat at this time. Uh but uh I'm pretty sure they will um come up at some point.
And uh I will finish off by saying that uh next month we will not be hosting a swarm community call on the last Thursday of the month as always because the last Thursday of the month is Christmas Day. And uh instead of that we'll do uh what we usually do in December which is a solstice special edition swarm community call and it will be broadcast on 21st on the solstice day obviously. So um see you then on the 21st of December. Thank you everybody for joining.
Thank you. Thanks. Thanks. Thank you. me working with that trading group for almost 3
Automatic transcript — names and jargon may be misspelled.