Secret^3: Community Continuance of Secret Network L1

Secret Governance
21

Because of Secret’s design, the chain can halt merely if not enough emergency signers remain in the active set. Secret Labs designed that part. They know what concentrating voting power does. They already showed it, by parking Labs-affiliated weight on one validator. That validator went down last night for a period of time, and the chain stopped producing blocks until it came back online.

I’d like to ask if you understand the situation, specifically, the consequences of no steward remaining who has a stake capable of properly capitalizing new organizations, and on a technical level, keeping the chain running period. People are not going to remain running validators at a loss, for an abandoned chain.

And I do understand where you are coming from with dilution, but Secret Labs created this situation, and they put the chain at permanent risk with their actions unless an organization is capitalized properly. Many of us are willing to continue the chain, we have the help and eyes we need, including some of the original developers who built Secret Contracts. Also, If you are actually the singular address that accounts for 92%~ of the no with veto vote, then you are indeed a “large stakeholder”, but I’m not convinced thats you. Happy to discuss either way, I’d like to clear up your confusion about the chains ability to continue in its current state.

22

Hi Lisa — thank you, this is a substantive reply and it moves me on two of the three points.

>On marketing vs. security

“Dollar amounts don’t necessarily reflect priority. […] Marketing is just expensive so a smaller budget is useless. Either we have the funds to do good marketing or we skip it entirely.”

You’re right and I’ll withdraw the inference. A marketing budget is lumpy and elastic; an audit budget is parametrized. Reading relative priority off the dollar amounts was a shortcut, and your explanation of how the two behave in practice is convincing.

One narrower version of the point survives: in the lean scenario — the one describing behaviour under constraint — marketing, events and community still total $300K against $200K for security. If marketing is the elastic bucket, I’d expect lean to show that, and it doesn’t quite. Minor, but worth a look.

>On Core Development

The quarterly mechanism, milestone evaluation by an independent committee, and retention of excess in the bucket is a real answer and more than I was asking for. Two things remain.

“The above is not in the proposal itself, but will be covered by the contract between the core dev team and the foundation.”

So holders are approving 299M SCRT whose only constraint lives in a contract that doesn’t exist yet, between two entities that don’t exist yet, one of which administers the other’s allocation. Everything you described is reasonable — which is exactly why it should be in the document people are voting on, or at minimum posted as a public commitment before the 19th. The terms you listed would fit in a paragraph.

Second, on this:

“But like all of the buckets, Core dev gets the voting power of the full allocation pre-vesting. This is the equivalent of the ‘Seats, not names’ fallback, where there’s no repurposing of the bucket.”

I don’t think those are equivalent. “Seats, not names” guarantees a vacated seat is picked up by another operator and the allocation is never repurposed — it’s a constraint on the allocator. Voting power over unvested tokens isn’t a constraint on anyone; it’s discretion exercised over tokens not yet earned. The quarterly disbursement mechanism is a genuine safeguard — I’d just describe it as such rather than as an equivalent.

Also worth flagging plainly, since it wasn’t in the tables.

“if the core dev allocation does not cover the amount needed due to token price fluctuations, the foundation can supplement from the R&D budget”

That makes R&D fungible into Core Dev, which puts Foundation, Core Development and R&D — 670M SCRT combined, 46.4% of post-mint supply — under a single administering entity, before the Ecosystem Fund. I understand the operational logic. It should just be stated.

>On advisors

“This bucket is meant for the life of the chain, while the remediation is a one-time event. Different calculations.”

Fair, and I accept it as a structural answer. The comparison still lands awkwardly — unnamed advisors at 72M SCRT against 44M SCRT for victims of a ~$4.67M loss — but I take the point that the two are calculated differently.

>On the Ecosystem Fund

This is where I still can’t get comfortable, and I’d push back on one sentence specifically:

“It’s difficult to put process and governance on this because we don’t know what the opportunities will be. This is an area where the trust of leadership has to come in — I don’t know another way to configure it and still protect the future of the chain.”

There are several, and they preserve exactly the flexibility you’re describing:

  • A threshold, not a process. Grants below X are committee discretion with no friction. Above X, community governance signs off. Big partnership opportunities are rare by definition, so this costs almost nothing operationally while covering the cases where a large share of the fund could move at once.
  • Multisig with non-Foundation signers. Named community members holding keys alongside the Foundation. Preserves speed, removes single-party control.
  • Tranching by time rather than milestone. Not a vesting schedule tied to deliverables — just a cap on how much can be deployed per year, with unused amounts rolling forward. Opportunistic spending stays possible; a single-year drain doesn’t.
  • Retroactive disclosure. Every disbursement published with recipient, amount and rationale within 30 days. Zero constraint on decisions, full accountability after the fact.

Any one of these would let the fund do what you want it to do. Right now it’s 178M SCRT — roughly 58% of all day-one liquid supply — released with no vesting, no cap, no threshold, no named committee, and no disclosure requirement. In dollar terms at current prices that isn’t a huge treasury, which is part of my point: the concern isn’t the size of the war chest, it’s that the single largest liquid block on the chain sits under fully discretionary control. It’s the on.

