CORE DEFI PRIMITIVES AND MECHANICS

Core DeFi Concepts Explained, Mechanics, Governance, and Snapshot Voting

9 min read
#Smart Contracts #Protocol Design #Decentralized Finance #Tokenomics #Governance
Core DeFi Concepts Explained, Mechanics, Governance, and Snapshot Voting

Liquidity pools, automated market makers, staking, and yield farming are the backbone of modern decentralized finance. Together, these primitives create a self‑contained economic ecosystem that runs on blockchain data and code. Understanding how they interlock, how token holders govern the rules that govern them, and how voting is executed on‑chain or off‑chain is essential for anyone who wants to participate responsibly.

Core DeFi Primitives

The first layer of DeFi is the liquidity pool. A pool is simply a smart contract that holds a pair of tokens. When users deposit equal values of each token, they receive liquidity provider (LP) tokens that represent their share. These LP tokens can be traded, staked, or used as collateral. The pool’s balance drives the price curve, which is defined by an automated market maker (AMM) formula such as x * y = k. This invariant keeps the pool in equilibrium and allows users to swap tokens at any time.

The AMM is the second primitive. It removes the need for order books by setting prices algorithmically. When someone swaps token A for token B, the AMM takes the amount of A, adds it to the pool, pulls an equivalent value of B, and updates the invariant. The result is a self‑balancing system that reacts instantly to supply changes.

Staking is the process where users lock their tokens in a contract to earn rewards. The reward distribution may be based on the amount of tokens staked or on the amount of LP tokens owned. Staking is the engine that fuels liquidity mining programs, which incentivize the deployment of capital to the network.

Lending protocols such as Compound and Aave provide a way to supply assets that generate interest and to borrow against over‑collateralized positions. These protocols rely on a dynamic interest‑rate model that adjusts borrowing rates in response to utilization.

Each of these primitives is written in Solidity or a similar language, published on Ethereum or another public chain, and audited to guarantee that no hidden backdoors or logic errors undermine the system.

Mechanics of an AMM Swap

A user initiates a swap by calling the swap function on the pool contract. The function first calculates the new balances using the invariant equation. For example, with x * y = k, if a user adds Δx of token X, the contract calculates the new y such that the product remains k. The difference between the old y and the new y is the amount of token Y the user receives.

Slippage measures the price impact of the trade relative to the pool’s current price. Large trades consume a significant portion of the pool’s liquidity and push the price curve, causing the trader to pay more (or receive less) than expected. Most interfaces display slippage tolerance settings that revert the trade if the impact exceeds a preset threshold.

Impermanent loss is the temporary loss incurred when the price of the supplied tokens diverges from their price at deposit. The loss is “impermanent” because if the price returns to its original state, the loss disappears. Liquidity providers calculate expected impermanent loss versus earned rewards to decide whether to add liquidity.

All these calculations happen within the same transaction. The transaction is signed by the user’s private key, broadcast to the network, and included in a block. Once mined, the transaction is immutable, and the state changes are recorded on the blockchain.

Governance Models

Decentralized governance is how DeFi projects evolve without a single point of control. The most common models are on‑chain governance and off‑chain governance.

On‑Chain Governance

In on‑chain governance, proposals are encoded as smart contracts and votes are recorded on the blockchain. A voter’s power is typically proportional to their token balance or LP tokens. The vote count is summed, and if a quorum threshold is met, the proposal executes automatically. Because all state changes are on‑chain, there is no need to trust a third party to tally votes. The downside is that every action requires on‑chain gas, which can be costly.

Off‑Chain Governance

Off‑chain governance, on the other hand, relies on external services to collect votes and count them. Snapshot, for example, uses a gas‑free off‑chain voting system that records the results on‑chain by a single transaction. Users cast votes through a web interface; the votes are tallied in a distributed ledger, and the final result is broadcast. The advantage is lower gas usage and faster execution. The risk is that a malicious or compromised off‑chain service could manipulate the tally before it is recorded.

Treasury Management

Beyond voting, governance often includes treasury management. Projects raise capital through token sales, grants, or fees. The treasury must be protected and allocated transparently. Many protocols adopt multi‑sig wallets or time‑locked contracts to enforce spending rules. Governance votes decide how much of the treasury to spend on development, community rewards, or partnerships.

Snapshot Voting

Snapshot is a popular off‑chain voting platform that allows projects to run governance polls without incurring gas costs. The key idea is that the contract uses a balance snapshot at a specific block number. Each token holder’s voting power is calculated based on the balances at that block, preventing manipulation through token transfers after the snapshot.

When a proposal is created, it specifies:

  • A unique ID
  • A description
  • A set of actions (function calls)
  • A start block and a deadline block

Once the proposal is active, users can vote “Yes,” “No,” or “Abstain.” Each vote records the voter’s address, the choice, and the block number. After the deadline, the contract tallies votes and, if the quorum and majority thresholds are satisfied, executes the actions.

