dYdX

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. dYdX's order book also sets it apart from the other main perps design in the directory: GMX has traders take leverage against a shared liquidity pool rather than matching them against each other. A newer entrant, Hyperliquid, takes the same app-chain-perps route with its own L1 but a much lighter governance layer – a useful contrast to dYdX's full on-chain Cosmos governance.

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. The fellow Cosmos AMM Osmosis governs itself through the same module, making the two the canonical app-chain-DEX pair.

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. For a different answer to the same problem, compare Synthetix, which governs through an elected Spartan Council rather than direct staked-token voting.

How Caper approaches this

dYdX makes governance Sybil-resistant by tying it to staked capital and delegating it to a validator set: a vote is a stake, and a holder who does nothing has their validator vote for them. It is a coherent design for a chain that must also be secured, but the deciding quantity is still $DYDX bought on a market, and power rests by default with the validators. In a caper, a member's vote weight comes from the tokens they hold together with the votes they have earned by casting ballots, and the same weight decides their fair share of the treasury when they leave.

The earned votes are soulbound: buying, selling and transferring tokens create none, and they cannot be delegated to a validator, staked for yield or bought from another member. Holdings still count, but a big bag alone can't capture control. A caper also has no validator set or staking layer for governance to ride on: its members vote directly on what the treasury does.

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).