---
title: "Den (multisig operations)"
url: "https://caper.network/wiki/dao-governance/tooling/treasury/den"
updated: 2026-09-19
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Den (multisig operations)

|  |  |
| --- | --- |
| **Category** | Treasury · multisig operations |
| **What it does** | An operations layer on top of an existing [Safe](/wiki/dao-governance/tooling/treasury/safe) — notifications, decoded transactions, simulation and payment requests to get signatures collected |
| **Smart contracts** | **None.** "Built on the Safe Contracts with no additional smart contract code" ([Den docs](https://docs.onchainden.com/overview/safe-contracts)) |
| **Networks** | 13 EVM chains where Safe's official deployments run — Ethereum, Polygon, Optimism, Arbitrum, Base, Gnosis Chain, Avalanche, BNB Chain, Berachain, Zora, Corn, Blast, World Chain ([docs](https://docs.onchainden.com/overview/supported-chains)) |
| **Notable** | Votes in [SafeDAO](/wiki/daos/infrastructure/safe-dao) governance as a delegate under `jgov.onchainden.eth` and `igov.onchainden.eth` |
| **Site** | [onchainden.com](https://onchainden.com/) · [docs](https://docs.onchainden.com) |
| **Related** | [Safe](/wiki/dao-governance/tooling/treasury/safe), [Squads](/wiki/dao-governance/tooling/treasury/squads), [Request Finance](/wiki/dao-governance/tooling/treasury/request-finance), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [The DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**Den** is an operations layer for organisations whose money sits in a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig. It does not custody assets and it does not deploy contracts: signing in fetches the Safes an address already owns, and Den's own documentation is explicit that it is [built on the Safe Contracts with no additional smart contract code](https://docs.onchainden.com/overview/safe-contracts). What it adds is everything that happens _between_ a transaction being proposed and the threshold being met — the part of [treasury operations](/wiki/dao-governance/concepts/treasury/dao-treasury-management) that is a human coordination problem rather than a cryptographic one.

## The bottleneck is inaction, not theft

A Safe is designed so that no minority can move funds. The corollary, which gets far less attention, is that no minority can move funds _even when they should_. Den's own framing of the problem it solves names coordination first: teams "[spend days getting everyone to sign multisig transactions](https://docs.onchainden.com/overview/den)", with hardware wallets in the wrong city and signers who simply forget. A 4-of-7 treasury that cannot assemble four signatures inside a week is, operationally, a treasury that cannot act — and unlike a capture attack, nothing about that failure is visible on-chain. It shows up as proposals that passed and payments that never went out.

This is a distinct failure mode from the ones catalogued under [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail): the governance layer works, the vote carries, and execution stalls at the last mile because the executing body is a group of individuals with day jobs. Tools in this category treat signature collection itself as the product.

## Coordination as the product

Den's answer is deliberately unglamorous. Discord, Telegram, Slack and SMS bots fire when a transaction is created, executed or rejected, and then keep firing: [reminder notifications repeat at a configured frequency](https://docs.onchainden.com/notifications/overview) until a pending transaction is executed. The bots tag the signers who have _not_ yet signed, and generate [statistics on who the least active signers are](https://docs.onchainden.com/overview/den).

That last feature is quietly a governance instrument rather than a convenience. Per-signer responsiveness is exactly the kind of metric a DAO otherwise has no record of: a signer set is usually appointed by a vote and then never measured again, and a member who has stopped signing is functionally a reduction in the effective threshold that nobody has ratified. Making non-signing legible is the same accountability move that [delegate scorecards](/wiki/dao-governance/tooling/analytics/karma) make for voting, applied to the custody layer — and it bears on the [participation-rate arithmetic](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs) DAOs now use to price governance work.

## Reading what you sign

The second problem Den names is comprehension: complex calldata, [numbers divided by 1018](https://docs.onchainden.com/overview/den), and no context for what a payload actually does. Den decodes transaction data, lets owners attach plain-language descriptions, supports [simulation at creation time](https://docs.onchainden.com/creating-transactions/simulations) and again [before execution](https://docs.onchainden.com/signing-and-executing/simulation), and offers a [custom transaction builder](https://docs.onchainden.com/creating-transactions/custom-transaction-builder) plus JSON upload so that teams stop maintaining bespoke scripts to construct treasury calls.

There is a structural point worth stating plainly here, and Den's own [security page](https://docs.onchainden.com/overview/security-practices) is the source for it. Because Den adds no contracts, it "is not able to modify the Safe Contracts or any transactions that a user has signed or executed" — the custody guarantee is untouched. But the descriptions and address labels that signers _read_ are off-chain data held on Den's servers, visible to Safe owners who prove ownership with an [EIP-4361](https://eips.ethereum.org/EIPS/eip-4361) signature. So the human-readable account of what a transaction does is a mutable, off-chain artifact sitting beside an immutable on-chain payload. That is not a flaw in the design — it is where the design draws its trust boundary, and it is the reason decoding and simulation matter more than the description field: those are derived from the payload itself.

## Gas paid from the Safe

Den defaults new transactions to having the Safe reimburse whoever executes them. This is not a Den invention: gas refunds are [native functionality of the Safe contracts](https://docs.onchainden.com/pay-gas-from-safe/how-it-works), exposed in `Safe.sol`'s execution parameters. Den's contribution is turning it on by default and routing execution through a relayer, so a signer holding no native token on the chain in question is no longer a blocker.

The safety property is the part worth noting: the [maximum refund is included in the signature itself](https://docs.onchainden.com/pay-gas-from-safe/faq) and enforced by the Safe contract, so the ceiling on what a treasury can pay out for gas is fixed at signing time rather than trusted to the executor. A DAO that reimburses signers manually instead pays for a second transaction each time — and, more importantly, pays it through a discretionary process with no such ceiling.

## Organisations, bookkeeping and the vendor question

Above the single-Safe view, Den groups related Safes into an organisation, lets non-signers hold read-and-annotate permissions on the off-chain data, and exports categorised bookkeeping to conventional accounting software. Den documents this as [an upcoming premium tier in limited early access](https://docs.onchainden.com/organizations/overview), which is a useful reminder that most of the DAO tooling stack is commercial software with a roadmap, not a protocol.

Den also occupies a position the wiki covers under [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers): it votes in [SafeDAO](/wiki/daos/infrastructure/safe-dao) as a delegate, publishing two delegate addresses, `jgov.onchainden.eth` and `igov.onchainden.eth`, and inviting `$SAFE` holders to [delegate to them on Snapshot](https://snapshot.org/#/delegate/safe.eth). SafeDAO is a substantial governance body — [17,720 followers and 55 proposals](https://snapshot.org/#/safe.eth) on its Snapshot space, read from Snapshot's GraphQL API on 3 September 2026. A vendor whose product depends on a set of contracts holding delegated voting power in the DAO that stewards those contracts is a genuine alignment _and_ a genuine conflict, of the same shape as the service-provider relationships mapped on that page. Den states the arrangement openly, which is the right disclosure; it does not make the structure disappear.

## Where it sits in the stack

In the layering described on [the DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), Den is not a custody choice — the custody choice is Safe. It is an operations veneer over a custody decision already made, in the same band as [Request Finance](/wiki/dao-governance/tooling/treasury/request-finance) (which turns vendor invoices into batched multisig payments) and distinct from an asset manager like [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey), which decides what the treasury _holds_. On Solana the equivalent role is bundled into [Squads](/wiki/dao-governance/tooling/treasury/squads) rather than sold separately. The category exists at all because Safe deliberately stayed minimal, leaving the workflow above it to third parties.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no signer set, so the coordination bottleneck Den exists to solve has no surface to appear on. A [proposal](/wiki/governance/proposals) that passes is [executed against the treasury by the contract](/wiki/governance/execution), and both halves of that – resolving the proposal when its window closes, and executing the action it carries – are permissionless. There is no interval in which a passed decision waits on individuals to sign.

Caper used to converge with Den on the gas question, and since 11 September 2026 it does not. Until that date the contract contingently reimbursed each settle-path call out of the caper’s own treasury, against a per-call ceiling (`SETTLEMENT_GAS_PER_CALL`, 5 XRD) and a per-proposal allowance (`SETTLEMENT_GAS_BUDGET`, 500 XRD) written equal to the flat 500 XRD proposal fee, so that a proposal funded its own settlement. The redeploy of 11 September 2026 removed all of it – `lock_settlement_fee`, the allowance ledger and both constants – after a pen-test found the reimbursement could not be scoped to the crank: the Radix engine consumes locked fees in reverse lock order, so the treasury’s lock was drawn before the caller’s and paid the first 5 XRD of _any_ transaction containing one settle-path call, whatever else that transaction did (finding L-2 in `contracts/PENTEST.md`). Den’s refund ceiling holds because the Safe contract enforces it against a signed transaction; the caper’s had nothing equivalent to bind it to, so it was removed rather than repriced. Whoever cranks a caper’s settle path now pays their own network fee.

What survives is the half of the comparison about who can change a number. Den fixes its refund ceiling in the signature, so the signers can re-sign a different one. A caper’s fee schedule – trade fee, the flat 500 XRD proposal fee, the 10% execution-fee rate, the 100 XRD vote fee, window lengths – is written into the logic component at instantiation, and the deployed `CaperMain` exposes twenty public methods and one instantiation function, none of them a setter. Changing any of it takes a new logic component and a governed move of the registry’s `current_main`, which is to say another proposal (`contracts/logic/src/lib.rs`). In place of a refund, the caper makes the crank cheaper: `settle_proposal` folds up to 60 uncounted ballots itself (`SINGLE_PASS_MAX_VOTERS`), so a small proposal settles in one call, and a passed action lapses if nobody executes it within seven days of its resolution (`EXECUTION_WINDOW_SECONDS`). How the rest of the industry pays for execution is covered at [proposal execution costs](/wiki/dao-governance/concepts/analysis/proposal-execution-costs).

## References

- Den, [What is Den?](https://docs.onchainden.com/overview/den) and [Safe Contracts](https://docs.onchainden.com/overview/safe-contracts).
- Den, [Security Practices](https://docs.onchainden.com/overview/security-practices) — the off-chain data and EIP-4361 ownership proof.
- Den, [Paying gas from your Safe](https://docs.onchainden.com/pay-gas-from-safe/how-it-works) and its [FAQ](https://docs.onchainden.com/pay-gas-from-safe/faq).
- Den, [Notifications](https://docs.onchainden.com/notifications/overview), [Organizations](https://docs.onchainden.com/organizations/overview) and [Supported Chains](https://docs.onchainden.com/overview/supported-chains).
- Snapshot, [SafeDAO space](https://snapshot.org/#/safe.eth) and [SafeDAO delegation](https://snapshot.org/#/delegate/safe.eth).
- Safe, [safe-smart-account](https://github.com/safe-fndn/safe-smart-account) – the audited contracts Den builds on. (Renamed from `safe-global/safe-contracts`; the old path now redirects.)