Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Community DAO v2 proposal discussion and debate part 2!
Recorded: June 30, 2025 Duration: 1:25:48Space Recording
Short Summary
In a recent discussion, the Nervos Community Fund DAO outlined new proposals aimed at refining grant processes, enhancing community engagement, and ensuring accountability in funding. Key topics included the introduction of milestone-based funding, the importance of budget reviews for larger grants, and strategies to attract quality developers to the ecosystem.
Full Transcription
Thank you. Thank you. Hi guys, I hope you're all having a good day, morning, afternoon or evening.
We'll give it a few minutes and then we'll get started. Thank you. All right, I think we should get the discussion going and as time goes on I think people will
trickle in so I think that tends to work quite well. So off we go. This is part two of our discussion with regards to the Community Fund DAO version 2.
This is a new proposal which is aimed at addressing some of the problems, some of the issues, and refining the Community DAO version one. I will post the link to the proposal in the comments in just a second,
where you can read in more detail. And you can refer also back to the initial discussion
two weeks ago, which covers some topics. We're going to proceed with further discussion of
different topics. The point of these discussions is really to have the community involved in engaging, participating, offering feedback, thoughts,
insight into the proposal and perhaps a good idea will come out of it but
it's just as part of due process and due diligence it's good for people to talk
about the proposal. Once it's been suitably talked about, then it can be potentially in the future voted
on or refined and re-proposed or whatever.
And so with us, we have Jordan Mack, who is from the Nervous Foundation, who has spent
a lot of time crafting this proposal.
Jordan, how are you today?
I am doing very well, thank you.
So we've covered a fair amount last time. We covered, I think, three different topics.
People can go back and listen to those ones.
And the topic that we're starting with, to begin with,
is to do with the grant program and milestones.
Could you, for the listeners, just give a brief rundown
as to what the main aspects of this topic is?
Yeah, yeah, sure.
So before I get into that,
I just want to quickly mention that if anybody wants to speak,
please go ahead and request to be added to the stage
and raise your hand.
We'll try to get around to you.
And if you're listening to a recording of this,
of course, you're not going to be able to speak to us
directly right now,
but that doesn't mean that you can't participate.
I would recommend that you use the Nervos Talk Forum, find the one on the
Community Fund DAO version 2.0, and go ahead, post your reply there. Or if you want, you're welcome
to just reach out to any one of us directly and voice your concern there. And some of you have
already done that. And I can't promise that I will agree with everything you say, but I do promise
to give you my ear and listen. So with that said, let's get into the topics.
The topics today, we're talking about grant budgets and team autonomy is the first topic.
And this just has to do, there's been a fair amount of discussion within the community over the past couple of years about what's appropriate budgets for teams and how these teams need to operate.
and how these teams need to operate.
So I have some thoughts around that that I want to share.
So I have some thoughts around that that I want to share.
We have also the next one would be voting power calculations and lockup requirements,
which is a considerable difference from the current model,
proposing some big changes there on what currencies we actually use
and should we lock up at all.
And then the last one, which we'll try to get to today, is down payment policies,
which we've had very, very few guidelines around these in the past.
And quite frankly, I think we can do a little bit better.
So it's time to reinvestigate and talk about what we can do with that.
Okay, great.
So yeah, go ahead.
Okay.
All right.
So getting into the first one, grant budgets and team autonomy.
So let's see, where do we start on this? So grant budgets are a pretty difficult one to manage.
And part of that is because our industry as a whole has very, very high volatility. As we know,
just with the market rate of coins is up and down all the
time. Sometimes it's up by 10,000%, sometimes it's down by 95%. And that's just the way that
our industry seems to work. And so when that's going on, the amount that various teams and
ecosystems have to spend on development of new projects is also going up by
and down by those same percentages more often than not. So when we're in a bull market, there is a
huge, huge shortage of talent. And a lot of projects are bidding very highly on the people
that are in the ecosystem that can actually do work. And then the opposite is true.
In a bear market, if you specialize in blockchain, nobody wants anything to do with you.
So what does that mean? That means to the DAO that we have a moving target when we're trying to place grant budgets, and we have to pay very close attention to how the market is just reacting and what is actually considered fair at
that time. Another thing to consider is that larger ecosystems, and I'm going to use Cardano
as an example, they have a treasury, which is probably something like 50 to 100 times larger
than ours is right now. That means that they are getting many more applicants and they're getting
more applicants because they are paying more.
And that's kind of the way the world works.
I'm not saying that I agree with it, but if you have deep pockets, typically you're expected to pay more.
So we have to take that into consideration as in we probably don't have to bid as high as Cardano does.
But at the same time, we're not getting the same level of applicants.
At the same time, we're not getting the same level of applicants.
So we do need to bid appropriately and make sure that we are in the ballpark to actually attract people to our ecosystem.
Let's see.
We are working towards a more perpetual treasury funding system, but we're not quite there yet.
When that does happen, we will have more funding. So that's something to keep in mind
as well, is that in the future, larger grants can be considered than they are actually today.
And this will help us definitely in trying to get more compensation to developers who are willing
to take that risk and build in a smaller ecosystem. Just as we've seen over the last couple of years,
there's a kind of like a force of gravity, you could say, to pull developers into larger ecosystems.
And that's because they're more established.
They have larger community to market to.
And it's simply, it's an easier sell than coming into a smaller ecosystem where you're at a higher risk.
risk. We've used the argument in the past that you could be a big fish in a small pond. I'd say
We've used the argument in the past that you could be a big fish in a small pond.
that while that is true, that is not really the reality that a lot of developers are facing
in terms of the risk they're willing to assume. Because when you look at some of the larger
ecosystems, there's more people for them to market to. And even though they're going to be
in some ways drowned out by a lot of
the voices that are out there all competing, the same times they know that that market is there.
Whereas if they go to a smaller ecosystem, they're putting in a lot of investment. And many times
they're investing the same amount into development for a product for potentially a much smaller pot. And it doesn't equate, right? It's not perpetually or
it's, what's the word I'm looking for? When you say big fish in a small pond,
the big fish just isn't simply as big as the small fish in the large pond, realistically.
So that's part of the reason that grants are there. We are supposed to be funding projects
to actually give them that early offset of risk so that they're willing to build and they have a larger chance of success and becoming ultimately more sustainable in the long term.
Because that's what we ultimately want.
We want sustainable projects.
We don't want a project that does great and then goes away two or three years because the market goes into a bear cycle.
We've done that. Many ecosystems have done that. That's not really a sustainable model.
And even though that's part of the nature of the beast in this industry, we want to do the best we can to build projects that are going to be around three to five years from now.
So anyway, with that said, let me pause for a minute because I know I'm doing a lot of the talking here. Does anybody have anything to add to that?
The kind of grants that you can offer are competitive within the framework and the context of the market as well.
And as you mentioned, a developer typically, and this is from my sort of conversations with developers over the years,
is a developer typically will go to wherever they're most likely to get traction and users.
Users is a big problem, generally speaking, in Web3 and Blockchain.
I say Web3, I mean, you know, crypto and Blockchain generally.
And that is a big challenge for smaller ecosystems because the tendency is just to move to...
People want to build things that they know will be used eventually.
And so the challenge generally for projects like CKB or other smaller projects
is this issue of retaining developers.
Typically you get, this might be kind of a tangent,
but typically you get developers or make an application or project on one chain, and then as they grow,
they reach like this glass ceiling almost, and then they have to
kind of spread their wings and go to other chains,
which sometimes detracts from the original, the kind of original
input and support that was given by the first chain,
if that makes sense.
And so I think generally, and even, so you mentioned Cardano, even Cardano had this issue
of like a lot of the developers in crypto generally kind of coalesced around Solidity,
EVM, that type of thing.
And then so to move to something completely different,
UTXO, Haskell, all those things,
was a big challenge even in the Cardano ecosystem.
And so they had to basically start afresh and start with educating and building developers
up from scratch who would then stay in their ecosystem.
That was by educating and teaching training pathways with Haskell for
example and Plutus and whatever they use now and so I think generally speaking to keep developers
or to have developers in our ecosystem they have to be the right fit in terms of almost like an ideological match, ideologically driven,
in that like they see that there is potential, intrinsic potential in the values of the chain,
and then it's about having the right product for that, to make use of those unique advantages
on that chain for example, and then if that's possible if that
materializes then then there's a chance uh maybe for some type of uh growth or or adoption uh later
on down the line but it's a much tougher tougher slog and it requires more long-term thinking
and so that's the tangent bit uh the only other bit I was going to say, Jordan, is that I think unofficially with the previous Dow,
we kind of almost had like an unofficial limit of about 100K in terms of the funding,
because you don't want a project coming in with a super large grant proposal just because of the size of the pot generally even though it was
quite a generous uh generous fund generally speaking uh 100k almost felt like well um there's
a certain amount of work you can do with that type of money and then if you need a second
grant you can ask for a second grant but it kind of of helps to keep the scope of the project manageable,
generally speaking.
And I think most ideas can be reasonably covered within that type of limit.
So I was wondering whether you thought there should be like, it's not like a mandated or
an in-protocol or, you know, in-the-rules type of limit, but it's not like a mandated or an in protocol or, you know, in the rules type of limit, but it's almost like a social understanding of, okay, you know, unless you really do need, you know, like 200 plus K, for example, then generally speaking about 100 K seems to be okay.
And then you can always be assessed by the community.
And then ask for a second one.
I was wondering what you thought about that.
Yeah, I mean, I think that this is one
that we can just work with general social consensus
and also work with perhaps bringing in, we can perhaps
some of these large projects that come in,
we can actually do a more formal grant budget review
in terms of like have somebody go out there
and do some research,
which they then publish publicly
before the grant is actually voted on
about what the industry rate is.
Because like in some cases,
it might be very much justified
that you would have a grant that is over $100,000,
although I think there's quite a few that
could be less than that.
For most cases, when I've been talking to teams that
are considering a grant of any kind,
I encourage them to do small things in smaller increments, which is like you can
roll things into one giant grant and then break it up by milestones.
That's one option.
Or you can just do multiple different grants.
It's really kind of the same thing.
But ultimately, I think just from a perceptual standpoint, it's better to have a smaller grant, a smaller general obligation,
and then have the process start over again when you're ready to do your second one.
And part of this is because when you're setting these large budgets,
there's so many... Well, if you're setting a large budget, it's going to be for a large project.
In a large project, it's going to be for a large project. In a large
project, it's going to take more time and more manpower to actually deliver a product. And so
when you actually deliver on this, which is in most cases going to be maybe eight months to
18 months, it might take some time. Things in the industry may have changed, things in the
ecosystem may have changed, things in just the product that you're developing you may have had to redesign them
in certain ways so just to avoid the formality of having to come back to your your proposal and
say you know if you've made it halfway through saying you know we we did milestones one and two
but milestones three and four don't make sense anymore. We're going to have to change this. Why not just start out with just doing milestone one and two in the beginning,
the parts that you actually know are going to happen with a smaller grant amount, and just
coming back and do the grant process again for the second one. I think ultimately for teams,
that's an easier lift. You want to state what your actual end vision is, but have a smaller grant.
Just the community would be, I think, more in favor to give you that small grant on something
you know you can accomplish within a smaller timeline. As long as they know it's building
towards something bigger, they're going to reinvestigate and issue that second grant when the time comes. But don't put the entire effort into something that could change so much in an industry like ours that's so rapidly changing.
Yeah, I agree basically what you said.
I think having a social limit, if that makes sense, gives
the opportunity for the community to kind of come back and just reaffirm that they support
what's happening. And it means that the project there is kind of built in accountability in
the project, but they kind of have to make sure that things are that were promised are delivered um yeah i had another thought about
this but i'm not uh kind of forgotten it but i think that's i think that pretty much uh covers
it covers that is there anything you wanted to mention kevin or
Yeah, I do agree with kind of how Jordan put it.
yeah just that i yeah i do agree with uh kind of how jordan put it um
From a community standpoint, you're more likely, a project is more likely to get there, you know, continue the grants.
If, hey, we know A, B was the first part.
Look, we've completed all the, you know, requirements on that.
Here's what we've built.
Now we need this grant for Part C. Obviously, they're going to probably get
over with the community more to get that passed. As we've seen in the
past, sometimes something gets delayed and then everybody kind of gets in
an uproar and kind of loses their confidence
in the project and what they're building. So definitely
like that idea of the smaller milestone type
sections. Obviously, once they prove it, more likely
to get votes passed to continue whatever they're building.
All right. So let's see. There's a few more things I can
add on to that. I mean, definitely,
we have an industry where it's very global. So we can have teams from all over the world.
And one of the things that's been brought up specifically around budgets is where the team
is actually based. Are they going to be more competitive from a financial standpoint?
And this is an interesting topic because I've seen arguments on both sides
and I've seen both sides of the argument be true in different cases.
So I want to take one of the...
I've worked, just so everybody's aware,
I've worked with outsourced teams all over the world.
I've worked with ones in European countries.
I've worked in ones in Asian countries.
I've worked in ones in South America.
I've worked, I don't know if I've worked in any of Africa yet, but, you know, maybe someday.
But anyway, I've worked with teams from all over different regions.
And I've seen good work and bad work come out of every single region.
But one thing I've seen that's been fairly consistent is that when you see an advertised low rate from one region of the world, it's not true.
it's not true. And I'm speaking like one of the places that I think was in my personal experience
has been notorious for this has been India. This is not to speak poorly of India in any way. I'm
just saying that they gave the lowest teaser price pretty consistently. I think second place
might've been South America. And again, like good and work,
bad work has come out of most regions that I've seen.
But when you have this teaser rate,
if somebody is saying I'm a fantastic developer,
I'm gonna work for $15 an hour,
I'm gonna tell you right now that's not real.
Okay, so if somebody comes into the grant
with a really low price, that's not necessarily better.
You have to take that into consideration. And the opposite is true. If somebody comes in with a really low price, that's not necessarily better. You have to take that
into consideration. And the opposite is true. If somebody comes in with a very high bid, that's not
necessarily a super qualified team either. You have to actually evaluate each one of these,
and we should be looking at every single proposal and scrutinizing it regardless of whoever submits
it. So the team's track record, of course, that has to be taken into account. A team that has a well-established track record for success is probably going to demand a little bit more. We should be taking that into account. Does that actually make sense in the scope of what they're trying to do for our ecosystem?
with this super low teaser rate,
we need to look at that and say,
is it actually a good deal?
As in like, we're putting money into somebody's team.
Are they going to deliver a product
that is of value to the ecosystem
in a way that matters?
And what I'm saying here is like,
let's say that there's a team
that has a really low price tag
and a team that has a higher price tag
on the same exact promise of the product
that they're going to deliver.
Is one team going to actually execute on this product? And this doesn't mean just development.
This is the development, the launch, the ability to market, and the dedication to the product to
keep it going in the future. There's a lot to consider. You can't just look purely at the
price tag. And I think that's, from what I've seen, that's one of the things that gets scrutinized
the easiest in our DAO system right now
because it's one of those
that's easy to look at.
You just see a number
and from that,
that's an easy point
of quantization
where the rest of it
is very hard to quantify.
How good is this team?
How likely are they
to be successful?
So we do need to look
closer at that.
And I think that the new system that we're putting together
with delegates is going to help with that,
because the delegated representatives are actually
going to be able to look into this,
and they're going to be a little bit more experienced
in the way that they are just determining
if these bids are actually good for the ecosystem or not.
Are they providing good value?
So I'm going to segue that into the next part, which
is team autonomy.
Now, this is one that I have some pretty strong viewpoints
on, and this is coming from the standpoint of what actually
makes sense for the DAO versus what actually makes sense
for a company.
So one of the things
that has been brought up is should we be demanding that these teams disclose what their hourly rate
is in terms of for compensation purposes? I think the answer to that is no. And I'm going to tell
you why. It's because they're not working hourly, number one. And number two, they are not working for the DAO specifically, as in
they are not employees of the DAO. The DAO does not watch over them. The DAO does not get in
their meetings. The DAO is not part of their team. They are doing performance reviews. It's not
managing their staff at all. What does it actually matter what they are paying their staff internally? Like that's not the point of the, that's not the concern of the DAO.
The DAO is, did they produce the product they said they were going to do and provide significant
value to the ecosystem at a fair price, right?
It's value in versus value out.
It's not what they actually charge.
And again, this comes back to my work as working with various teams
across the world. When I've been doing business with certain teams that claimed a low hourly rate,
from what I could see, a lot of the time that hourly rate is not even honest, right? They're
claiming like we're charging $15 an hour from the work that they put out. They were probably
charging close to 75, just in the example I was put out they were they were probably charging close to 75 just
in the example i was i was actually doing because they're saying saying one thing they're you're but
nobody's watching over them right you're there wasn't actually good value coming out because
they're saying this low hourly rate i don't think that they were working that whole time right it
was part of my job in the past to actually go in and help salvage projects that were failing. And there was several cases where I found out that the team was claiming all of these hours.
And it just didn't add up to the work that was being produced.
You know, so anyway, it's just an unfortunate thing that sometimes in this industry, when the money's involved, people lie, right?
Like it shouldn't be a surprise to anybody that people in crypto lie sometimes.
Like, it shouldn't be a surprise to anybody that people in crypto lie sometimes.
Well, you know what?
When you have teams in different countries across the world and they have no oversight over them because they're managing their own team, you have to hold them accountable by making sure that they are producing the output that you require for the total price.
But the hourly rate is rather meaningless.
So let's see.
So, and again, like for most grants, which are fixed sum,
the internal hourly rate doesn't matter at all.
It's, why is that even relevant, right?
Because like, it's just a big estimate anyway.
Like one of the most difficult things for developers to anticipate the actual number of hours.
They could be very easily over or under. So just the projected hourly was rather meaningless
as well. It's really just like if they were actually doing a job on an hourly basis, which
I think is going to be very few of the grants, then yes, they should be disclosing that 100%
because that's an appropriate case.
But in most cases, we are dealing with teams that are operating autonomously for the most
part and we can't be watching over them.
Oh, yeah.
Neon, did you have something?
Yeah, I was just going to ask, so from your perspective, you are you saying that like i'm assuming obviously there
should be a breakdown so if a grant is requested there should be a breakdown of uh what the grant
money will be spent on um and then you know it kind of in general terms as like a mention of an allocation to cover the cost of,
you know, team members time, for example, but it doesn't need to go into like the specifics of that.
It's just kind of like, this is how much we need for our time.
And then kind of you think that does or doesn't need to be mentioned,
or is it kind of just generally just more vague?
It's kind of like, oh, you know,
this is what we've calculated as an overall type of grant request.
I just want to get clarification on where you kind of draw the line.
Right, right.
Yeah, I mean, that one, it's kind of tough there
because I see that as being something that is completely up to the team,
more or less, on what level of detail that they want to disclose.
If they want to open their books entirely, by all means, they're welcome to do that.
It's just from my experience in running development teams is that there's so much of that that
is just basically estimated at a point.
You have to assume that every team is overbidding to some extent, right? They calculate what they think is going to take the job,
and then they mark it up a certain percentage
because they know there's going to be certain unknowns
and certain problems that come up along the way.
And in our ecosystem in particular, that has been the case very much so.
Almost every team that comes in is hit by something that they didn't anticipate, and it slows them down pretty significantly during some point of the development cycle.
So these types of things, like you can't, like if they are, let me put it another way is if they said we think this will
take x number of hours um developer hours and they are they try to hold to that it's almost a
certainty that they have under budgeted their project um because i just know that in our
ecosystem you hit problems i mean in every ecosystem you hit problems. I mean, in every ecosystem, you hit problems.
So like a breakdown and stuff of what they generally want to spend in different segments,
like maybe they've allocated a fair chunk to marketing or something.
These are all reasonable things that I think that absolutely should be included in the proposal itself.
Because like development could be a big part of it.
Maybe this is a particular project that does require a significant amount of
marketing.
And if they've been able to articulate that in their proposal in a way that
really makes sense, that should be in there.
And that should be,
and giving a percentage is absolutely completely appropriate in that case.
What I'm more getting at is if they say that we're going to dedicate three months
to this project and we need X number of thousands of dollars, I just don't feel that it's
appropriate for us to go into there and start hammering it down with the anticipation of
knocking down any potential for them to make a profit off of this.
Especially as I've seen in the past with people who are not necessarily familiar with development.
It's not appropriate.
We have to anticipate that these teams are trying to make profit and they're trying to survive in our ecosystem.
If you give them no margin, they're not going to be successful, right? You are working against our ecosystem in that sense. And so anyway, it's like
when you look at all, there's so many little variables on this kind of stuff, you'd have to
kind of just zoom out from it and say, what is the DAO supposed to do, right? What are you supposed
to evaluate? We are not supposed to micromanage teams.
That's one thing we absolutely don't do.
So it's value in, value out, right?
What are they producing?
Is that fair for the market?
And if we can justify that,
that's how I think we should be making most of the decision.
Not necessarily who's involved,
but can they actually deliver on it?
Not have they actually, have they made an
effort, I think is less important than if they have actually done what they said they were going
to do. And at the same time, there's been, I think within our ecosystem, we have not rewarded those
who have been loyal to our ecosystem quite enough. And I think that the ones that have truly been around,
we should be a little bit more generous to them
because we are seeing two different motivators coming here.
The motivator to make profit,
but also somebody who's been motivated
in our ecosystem regardless.
Whereas like, if you want to just throw big numbers around,
we can attract half the world, okay?
But to our ecosystem with a limited budget,
we can't do that.
We need to be rewarding people who
have genuine interest in our product.
Yeah, Neon, I see your hand is up.
Is that from before?
Do you have something to add?
NEON NIEWENZERJANI- No, it should not be up.
That's just a bug, I think.
But yeah, I agree completely.
Precomplete voice.
OK, I agree. I agree. Pre-complete voice. OK, so anyway, yeah, I think as just a general rule of thumb,
I wanted to put in there something,
a clause about everything over $50,000.
Any grant above $50,000 should require a budget review
by an industry expert.
Somewhere in there, I think, is a pretty reasonable number, in which case we would just be provided with a number that's a
little bit more appropriate of a guideline so that the representatives don't have to do quite
as much work individually reviewing every single product. Absolutely, that's redundant work.
reviewing every single product, it's absolutely, that's redundant work.
And I think that'll give a little bit more visibility just to the public in general on
what is actually the industry expectation at that particular time, which is, like we've
mentioned before, this is something that floats all over the place and it's changing all over
over the time what was what was the truth six months ago may not be the truth today
the time. What was the truth six months ago may not be the truth today.
yeah i think it depends on i guess certainly if like in the future there's um the whole process
is scaled up and there's a lot there's a lot of stuff going on there's there's um i guess
and there's a lot of there's a lot of stuff going on there's there's um i guess um a number of
proposals then you do then it kind of makes sense for there to be reference points in terms of what
the market going rate is um and i think the problem is is there's sometimes a tendency to maybe
over engineer that because I'm thinking
about that then I'm thinking my mind kind of goes to okay well you know if the team really wanted
to kind of get a grant through for example they could try to persuade whoever this kind of
independent professional person is or whatever in which case you need like, you know, like rotating or like multiple different
points of contact that you can use and then want to select it randomly or whatever, this type of
thing. But like, I think I agree with the general principle that delegated representatives, which we should probably touch on soon,
may need some additional expert insight into some of these things when it comes to costs and rates and that type of stuff.
Okay, so I was just looking at time.
I see that we actually used quite a bit of time on that topic.
We should probably move on to the next one. So let's see the next one being voting power calculations and lockup requirements. that we are allowing as many people as possible to participate.
But at the same time, we need to try to get high quality participants.
And we're trying to create an environment that is less biased and less prone to politics in general.
And so there's a lot of things that you kind of have to end up balancing out.
So with the current community fund DAO, the way that it works
is that you must lock your funding in the DAO, which has a 30-day lockup period minimum. And
once you're in there, you're able to do two things. You get the 2% DAO compensation, and you
also get voting rights if you choose to participate in the DAO. And from what I've noticed so far is
the, in talking to several of our community members, the 2% DAO compensation is not a
significant motivator for most. In terms of like, there's, we have quite a few people in our
community who are active traders, and they are absolutely, 100% dedicated to our ecosystem.
And they continue to hold our token, but they are actively trading it around on a daily basis.
So the 30-day lockup for them is an absolute no for them.
They will not do it.
And I think this is actually a little bit more common than we would actually suspect
a little bit more common than we would actually suspect because the 2% lockup is prohibitive from
doing so many other things as well. It's just like when we had Yokai was up at its peak,
people were doing various types of pools, liquidity pools to actually generate some yield,
get the yield farming. And that was something that was not
possible if you were locked up in the DAO. And another one is to get voting rights. That's
important to some, but it seems like in general, most people are not too interested in voting. So
when you add in this extra barrier to entry, you're absolutely not going to encourage them by saying, oh, we'd like your vote.
And by the way, you have to lock it up and you can't do anything with it.
It's not working too well is what I'm saying.
Our incentives for participation are not working very well with the current system.
system. So to rectify this, the new model that I've been suggesting is that we open it up not
only to those who are locked in the DAO, but also to unlocked CKB holders and also to ICKB in the
future, because that is a token that is very much the derivative of CKB. And for anybody who's not
familiar, ICKB is a kind of like a liquid staking token in some ways. It would you be trading with CKB
when you could be trading with ICKB,
which is the same thing,
but also giving you a little bit of extra interest.
I could actually see this being as the main token
that's used in our ecosystem in the future.
And if that is the case,
do you want participants from those holders
to actually be able to participate in voting?
And I think the answer to that is yes.
So I'll pause here for a moment just in case anybody wants to jump in.
Yeah, I would just be pleased, Jordan, is it the case that you should have, so I think it's a good idea to have voting rights to unlock CKB,
generally speaking, because I think with the current system, if anyone really wanted to vote,
they would just lock straight away.
It kind of is almost besides the point.
Anyway, what's the point for locking it? You've done your vote and now you kind of just have to the point anyway, what's the point?
Blocking it, you've done your vote,
and now you kind of just have to wait for an unlock, for example.
So I think the kind of incentive there is a little bit,
it doesn't make sense as much. So it seems more the case that you should have unlocked.
But if you have unlocked,
if you allow voting rights for unlocked CKB,
then is there a potential issue of someone...
In which case, I don't think you should have
voting rights for locked CKB.
You could have voting rights for ICKB,
but if you had voting rights for, for example, a locked CKB and then could have a voting rights for ICKB, but if you had voting rights for, for example,
a locked CKB and then ICKB on top of that,
it almost seems like two bites of the cherry,
if that makes sense.
So it would make more sense to have unlocked and ICKB
or unlocked and locked, but then not ICKB
because of the fact that you have a derivative of existing CKB.
So it almost seems like one or the other, but not both at the same time.
That was kind of my question from that perspective.
Well, yes, it would not be at the same time, if that's what you're asking.
you're asking if something is locked in the DAO, which then is issued an ICKB token, then
If something is locked in the DAO, which then is issued an ICKB token,
the DAO locked version of the token cannot be counted in the DAO. And this is pretty much
inherent to the way the system works, because anything that is locked up in ICKB in particular
is going to have a very particular address associated with it that is not claimable. There's no way to associate that
address with the voting system because it's just a smart contract. And so anyway, once it's a
deposit in the DAO, well, if you deposit in the DAO yourself, then you can vote with it. If you
deposit it in the DAO to make ICKB, you can only use ICKB. So that kind of solves that. There's
no double counting in any way. But the one issue that is worth discussing is with unlocked CKB in
particular, what happens if somebody wanted to sway the vote? And so what they did was they moved in a, they went and bought a huge amount
of currency, a huge amount of CKB just to do their vote and then immediately moved it out again.
Could they be able to sway the vote? And so that's a genuine concern. And I think that was
part of the motivation behind the 30 day lockup in theervos DAO to begin with. So the way that
we can get around that pretty easily with this system while remaining liquid is to actually
just use the age of the UTXO itself. As in, if you have unlocked CKB, then we look at the age
of the UTXO and see how old it is. If it's brand new, it actually has zero voting power.
Then it gradually gains voting power up to 30 days.
And 30 days is the number in particular because that matches the Dow exactly.
So you're saying that if anybody decided to borrow a tremendous amount of CKB to try to sway the vote, it wouldn't do them any good in the very beginning.
They'd have to hold it a full 30 days before they would get the same voting rights as somebody who had blocked it in the Nervos Dow.
It's perpetually exactly the same. The things that I like about this system is not only does it protect the system, but this doesn't introduce any new experimental mechanisms or what's called in our industry magic numbers.
A magic number is when you say an arbitrary value and it just has special meaning to it.
In computer science, we generally try to avoid these because they tend to add
problems down the line because there's no no real reason for it for example the 30-day lockup
is technically 180 epochs in our system and that itself is is it is a magic number
but that's a pre-existing magic number right that was that's baked into the foundation of ckb and
i'm sure there are some
reasons behind that, but we don't want to introduce more numbers. Like I'm not going to say
we want to lock our thing up for seven days to get full power. Like why seven days, right? There
has to be a justification for this. You have to actually introduce a reason for this. So
the 30 day numbers already in our system already as a magic number. Let's rely on the existing numbers
that we can't get around no matter what.
And that gives us a good basis for building upon.
And so let's see, I just heard something.
Did you have something to add to that?
No, I was just gonna say that's a really good way
or it might be that's a really good way
of allowing CKB to a representative,
for example, a delegate, then is there,
I'm assuming that CKB is, is it still liquid?
Is it like in a smart contract of some type or,
you know, has there been any thinking around that?
No, it doesn't get locked up.
It would actually remain 100% liquid.
And what's actually going on is when you cast your vote, this is an off-chain process.
And it's symbolic until the actual counting, which is done on a snapshot, which
occurs on a very specific block number. So when a vote is occurring, you have a final,
when does it actually end, right? And so as you see people voting into the system and everything,
those votes are being calculated, but they're actually just kind of estimates
until the very, very end.
Because people could be moving around their CKB.
They might have linked up to the system
and sent some CKB somewhere else, right?
They're spending it or something.
And so at that point, they have a slightly lower power.
And if they've delegated,
their delegate has a little bit lower power
at that very moment, too.
So the system has to watch a tremendous amount of addresses and balances over a course of time.
And it can't do this always exactly in real time.
So while the vote is going on, you're going to be able to see, you know, this side's winning or that side's winning.
And it's an estimate until the final real tally, which occurs at the very end.
And that does, once the vote, the voting ends, then, so that's when the system will actually
go through and recalculate everything at that exact block when it ended, look at all of the
final balances to make sure that everything was 100% in sync.
And the way that I would like this to happen is it would spit out this giant proof file that shows like every single vote, what balance it was based off,
and then provide all of the signatures that proved that this delegation had occurred
and that this vote had occurred, all of these signatures.
And this is independently verifiable by anybody who uses the,
there'll be a verification script of some kind that would actually,
ideally we would actually have multiple of these.
And I think this is something we could actually partially fund through the DAO
is that we can have multiple implementations to verify this file,
which will give us relatively high assurance
that no form of fraud has taken place in any way, shape, or form,
because you'll have all the proof data all there.
And anyway, this is a, because you have to do this process
of delegating to a representative, and the wallets
have to all synchronize and make sure
that they're counting the power towards the correct delegate and all this. It's relatively intensive in its
computation. As far as blockchains are concerned, this is not appropriate for a node. We don't
necessarily want this to be a burden on the nodes. So this is something that's done off-chain and remains fully verifiable.
And it doesn't have to happen in real time,
because once the snapshot is taken,
at that instance when the vote tallies,
now you can take your time in processing it.
Realistically, it wouldn't take more than a few minutes.
But it's like, you can take your time
in processing this kind of stuff and be assured that the results are 100% accurate.
And this one more thing I just kind of want to tag on there.
The reason part of the reason that I opted for proposing this type of a method is because it makes it so much more flexible on what we can do in the future.
When you do fully on chain voting, you were relative.
You were limited to a relatively simple system.
I wanted us to have a system that could over time evolve and introduce more types of voting methods.
And by taking this off-chain approach to it, we are still, of course, we're relying 100% on the
state of the chain. We are doing voting that is completely provable by the data on the chain.
But the actual voting mechanisms can become much more complicated, much more robust because
we're using off-chain systems.
And that's one of the things that CKB was founded on is that principle that we can use
off-chain systems as well and we can do a lot of work.
Just because you can put something on chainchain doesn't necessarily mean that you should.
That's kind of one of the rules of blockchain.
That was one of the mistakes that I see a lot of small teams make that are not that experienced
is they try to do too much on-chain.
Keep what's absolutely essential on-chain, and that's exactly what we're doing,
but let's move everything that we can off.
Let's make sure that the burden on the nodes is low.
Let's make sure that we get the best absolute system
that we can build by using the technology
that is available off-chain as well.
So let me see.
There's one other thing I just thought of
that I wanted to mention, which is the stake amount.
Yeah, the amount of the stake determines your influence.
That's one CKB equals one vote, more or less.
The one thing that has been brought up a couple of times was,
Nian, I see your hand up.
Did you have a comment to throw in there?
Yeah, I'll let you carry on though and I'll just chip in at the end.
Okay, sure. One other thing that has been brought up by
a couple of people to me
was that they wanted to see long-term holders
get more benefit in the voting, right?
They wanted more voting rights for long-term holders.
And while I share the sentiment of that
and I absolutely understand
what is trying to be done with that,
there's no practical way I can think of
to implement this effectively. And so no practical way I can think of to
implement this effectively. And so this is why I'm kind of against that. And let me, if I can
articulate, hopefully I'll be able to articulate this correctly. It's like whenever you give a
benefit to somebody who is trying to do good for your ecosystem. These are generally benevolent dictators in some sense.
If you give a power to one person who you believe is good, you are opening the door
to give power to somebody who's trying to negatively impact your community.
And so giving it to a long-term holder, while it seems benign, at the same time,
you've got to remember that you're not going to agree with everybody.
And not everybody should be trusted by default that their judgment on every topic is correct.
It doesn't matter how long you've been a holder.
long-term holders to have a very significant amount of benefit. Over time, you may actually
introduce a plutocracy where you have a large whale or a couple whales or whatever who have
been long-term holders and they now have almost the entire influence over and control over your
DAO system. I don't think you want that. Just because somebody is new to the ecosystem doesn't
mean that their ideas don't matter and they're not good ideas.
You've got to leave room for change when it's necessary.
So anyway, that's kind of the short of it.
Every time I thought about this and I did try to think of how could we give people who have good ideas and have been long-term holders, can we safely give them more voting power?
I couldn't really figure out a way to do it.
So I've kind of shifted my thinking
and I'm no longer really in favor of that.
It's just basically one-to-one.
If you're a holder, you have the same voting power
as anybody else.
With, of course, with that 30-day lockup thing
we talked about earlier, right?
Like if you're liquid, you got to hold for 30 days
to have that power or you got to put it in the dow um but other than that i think
it's pretty straightforward there we don't want to necessarily give undue influence for any
particular group of people yeah so i was going to ask j about the, so I think generally that's the right thing in terms of like long-term holders beyond like the 30 day, for example.
I think if there's generally speaking a level playing field, I think what it does do, it keeps things open and welcoming for people who are relatively new, who've maybe not been
around for years and years for example, to still have an equal say, generally
speaking, as it is really based on obviously CKB voting power in that sense.
I was going to ask for the 30- lockup is the relation, is it, is the kind of the relationship between voting power and,
age of the utix.
So is that like a linear relationship?
Is it like,
like a logarithmic one or is it some type of,
is it basically like a simple linear relationship?
was my first question and I'll start with that one.
Then I'll,
I'll finish off.
Yeah, yeah.
I mean, I think it should be linear.
I mean, absolutely, if anybody feels differently
that it should be something like a logarithmic,
I'd be willing to hear that out.
But I kind of see it as just a linear thing,
as there seems to be a proportional relationship that's
pretty easy to grasp if it was linear.
Yeah, I think so.
I think, I mean, yeah, it's, I don't really see a strong argument for anything other than
linear generally speaking.
I was going to say something else about that.
I mean, like the idea of off-, off chain doing most things off chain,
I think what it does do. And like, for example,
like with an, if it was like a fully on-chain system, in theory, you can still change your vote.
Um, I assume like halfway through or, uh, something like that. Is that, is that true?
Yes. You could, you could design something that was on-chain
and absolutely you could change your vote partway through.
I mean, a lot of the things you can, it's really the, let's see,
with on-chain voting, one of the biggest things,
the downsides is that it is once you you change some once you implement
something it's very hard to change it and it's just in general it's much harder to add new features
it's it's like the lack of flicks of flexibility is one of the things that i didn't really like
about those systems and um so part of what we're doing here is like this, this entire Dow proposal that the way
that I wrote it, everything that I've tried to do has been on the basis of trying to keep
it simple, trying to keep it easy to understand, because I want to guarantee that we get something
for our ecosystem that works properly and is realistically feasible in the timeline
that we have to do it.
Um, I didn't want, there's all all kinds of crazy ideas about there, about all these
systems that are really, really flashy or really complicated and have these algorithms on all the
voting and stuff. While those are interesting, they're also highly experimental. And this is
why I shied away from all of those types of approaches, because this is not the project
to test these things on, in
my opinion. We need something that works for our ecosystem to ensure that we have a future.
We can do sub-DAOs in the future. If you want to do something experimental, there doesn't
have to just be one DAO. We can absolutely experiment with other systems. But I needed
to know that we have something solid that we can build on in the future. So everything I've been trying to keep is, I'm always leaning towards the simpler side of things.
If it's easy to understand, if it's simpler, if it's something that we can reasonably project is going to be successful, and even if it's not the optimal part in theory, right, I'm still leaning towards the simple.
I want to make sure that we have something established
in the nearer future, sooner rather than later.
Okay, cool.
I mean, that makes perfect sense to me.
I'll finish off with one thing,
and then we can move on to the final one.
With off-chain processes,
and I think that makes sense.
My only thinking was,
I guess if you have a type of design
where it's kind of showing you
as the voting process is happening,
some type of estimate,
I think in some ways that can be
open to gaming as well.
My idea is kind of
maybe what the
tally should be. There shouldn't
be a tally at all. It should be hidden
until the final snapshot.
the reason for that is incentives
number one, to make sure everyone who wants to participate does
vote. Sometimes like if you kind of, if someone really wanted to gain that type of vote, they
could, for example, like, you know, vote yes to something and go all in on the yes. And it's kind
of basically like 95% and it's really heavily voted in favor yes,
and that kind of stops other people voting yes
because they think, okay, the vote is already kind of decided
and, you know, there's no need to kind of pile in on that.
And then, like, at the last minute, they can change it to a no
to torpedo the vote, if that makes sense.
It's kind of just like weird game theory type stuff
based on this kind of prediction system or something that kind of shows an ongoing tally
as things are occurring. And in some ways, maybe like a hidden system makes more sense.
I don't know if you have any thoughts about that. Yeah, that is a valid concern in some respects, and I don't know that there's an easy way around
that. I mean, with the vote, somebody changing at the last minute or voting at the last minute
is always a potential thing, and ultimately, more participation is what is going to get us out of that. And that's
part of the reason why we want to open this up to unlocked ICKB and CKB as well.
Try to encourage more people to vote just in a general sense. In terms of getting more the
gamification of something, I think that in the future with this system, a very large percentage, probably 90% or more of the votes are going to be occurring by the representatives.
And in that case, I don't think you're going to see too many of those games being played because in most cases, it's not going to be something that is, I mean, these people are
delegated to because they're supposed to be responsible, right? So if they started playing
games at the end or something, there'd be a big problem there and they'd probably lose all of
their delegation very quickly. And so in this system, this is one of those where there is no
obligation to delegate to anybody and you can remove your stake from
them immediately if you wanted to. So if anybody is showing some signs that they're not
acting in your favor, they're at risk. They're at risk from losing their voting power immediately.
So anyway, yeah, I don't necessarily think that that will be too big of an issue,
although I'm absolutely open to hearing more about cases when it's appropriate to hold the vote,
doing silent votes or something. I haven't really thought too deeply into that one,
but there very well could be justifications for that.
Yeah, I think as you say, once you have delegates who are the majority participating on behalf
of other people, then there is more of a social responsibility.
People are known as you can't really do that type of stuff.
If it's someone anonymous, for example, voting by themselves, then that's right.
I mean, this is kind of, you know,
really out there type of thinking, but
like, I guess
in theory, that type of stuff could happen.
But yeah, I think that covers
it for the most part.
Nice.
Quick point. Can you hear me?
Yeah, we can hear you.
Sorry, I dropped off a few times.
So kind of just to piggyback on what Neon said, I never really thought about that.
But, you know, the silent vote thing.
So, you know, maybe the goal of this, obviously, is to get more people to a partial space in the Dow, right?
So if you see the totals and say there's, I don't know, whatever, 10 million on the yes side and a million on the no side maybe you just go I only have you know 250
thousand CKB I'm not gonna vote it doesn't matter so maybe there is some
merit to not showing the results you know kind of how we go in politics right
same thing like my blood doesn't. Whatever state I'm in is already
always Republican, always Democrat, something like that. So that could incentivize, you know,
people to participate more. Just a thought on that. Yeah, yeah. And I agree with that.
My hope is that they have delegated at that point. If they're really that apathetic towards the actual issues.
And I mean, I can understand that because definitely it takes a lot of time and effort to review proposals.
I don't expect most of our community members will be willing to do that.
Many of them simply are not going to be qualified to.
And that's perfectly fine.
I don't expect everybody to understand all the subtle nuances of, of, um, of, uh, of,
of a proposal, especially a technical one. Um, you know, there's people working all kinds,
kinds of jobs. They got their own concerns. They got, they got kids, they got stuff they
got to do. Right. I simply don't think it's realistic for a lot of people to put in that
kind of time. And so anyway, if, if they if they are, if they're the type of person who is
unwilling to even vote on a simple issue that they do understand, because they simply don't
have the time or the interest, my hope is that this system will encourage them to delegate,
right? And delegate it to somebody who has their interests in mind. And that person should be able
to take the time. And that person should also be very much
willing to vote regardless of if they're winning or not. And that's something that we should
probably, maybe we should outline that definitely as a consideration in like the handbook,
basically, for a representative is that they should be encouraged to vote on everything.
And one thing that I want
to absolutely put in there is, let's see if I can remember this from memory. I want to have a
section on the delegate themselves on their page within the DAO that shows their voting history.
And this is going to show what they voted in favor of, what they voted against,
what they chose to abstain from. This is a willingful
abstain. And then what they also didn't vote on at all, right? They just, they abandoned that
voting opportunity. So you're going to be able to see this when you go and you look at any delegate,
including the ones that you have delegated to and see, is this person I delegated to,
are they being responsible here? And are they considering the issues that are handed? Are they participating enough? And if they're not participating and they're not
really giving justification for it, this is where it gets a little bit more dicey because you need
community members that are paying attention. But my hope is that they would then choose somebody
to delegate to somebody else if they believe their representative is not actually participating.
to somebody else if they believe their representative is not actually participating.
Okay, so I'm going to suggest that we just move on to the last topic here because we're already
a little bit beyond the time that we had anticipated. So the next one is down payment
policies. So we've had very few guidelines around down payments in the current DAO. And this is definitely something that a couple community members have brought up, and I think we can do better.
of $10,000 USD or more, then you must do milestones. And also in there was a clause that
if you request a down payment, your down payment cannot be more than $10,000. And this helps to
cover, of course, initial costs and also build mutual trust in the system. When you have a team that's coming into an ecosystem and they start doing work
of some kind, they generally want some guarantee that they're not going to walk away empty-handed.
I mean, this isn't just our ecosystem. This is business in general. This is oftentimes why
down payments are pretty standard in business and many large purchases is they want to make sure that whoever's saying they're
going to pay has put something up to make sure that there's something serious, right? And it is
a small percentage typically of the total amount, but it makes sure that they can't just walk away
and pay you absolutely nothing. So this is kind of a tough one, especially when we're dealing with this industry that
there's so many teams.
Some of these teams are even anonymous, and $10,000 is a pretty big chunk of money.
If a team came in and they requested a $100,000 grant, they got a $10,000 down payment, and then they did absolutely nothing.
Then they are, in theory, walking away with $10,000 scot-free, and they didn't do any work.
That's a bit of an issue, and I think that this is something that should be taken into consideration by the voters when they are looking at it and evaluating the team. After all, a well-known team with a reputation is probably not going to
risk their reputation for a relatively small amount if they're a very well-known team. $10,000,
that's not a very big grant, especially if they have a full team of people. They're probably not
going to risk it on that small amount. They're not going to try to do anything shady with that
is what I'm saying. Now, an anonymous team or something, that's a little bit different situation. Maybe they should
not be allowed to get a down payment. It's at least one that's so easily obtained, right?
These are different considerations that we should probably outline in the guide itself.
different considerations that we should probably outline in the guide itself. But I'm not inherently
against down payments. Although, you know, when this was brought up, I started thinking about
this a little bit deeper. And maybe there's actually a middle ground that we could explore.
And that has to do with actually just modifying the milestone system a little bit. Like what if we actually just said we don't do down payments,
but what we do is we expect you to kind of work your first milestone
into something that's very easily attainable.
And this is basically a down payment milestone.
And what this actually ensures is that they are in motion
and doing some work before they receive their down payment.
And this could be something that's very easy to define
and easy to achieve.
It'd probably be something just like the project reviewer
would need to be able to go in there
and they'd be able to see that the team was engaging, that certain internal discussions were occurring, repositories were created.
Maybe they could even check to see that, is code actually been started to run or design documents, right?
Something that indicates that this project is being moved on.
that this project is being moved on.
And once they are convinced that that's happening,
that's when the first triggering of the down payment milestone actually occurs.
Something like that.
So anyway, I'll pause here for a moment in case anybody has anything to add to that.
Yeah, I was just going to say, Jordan,
that I had a thinking fairly similar to you with this issue of down payment. My thinking
was in fact some type of escrow or something so that the down payment is actually paid on this
at the beginning of the grant but it's held in some type of you, some type of wallet by like a clerk or something to show that like, okay,
that the payment has been made, there just needs to be some checks and balances,
some approvals first before it actually gets released.
It might be, for example, you know, some indication that scoping has been done,
some preparations have been made,
or whatever the conditions are set, but then at least it's kind of like, okay, you know, it's the
team working has some type of reassurance. And I agree that this should be really more of a
consideration for anonymous teams. I think if it's generally a well-known team with a reputation,
a history, people of docs, for example,
then I don't see that as being as much of a problem
because there are opportunities for recourse, for example, if needed.
Whereas if it's an anonymous team, then I think, yeah, my idea was the escrow,
but having a shorter milestone at the beginning, for example,
is also another way to do it.
It's kind of, yeah, I think both types of designs work.
Yeah, I had also considered the escrow method as well.
The reason that I came a little bit more to the side of having a down payment milestone
was that if you involve any kind of an escrow service, there's typically fees if it's a
third party.
If it's not third party, it's within your custody anyway.
way. And somebody has to do this. Somebody has to do the review. Somebody has to set up the criteria
And somebody has to do the review.
for what is considered passing or not passing anyway. And so if it's really just the process
that the DAO has to set up all these things anyway, it might as well just do the last step
and just do it itself, kind of was my thinking Because like 95% of the work is there already.
We should definitely take into consideration that we want to make sure that the DAO itself
has a good record for payment. I mean, like there's no reason to really
doubt it at this point. Every obligation that the DAO has been responsible for
has been paid. And we just want to make sure that it stays this point. Every obligation that the DAO has been responsible for has been paid,
and we just want to make sure that it stays that way. When teams are considering different
ecosystems to build in, the possibility that they could go through this grant process, which is,
for most teams, from what I understand, they don't really like the process. In fact, I've
suggested many times
to various teams who are requesting funding that they go through the community fund out process,
and they're simply not interested in doing it because it is some work. They have to go out
there and they have to actually not only write a proposal, but campaign a little bit for it.
And a lot of them aren't really willing to do that. They would rather do campaign a little bit for it. And they, a lot of them aren't really willing to do that.
They just, they would rather do things a little bit more in a private sense. So anyway, what I'm
suggesting is because we are moving towards a system where it is going to be out there and it
is going to take a little bit more work for these teams and they are going to be putting themselves
out there in ways that some of these teams would rather not do in
the first place, let's not make it any more difficult by saying like, you know, you can't
even, there's a potential that you won't get paid or it's hard to get a down payment, right?
If as long as they are showing that they are doing a work and they've actually started, I think
that's a reasonable justification for them
to do what we see as down payments, which are pretty standard around the world in every single
industry. We need to make sure that we don't deviate too far from reasonable expectations
is what I'm suggesting. Yeah, I think generally speaking,
Yeah, I think generally speaking, like the policy around the down payment should be fairly lax.
But again, particularly so for projects that have a reputation. a project that's coming in with an application that will kind of be considered as part of the
as part of the actual DAO process and the voting process anyway.
But it's kind of just an extra reassurance for a team or people that are completely anonymous,
for example, may not have a track record.
for example, may not have a track record.
Yeah, I guess that kind of, it's kind of up to the community in that sense
that they've decided to trust that type of team with funds, for example.
But yeah, it's kind of where to draw the line and not to disincentivise people
from wanting to do it.
Because like you said, it's a hard process anyway.
And probably another discussion for another day
is kind of how to make that process easier
by having additional roles within the DAO
and that type of stuff.
But yeah, that was my thoughts.
Yeah, well, I mean, like one part of that
is absolutely the reputation and track record of the teams. I mean, and this is something that we ran into pretty, unfortunately, very often in the Godwoken Build Club grant program.
doing technical review on a bunch of projects. But most of the projects I was involved with in
some way, so I got to see peripherally what was going on, but I did not do the actual follow-up
with teams, and I didn't do most of the grant approvals. But one thing that went very wrong
on a lot of those was you had small teams that came into our ecosystem for the first time,
and they requested a grant. many cases it was a ten
thousand dollar grant which they were approved for they were paid in up front and they didn't do
anything right they or maybe sometimes they started but then they just lost motivation or
they moved on to some other ecosystem because they got another grant this is one of those things like
This is one of those things like you have to make sure that the incentive is there to actually complete the project.
you you have to make sure that the incentive is there to actually compete complete the project
And so like I operated a little bit differently.
There was a couple different ones where the grant, for one reason or another, it fell to me to review and structure it entirely.
And I never, I absolutely would never send money out the door unless I was extremely confident they were going to either do the job or I would structure it so there were specific milestones. And while I would say that not all
of the teams got to the final milestone, I never ever did I have one team walk away with anything
and not do any work. And that's because you have to structure the incentives this way.
And I think that, so anyway, this is something that's going to be outlined for sure in the guides, right, to take this into account.
But this is such a nuanced issue.
Like, we can't really do anything but outline specific, you know, some recommendations of what to look for.
But, you know, it's ultimately going to be up to the voters to decide if this team can be trusted enough.
All right. ultimately going to be up to the voters to decide if this team can be trusted enough.
All right.
And I think part of this is probably actually a good opportunity to mention the Catalyst program, Neon, since like you're actually trying to help with this process a little
bit.
Yeah.
So the Nervous Community Catalyst is a program designed to incentivize people in the community to be productive.
And one of the ideas about it is for people in the community to build up a record of work.
Or like a community proof of work is kind of how I phrased it before, is for people to kind of do stuff in the community at a very low entry rate
and low level of commitment and then start to build up from there.
So in many cases, people after six months or a year can eventually go to the community DAO
and say, this is what I've done over a period of time which you know it's like a
record of work it's like a CV it's like work experience it's to create and build trust in
the community that that person can then request a larger grant with more confidence in the
community that they'll be able to deliver it or that they will be a a good actor and working in their interests and in the community
interests as well because sometimes the question as you say Jordan has come up
like if someone appears out of the blue and there isn't much of a track record
to assess them by then it's kind of like people switch off a little
bit and and are like well you know we really can't judge whether or not you'll be able to do it so
it's almost like a gamble it's like you're taking a punt as to whether they'll actually deliver on
that and one of the goals of the community class list is to number one create people create
productive community members who are already CKB supporters and want to spend more time doing the things that they love and to be rewarded because they deserve to be rewarded.
But also to build something greater and to have a plan which can then be validated and voted on by the community later on.
So, yeah, that kind of segues quite nicely to that.
All right.
So anyway, I think that's probably all I have here on that.
And we're a bit over time as well.
So unless there's anybody, this is your last chance
to chime in if you have anything to say.
And of course, if you're listening to a recording of this
and you have something to say, you
can reach out on the Nervous Talk forums
or send us a DM to one of us.
And we'll be sure to listen in anything
that you are concerned about or whatever you had to say,
whatever your two cents were on the topic.
Let's see.
So anything else before we wrap up, Neon?
No, nothing from my end. I'm just looking to see in the comments if there's any questions or requests to speak. I don't see anything at the moment. But as Jordan said, you can
find us on Telegram, t.me forward slash nervous nation, or NervousTalkForum talk.nervous.org to ask questions or to follow up on anything.
I'm sure there will be future discussions anyway regarding this, but from mine, that's pretty much it.
Okay.
Well, in that case, I think we can call it then um yeah this has been a good discussion
and um hopefully uh let's see so let's see when we'll probably do the next one in a couple weeks
you think yeah i think so i think every two weeks uh works uh pretty. It gives people time to digest.
And I know there's been some content created out of the spaces in the community,
kind of summarizes the discussion points, which is really actually very helpful and great for the community, I think.
So I think two weeks for the next topics would be great.
All right, perfect.
All right, well, what do we call it there then?
And let's see, we have a,
for anybody who is listening now,
we have the hard fork coming up in 10 hours,
Nepo hard fork.
So hopefully everything will go smoothly.
Get your champagne bottles out.
All right, anything else, Leon, or are we done here?
No, I was just going to say,
I updated my node earlier. I actually had to
re-sync from scratch because
I had one of
Phil's custom nodes made
and I messed up
something.
I started two
days ago and it's
about to sync probably in the next couple of hours
so I'll be ready for the for the hard fork so um yeah excited yeah perfect perfect yeah i just updated
my notes as well i was pretty late on that because i've been so busy with other stuff the miner
updated now too and i see on the hard fork countdown 10 hours and 30 minutes approximated
99.45 percent of miners have now updated updated so we're in good shape it should
go very well yeah onwards and upwards um awesome great so i think we'll call it there uh thanks
to everyone for listening and uh we'll see you next time all right thanks everybody all right
