Turning on the DAO
How Ekubo governance went live, and the six proposals that have shaped who can pass one — quorum, delay, voting period and the ability to simulate a proposal before creating it.
Part of a series covering every proposal the Ekubo DAO has voted on — 72 of them, between June 2024 and July 2026, of which 57 executed. This post covers the six that changed the rules of the process itself, and is dated to the last of them.
Period covered: June 2024 – July 2025.
The first proposal had a bootstrapping problem
Ekubo governance activated on June 1, 2024. The first proposal did three things at once: upgraded the governor from v2.0.0 to v2.1.0, cut the quorum from 5M to 3.5M EKUBO, and shipped a class-hash update fixing the TWAMM math bug.
The quorum cut was the point. 5M tokens was roughly the entire circulating supply at the time, which meant a proposal could only pass if essentially every token voted. Governance could not act until it had lowered its own bar — and lowering the bar required passing a proposal at the old bar.
It cleared. What it took to clear is the subject of the second proposal in this series, and it is not a detail: on June 12 the DAO spent 180,000 STRK rewarding the people who had delegated their EKUBO to voters on that first proposal. Reaching quorum was expensive enough to be worth paying for retroactively.
That is a real thing to know about a young DAO. The first vote is the hardest one, because the machinery that makes voting cheap does not exist yet.
Making proposals safe to write
By June 20, 2024 the complaint was that proposals were hard to get right. A proposal is a list of raw contract calls; a mistake in the calldata is not visible until execution, and by then it has passed.
Governor v2.2.1 addressed this by exposing the __execute__ entrypoint for simulation only — you can dry-run the exact call list before you create the proposal. The same upgrade removed the report-breach functionality, which the longer voting-start delay had made redundant.
It also made the first cut to the clock: voting start delay 1 day → 3 days, voting period 7 days → 3 days. With enough active delegates at the reduced quorum, the DAO could afford to spend less time voting and more time reviewing.
This turns out to matter later. In January 2026, a proposal to remove the withdrawal fee failed on a calldata error and had to be reposted three days later. Simulation is not a guarantee.
The clock kept getting shorter
The voting parameters have been retuned twice more, both times in the same direction.
November 2024 — “Reconfigure governor to be more agile”: start delay 3 days → 1 day, voting period 3 days → 2 days, execution delay 1 day → 1 hour.
July 2025 — “Adjust governance parameters for current phase”: start delay 1 day → 1 hour, voting period 2 days → 3 days.
Read together, the trajectory is unusual. Most DAOs lengthen their timelocks as they grow. Ekubo shortened the waiting and lengthened the voting: a proposal now becomes votable within an hour, but the window to actually vote is three days, and execution follows an hour after it passes.
The stated reason each time was the protocol’s stage — urgent matters needed handling, and the delegate set was concentrated enough that a long start delay bought little. It is a defensible trade and also a real one: an hour of notice is not much time to organise opposition to a proposal you dislike.
Plumbing
The remaining governance-layer change was January 2025’s upgrade to governor v2.3.1, which moved to Cairo compiler v2.9.2, migrated the old configuration storage, and — the load-bearing part — enabled the governor to make calls to L1.
That single capability is what everything in Getting to Ethereum depends on. A DAO living on Starknet cannot deploy or steer an Ethereum contract without a way to reach across. Every subsequent proposal that moves DAO money on Ethereum runs through the machinery this upgrade unlocked.
The proposals
| Date | Proposal | Outcome |
|---|---|---|
| Jun 1, 2024 | Activate Ekubo Protocol Governance | Executed |
| Jun 12, 2024 | Transfer 180000 STRK to airdrop contract for users who delegated their EKUBO tokens | Executed |
| Jun 20, 2024 | Upgrade the Governor contract to v2.2.1 and reconfigure voting parameters | Executed |
| Nov 23, 2024 | Reconfigure governor to be more agile | Executed |
| Jan 6, 2025 | Upgrade the governor to v2.3.1 | Executed |
| Jul 8, 2025 | Adjust governance parameters for current phase | Executed |
All six executed. The governance layer is the one area of the DAO’s history where nothing has been rejected — which is either a sign of uncontroversial housekeeping or of a delegate set that agrees on process. Both readings are available.
Next in the series: the TWAMM bug that governance was activated to fix.