# Signals Docs

> Signals - Community-driven initiative governance with token-weighted voting

## Docs

- [Capital allocation](/use-cases/capital-allocation): Signals can be used as a capital allocation mechanism. Token holders lock governance tokens behind funding proposals they want to see capitalised. Because locked tokens cannot simultaneously back multiple initiatives, every allocation decision carries opportunity cost. The result is a ranked signal of where the community wants capital deployed — something binary yes/no votes on individual proposals cannot produce.
- [Use cases](/use-cases): A board with no close date functions as a continuous prioritisation engine. Communities that need ongoing signal about product direction or funding priorities can leave a board open indefinitely, and initiatives rise and fall organically as sentiment shifts.
- [Closing and Cancelling a Board](/signals-board/close-cancel-board): There are two ways to shut down a board, and they have different consequences for locked tokens. Both are **owner-only** and **irreversible**.
- [Creating a Signals Board](/signals-board/create-board): Board creation is a two-phase process. First, deploy the board through the **SignalsFactory** with a complete `BoardConfig`. Then, optionally attach an incentives pool before the board opens. Acceptance criteria, locking parameters, and decay curves are **immutable after deployment**.
- [Incentive Pools](/rewards-and-incentives/adding-incentives): Incentives are board-wide reward pools that distribute tokens to supporters of accepted initiatives. The distribution is **time-weighted**: earlier supporters earn a larger share than those who lock later. Rewards are auto-claimed when supporters redeem their lock positions.
- [Adding Bounties](/rewards-and-incentives/bounties): Bounties let anyone attach external ERC20 token rewards to a specific initiative. When the initiative is accepted, the bounty is split three ways between the protocol, supporters, and a treasury according to configured percentages.
- [Accepting Initiatives](/reference/initiative-actions/accept-initiative): Sets state to `Accepted`, records `acceptanceTimestamp`. Supporters can redeem after `releaseLockDuration` passes.
- [Adding Bounties](/reference/initiative-actions/add-bounty): Distribution and refunds are not yet triggered on-chain. Balances are tracked but cannot be claimed.
- [Expiring Initiatives](/reference/initiative-actions/expire-initiative): Owner-only. Sets state to `Expired`. Requires `block.timestamp > lastActivity + inactivityTimeout`.
- [Proposing Initiatives](/reference/initiative-actions/propose-initiative): **Returns:** `initiativeId` of the newly created initiative.
- [Redeeming Tokens](/reference/initiative-actions/redeem): Burns the NFT, transfers locked tokens back to the holder. Auto-claims incentive rewards for accepted initiatives.
- [Supporting Initiatives](/reference/initiative-actions/support-initiative): **Returns:** `tokenId` (ERC721 lock NFT).
- [Tracking Support](/reference/initiative-actions/tracking-functions): Returns complete initiative information including state, proposer, timestamps.
- [Example Configurations](/reference/board-configuration/example-configurations): Each example below is a complete `BoardConfig` that can be passed directly to `SignalsFactory.create()`. The parameter values are opinionated starting points. Adjust thresholds and durations to match your community's size and governance cadence.
- [Incentives Configuration Reference](/reference/board-configuration/incentives-configuration): Complete technical reference for configuring and deploying the IncentivesPool system.
- [BoardConfig](/reference/board-configuration/parameters): Off-chain compatibility marker. Current version: `"0.3.2"`.
- [Querying Board Configuration](/reference/board-configuration/querying): View functions for reading board configuration and checking participant eligibility.
- [Validation Errors](/reference/board-configuration/validation-errors): Errors thrown during board initialization via `SignalsFactory.create()` and during participant eligibility checks at runtime.
- [Accepting and Expiring Initiatives](/initiatives/action-expire-initiative): An initiative in the **Proposed** state can transition to **Accepted** (threshold met) or **Expired** (inactive too long). Both transitions are permanent and one-way.
- [Redeeming Tokens](/initiatives/reclaim-tokens): When you lock tokens behind an initiative, you receive an ERC721 NFT representing that position. Redemption burns the NFT and returns your tokens. When and how you can redeem depends on the state of the initiative and the board.
- [Proposing an Initiative](/initiatives/submit-initiative): An initiative is a proposal submitted to a Signals board. Anyone who meets the board's **proposer requirements** can create one. Both methods accept a title, description (markdown supported), and up to **5 attachments** (URIs pointing to supporting documents, designs, or forum posts).
- [Supporting an Initiative](/initiatives/support-initiative): Lock ERC20 tokens behind an initiative to generate **support weight** that counts toward its acceptance threshold. Each lock mints a transferable ERC721 NFT representing the position. For example, a board using ENS token would mint NFTs named `ENS Locked Support` with symbol `sxENS`. Trading the NFT transfers the right to redeem the underlying tokens.