23

@Gymo “holders did not accept the risk associated with a bridge. The risk the victim assumed was that of a hacker attack.”

Holding or staking the token of a network means being exposed to that network’s risk, not only to the risk inside your own wallet. Bridges, contract engines, validator concentration — these are all part of what the token represents. There’s no version of holding SCRT where the chain’s technical risk belongs to someone else. What holders can reasonably expect is that the team running the project treats security as a standing obligation rather than a per-incident response.

But you’re aiming at the wrong target anyway.

You describe the dilution as making holders pay for the hack. Look at the allocation table: remediation is 44M SCRT, 3.1% of post-mint supply. The other 96.9% funds the Foundation, core development, R&D, advisors, the Ecosystem Fund, validators and relayers.

So the real question isn’t “why should I pay for someone else’s exploit” — you’re barely being asked to. The real question is “is 74.9% the right price for operational funding, and are the safeguards on those buckets adequate?” That’s a better objection than the one you’re making — the Ecosystem Fund is where I’d push.

On “the network is functioning as designed.”

“The network is functioning as designed, and dilution on this scale will, in practice, destroy it.”

The people who have maintained it are leaving on September 1. Validators don’t run SGX at a loss indefinitely for a chain nobody maintains — they leave, quietly, the way several already have.

So the choice isn’t between 100% of your position and 25% of it. It’s between 25% of a chain that has a funded team, and 100% of a chain that has no maintainers, degrading listings, and no one to ship the next upgrade. A token nobody maintains and nobody can trade doesn’t hold its value because the supply stayed fixed.

I’m not telling you to vote yes. I haven’t decided myself, and I think several parts of this proposal need tightening before the 19th. But “reject dilution and the network continues as it is” isn’t one of the available outcomes. That option closed when the maintainers announced their exit.

24

@thenodefather — thx for the detailed answers, particularly the Common Prefix link and the commitment on continuous automated review. One follow-up on your last point, because I think it answers a different question than the one I asked

“It would concentrate voting power into the hands of people who care about the network. This is a technical requirement to avoid the situation Secret Labs put the network, and all holders in last night when the chain went down because SCRT Labs and their affiliates moved many of their coins to a single validator, and that validator went offline.”

Above one third, a single operator halts the chain by going offline. Above one half, the same operator can censor transactions and decide any governance proposal alone, quorum included. We are past both thresholds today.

Which is why I don’t think your answer works. The halt wasn’t caused by stake sitting with people who don’t care about the network — it was caused by stake sitting in one place. That’s a distribution property, not an alignment property. A well-intentioned entity holding 40% of bonded stake halts the chain exactly the same way when its infrastructure fails. Replacing indifferent concentration with aligned concentration doesn’t remove the single point of failure. It changes who owns it.

The part nobody in this thread has costed out

Governance participation for those same two validators:

  • Kraken01: 6.79% — 19 proposals out of 280
  • melea: 5.71% — 16 out of 280

That measures whether the validator itself casts a vote, not what its delegators do . But it means 71.20% of bonded stake sits behind validators that effectively never vote by default. Quorum arithmetic on Prop 365:

  • Bonded stake: ~96.18M SCRT
  • Quorum at 33.4%: ~32.13M SCRT required
  • Kraken01: 48.89M, spread across only 3,702 delegators
  • Realistically reachable stake — everyone else, including melea’s 19.59M via individual delegator votes: ~47.3M

Turnout is currently 16.53M. Reaching quorum means finding another ~15.6M from a remaining pool of roughly 30.8M — that is, mobilising about half of all non-Kraken stake that hasn’t yet voted, in six days.

That’s difficult but not impossible. It needs melea to vote, or a large individual turnout from melea’s 18,135 delegators overriding their validator.

Question :

Does the development plan include anything structural to prevent stake concentration going forward? I can’t find it in the proposal or in your replies. Concretely:

  • Any protocol-level work planned — diminishing rewards above a stake threshold, redistribution weighted toward smaller validators? Economic disincentives rather than hard caps, since a hard cap is trivially defeated by running a second validator under another name.
  • Will the Foundation commit to a published delegation policy — a cap on how much of its own stake goes to any one validator?
  • The Validator Program pays 72M SCRT to the active set over five years in equal quarterly distributions. Is any of it weighted toward distribution, or is it flat across seats regardless of concentration? Weighting it costs nothing and needs no fork.
  • If one validator is above one third at execution, does anything here change that, or does the network inherit the same failure mode with a better-funded treasury behind it?

You’ve made stake concentration the central technical argument for this proposal. If the plan fixes funding but leaves concentration where it is, the chain stays one outage away from the same halt — with better-resourced maintainers to explain it afterwards.

25

Not at this exact time it doesn’t. But current reality around what the largest stakeholder(s) (slabs and their friends) are doing to destabilize the chain while they exit is the threat. We have plenty to do immediate term, but i’m sure dpos could be looked into. Your point is more of a dpos design property.