dYdX is a decentralized exchange for perpetual futures. Its distinguishing decision is architectural: rather than remain a smart-contract application on a shared chain, dYdX rebuilt itself as its own sovereign blockchain — the dYdX Chain, a Cosmos SDK Layer 1 whose validator set runs a fully on-chain order book. That move reshaped its governance completely. Where the earlier Ethereum version borrowed Aave’s on-chain-Governor-plus-timelock machinery, the app-chain governs itself the way Cosmos chains do: through the standard governance module, where voting power is staked DYDX and validators carry their delegators’ votes by default. dYdX is the clearest case study in the wiki of a DAO that changed its governance by changing the ground it stands on. Claims below link to dYdX’s own documentation and primary reporting.

From an Ethereum L2 to a sovereign app-chain

dYdX v3 ran as an Ethereum Layer 2 built on StarkEx, with an off-chain order book and matching engine operated by the dYdX company and on-chain settlement via a validium. Governance lived in Ethereum contracts modeled on Aave: a Governor tracking proposals, multiple timelock executors (short- and long-delay), a Safety Module staking pool, and a Governance Strategy that counted voting power from ethDYDX, wethDYDX, and staked stkDYDX.

On 26 October 2023 the dYdX Chain launched on mainnet as a standalone Cosmos SDK / CometBFT chain — a genesis block produced by an independent validator set, not a rollup posting to Ethereum. The order book itself now lives on-chain, replicated across validators. A community governance vote initiated a migration of the token: holders bridge the Ethereum ethDYDX ERC-20 to the chain’s native DYDX through a one-way, permissionless, irreversible bridge with no end date. The old Ethereum governance stack did not move across; the chain governs itself with Cosmos-native tooling.

On-chain governance through the Cosmos gov module

The dYdX Chain uses the standard Cosmos SDK x/gov module, so its lifecycle mirrors other Cosmos chains rather than an Ethereum DAO:

• Deposit period. A proposal must attract a minimum deposit to reach a vote — a 2,000 DYDX initial deposit is required to open it (the module’s initial-deposit ratio is 20% of the full minimum), within a 7-day deposit window; anyone may top it up.
• Voting period. Once funded, a roughly 4-day vote opens with four options — Yes, No, NoWithVeto, and Abstain.
• Passage. A proposal passes on a 33.4% quorum, a 50% Yes majority of non-abstaining votes, and fewer than 33.4% NoWithVeto. Abstain counts toward quorum but not toward the majority.
• Veto teeth. If the NoWithVeto threshold is crossed, the proposal is rejected and its deposit is burned — a built-in cost for spam or captured proposals. Deposits are not burned merely for failing to reach quorum.

Unlike an Ethereum Governor executing arbitrary calldata through a timelock, a passed dYdX proposal is applied by the chain’s own state-machine logic — parameter changes, software upgrades, and treasury spends handled as native governance actions.

Stake to vote: validator inheritance and delegator override

The defining feature of Cosmos-style governance is that voting power is staked, not merely held. On the dYdX Chain a holder’s vote weight equals the DYDX they have actively staked, one-for-one; unstaked or unbonding tokens carry no weight (governance module docs). Because staking secures the chain, this fuses two roles the earlier Ethereum design kept separate: the token that pays for block security is the same token that votes.

Staking is delegated to validators, and that shapes participation. By default a validator votes on behalf of everyone delegated to it, and any delegator who does not cast their own vote inherits the validator’s choice. A delegator who disagrees can override by voting directly with their own stake. The upshot is a plutocracy softened by delegation: default power pools in the validator set, but engaged delegators can always reclaim their weight. It is token-weighted voting with a staking gate and a delegation layer — Sybil-resistant and security-aligned, yet still power proportional to capital.

What governance controls

Because dYdX is the chain, its governance reaches further than a single application’s parameters. Passed proposals can authorize software upgrades to the chain binary, tune module and market parameters (fees, margin, listing new perpetual markets), and direct the community treasury that funds grants and ecosystem work. The dYdX Foundation and the operations subDAO steward process and tooling, but the binding levers — what the chain runs and how it spends — sit with staked-DYDX voters. Governance here is not an overlay on a protocol; it is the protocol’s upgrade and treasury mechanism, expressed in the chain’s own consensus.

How Caper approaches this

dYdX makes governance Sybil-resistant by tying it to staked capital and delegating it to a validator set: your vote is your stake, and if you do nothing your validator votes for you. It is a coherent design for a chain that must also be secured — but the decisive factor is still DYDX bought on a market, and the default resting place of power is the validators. Caper folds a different quantity into the weight. A caper member’s vote weight is (t·v)/(V·T) — held tokens t times the member’s earned soulbound votes v, over supply V and circulation T — computed by the contract’s compute_vote_weight helper and reused verbatim by exit() to size a member’s treasury share, so the same metric that governs also settles the way out. The vote token is DIVISIBILITY_NONE, minted one per vote, and non-transferable (its depositor role is bound to the component’s own global_caller and its updater is deny_all), so v is an accumulated record of participation that cannot be delegated to a validator, staked for yield, or bought on a market. This is not a claim that holdings do not matter — t is a straight multiplier, so a bag still counts — but a large bag alone cannot capture control the way a whale accumulating staked DYDX can, because the second factor has to be earned one vote at a time. Caper also declines dYdX’s coupling of security and governance: there is no validator set to delegate to and no staking layer, only a flat membership voting a typed treasury.

References

• dYdX governance module documentation — deposit, voting, quorum, thresholds, and vote-weight rules.
• dYdX Foundation — expanded utility of DYDX on the dYdX Chain — the ethDYDX→DYDX one-way migration and staking.
• The Block and CoinDesk — the standalone Cosmos Layer 1 launch (26 Oct 2023).
• Cosmos SDK x/gov module — the underlying governance primitive (deposit/voting periods, NoWithVeto, delegator inheritance).