The benefits of Snapshot include:

  • Zero gas for voting
  • Transparent record of who voted and how
  • Compatibility with any ERC‑20 or ERC‑721 token
  • Flexible time controls

The drawbacks are:

  • Dependence on the Snapshot service
  • No on‑chain dispute resolution
  • Potential for vote‑buying if a user obtains a large stake before the snapshot

Projects mitigate these risks by combining Snapshot voting with on‑chain checks or by requiring multi‑sig approvals for high‑value proposals.

On‑Chain vs. Off‑Chain Snapshot Voting

The choice between on‑chain and off‑chain Snapshot voting hinges on several factors: cost, speed, security, and user experience.

Gas Costs

On‑chain governance requires every vote to be a transaction that consumes gas. This can be prohibitive for large token holdings or for users with limited funds. Snapshot eliminates the gas barrier by letting users vote off‑chain, with a single on‑chain transaction to lock in the results.

Speed of Execution

On‑chain proposals typically need to wait for a voting period that spans several blocks, often a day or more. Snapshot proposals can run for any duration, and once the deadline passes, the result can be executed immediately with a single transaction.

Security and Trust

On‑chain voting removes the need to trust an external voting service. All votes are recorded on the blockchain, and the contract logic is transparent. Snapshot introduces a layer of trust: users must believe that the off‑chain tallying is accurate. However, Snapshot is open‑source, and the community can audit its code.

User Experience

Off‑chain voting is usually more user‑friendly. The interface can integrate with popular wallets and show voting power instantly. On‑chain voting forces users to approve a transaction in their wallet, potentially confusing new participants.

Governance Robustness

Some projects adopt a hybrid model: they use Snapshot for preliminary proposals and on‑chain voting for critical changes. This approach balances cost, speed, and security. For example, Uniswap’s governance uses on‑chain voting for major upgrades while employing Snapshot for community feedback.

Case Studies

Uniswap V3

Uniswap’s governance token, UNI, holds on‑chain voting rights. Proposals must be approved by a 15% quorum and 51% of votes. The smart contract executes changes directly, ensuring that protocol upgrades are transparent and irreversible. The project recently adopted an off‑chain voting interface for user experience, but the final tally remains on‑chain.

Compound

Compound uses the COMP token to govern upgrades and parameter changes. COMP holders vote on proposals that can adjust interest‑rate curves, add new assets, or allocate the treasury. Compound’s governance contract records votes on‑chain, making the process auditable. The protocol also employs a “timelock” mechanism to delay execution, giving the community time to react.

MakerDAO

MakerDAO’s governance is a blend of on‑chain and off‑chain mechanisms. MKR token holders vote on changes to the system, and the outcomes are executed via the Governance Smart Contract. However, MakerDAO also uses off‑chain voting for proposals that require larger budgets, using a third‑party service to aggregate votes before final on‑chain execution.

Best Practices for Snapshot Voting

  1. Clear Proposal Language
    Draft proposals in plain language, specifying the exact actions and thresholds. Ambiguity invites disputes.

  2. Use Transparent Quorum Metrics
    Set a clear quorum requirement. Too low, and the result may not reflect the community; too high, and proposals may never pass.

  3. Leverage Time‑Locks
    Add a delay between proposal approval and execution. This gives token holders time to react to unexpected outcomes.

  4. Audit Snapshot Logic
    Periodically review the Snapshot codebase to ensure no hidden backdoors or manipulation vectors remain.

  5. Encourage Token Locking
    Require voters to lock their tokens for the duration of the vote. This reduces vote‑buying and aligns incentives with long‑term participation.

  6. Provide Off‑Chain Transparency
    Publish the Snapshot voting results on a public dashboard. Allow third‑party auditors to verify the counts.

Conclusion

Core DeFi primitives—liquidity pools, AMMs, staking, and lending—create a frictionless financial layer that operates purely on code. The mechanics of swapping and providing liquidity are governed by simple mathematical invariants, but the broader system relies on transparent governance to evolve and protect participants.

Governance comes in many shapes: on‑chain contracts that record every vote, off‑chain platforms like Snapshot that reduce costs, and hybrid models that blend the strengths of both. Each choice involves tradeoffs in cost, speed, security, and user experience.

By understanding the mechanics of DeFi primitives, the mechanics of AMM swaps, the nuances of governance models, and the operational details of Snapshot voting, stakeholders can make informed decisions about where to invest, how to participate, and how to shape the future of decentralized finance.

Lucas Tanaka
Written by

Lucas Tanaka

Lucas is a data-driven DeFi analyst focused on algorithmic trading and smart contract automation. His background in quantitative finance helps him bridge complex crypto mechanics with practical insights for builders, investors, and enthusiasts alike.

Contents