Skip to main content

TAM: Introduction to Tokenized Allocation Mechanisms

Purpose: Explain TAM's core model, why it exists, the mental model behind shared lifecycle + mechanism-specific hooks, and what TAM does not attempt to do.

Audience: Developers, researchers, and DAO operators building governance and funding mechanisms; assumes familiarity with core Octant concepts but not with TAM specifically.

Level: Intermediate

Source of truth: TAM design in [email protected]; deployment addresses, where needed, come from the Deployed Addresses page.

Use this page when: You want to understand the "why" and "what" of TAM, learn the key terminology, and grasp the shared-lifecycle-plus-hooks mental model before diving into architecture or implementation details.

Do not use this page for: Detailed architectural explanations (see TAM: Architecture), concrete hook implementations, or quadratic funding specifics. This is conceptual; for architecture and lifecycle details, move to the next pages.

Before you read this page

Tokenized Allocation Mechanisms (TAMs) generalize a proven Yearn V3-style pattern to governance and funding. The mechanism itself is a tokenized accounting and lifecycle layer with strict transfer and redemption rules. The shared implementation fixes the round lifecycle, while hooks let you swap in different funding and voting policies, such as quadratic funding, linear voting, matched allocation, or other custom rules.

Who this is for​

  • Protocol teams building repeatable, auditable funding rounds.
  • DAO operators who want permissionless queuing with explicit lifecycle gates.
  • Researchers experimenting with voting and distribution rules inside a shared invariant-checked framework.

The model in one paragraph​

Voters register, optionally depositing assets to gain voting power under the mechanism's chosen policy. Proposers open proposals, voters cast votes, the owner finalizes tallies, and then anyone can queue successful proposals during the allowed queueing period. At queue time, the mechanism either:

  • mints shares to recipients, redeemable during a global redemption window, or
  • performs a custom distribution through a hook while keeping internal accounting correct.

Shares are non-transferable before redemption starts, and transferability remains constrained by the shared mechanism rules throughout the lifecycle.

Key terms

Delegatecall: runs code from another contract using the caller's storage. In TAMs, the proxy holds state and the shared implementation supplies behavior.

Hook: an internal policy extension point. In the Solidity architecture, hooks are exposed through wrappers guarded by the onlySelf pattern, so they can only be reached through the shared implementation.

Timelock / queueing window: the period after tally finalization during which successful proposals may be queued.

Redemption window: a global time window, configured when tallies are finalized, during which recipients may redeem their queued shares for assets.

Why TAM (developer motivations)​

The design targets three outcomes:

  1. Modularity. Reuse one shared implementation while expressing policy in hooks.
  2. Permissionless execution at the right step. Anyone can queue proposals once the mechanism has finalized tallies, without giving up policy control over how votes translate into distribution.
  3. Operational clarity. The lifecycle is explicit: registration, proposals, voting, tally finalization, queueing, redemption.

Key concepts (compact glossary)​

These terms appear throughout the code and docs.

  • TokenizedAllocationMechanism (implementation). Shared lifecycle logic for registration, proposals, voting, tally finalization, queueing, redemptions, and transfer restrictions. It also provides the ERC-20-compatible share ledger and EIP-712 flows.
  • BaseAllocationMechanism (proxy). Thin delegator that initializes the shared implementation and exposes onlySelf-guarded hook wrappers. Storage lives in the proxy via delegatecall.
  • Hooks. Internal extension points used to customize voting power, vote processing, proposal filtering, vote-to-share conversion, and distribution behavior.
  • Voting power. The mechanism-defined quantity a voter can spend. Different mechanisms may make it linear, quadratic, capped, time-weighted, or otherwise policy-specific.
  • Queueing. The permissionless step where a successful proposal is turned into redeemable shares or a custom distribution.
  • Redemption window. A global period during which queued recipient shares may be redeemed for assets.
  • Custom distribution. An optional hook-driven path where queueing does something other than mint shares, while still reporting the exact assetsTransferred so accounting remains correct.

What users should expect​

  • Voters: explicit round stages, visible proposal state, and mechanism-specific voting power rules.
  • Recipients: either minted shares that become redeemable during the redemption window, or funds delivered through a custom distribution hook.
  • Operators: clear gates for finalization, queueing, and redemption, with fewer ad hoc actions hidden behind manual bookkeeping.

Lifecycles at a glance​

Round lifecycle​

  1. Register → voting power. A voter calls signup(...) or a signature-based equivalent. The hook layer determines how voting power is assigned.
  2. Propose. An authorized proposer opens a proposal.
  3. Vote. A voter casts votes under the mechanism's configured voting rule.
  4. Finalize tally. After the voting window closes, the owner calls finalizeVoteTally(). This also establishes the global redemption window.
  5. Queue. During the allowed queueing period, anyone may call queueProposal(pid) for a successful proposal. The shared implementation checks proposal state and then either mints shares or executes custom distribution.
  6. Redeem. During the redemption window, recipients may redeem queued shares for assets, subject to the shared mechanism rules.

Responsibilities for mechanism authors​

Mechanism authors work in hooks, not in the shared lifecycle.

That means your job is to define policy, not to reimplement the state machine.

Typical responsibilities include:

  • defining how signups convert deposits or identities into voting power,
  • defining how votes are processed and whether voters may vote once or incrementally,
  • defining how successful vote totals convert into recipient shares,
  • defining whether queueing mints shares directly or triggers a custom distribution path,
  • ensuring every custom hook remains deterministic and accounting-safe.

When implementing _requestCustomDistributionHook, always return the exact assetsTransferred value so shared accounting stays correct.

TAM is broader than QF​

Quadratic Funding is an important TAM use case, but it is not the only one.

The shared TAM architecture is designed to support multiple mechanisms through hooks. Quadratic voting and ProperQF utilities are part of the codebase, but they are examples of what TAM can host, not the definition of TAM itself.

So the right mental model is:

  • TAM = the shared lifecycle and accounting framework,
  • QF = one concrete family of policy logic you can implement on top of it.

What is quadratic funding?​

Quadratic funding (QF) is a mechanism where small donations from many people are amplified by a matching pool. The more individual contributors a project has, the more matching funds it receives — even if each individual contribution is small. This means a project with 100 donors giving 1eachgetsmorematchingthanaprojectwith1donorgiving1 each gets more matching than a project with 1 donor giving 100. QF is one of several allocation policies you can implement as a TAM. Others include simple token-weighted voting, linear funding, or any custom rule you design.

Architectural split​

At a high level, the architecture is:

BaseAllocationMechanism (proxy + state)
        ↓ delegatecall
TokenizedAllocationMechanism (shared lifecycle + accounting)
        ↓ onlySelf hook wrappers
Your mechanism-specific hook logic

That split matters because:

  • the proxy holds state,
  • the implementation owns the fixed lifecycle,
  • your mechanism customizes policy through hooks rather than rewriting the whole contract surface.

What this page does not try to do​

This page does not define one specific voting rule, one funding formula, or one proposal policy.

For that, continue into the deeper TAM pages and the contract reference. This page is only meant to establish the shared model:

  • tokenized lifecycle,
  • permissionless queueing at the right stage,
  • hook-based customization,
  • and a shared redemption/accounting model.