Den is an operations layer for organisations whose money sits in a 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. What it adds is everything that happens between a transaction being proposed and the threshold being met — the part of treasury operations 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", 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: 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 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.
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 make for voting, applied to the custody layer — and it bears on the participation-rate arithmetic DAOs now use to price governance work.
Reading what you sign
The second problem Den names is comprehension: complex calldata, numbers divided by 1018, and no context for what a payload actually does. Den decodes transaction data, lets owners attach plain-language descriptions, supports simulation at creation time and again before execution, and offers a 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 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 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, 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 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, 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: it votes in SafeDAO as a delegate, publishing two delegate addresses, jgov.onchainden.eth and igov.onchainden.eth, and inviting $SAFE holders to delegate to them on Snapshot. SafeDAO is a substantial governance body — 17,717 followers and 55 proposals on its Snapshot space as of August 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, 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 (which turns vendor invoices into batched multisig payments) and distinct from an asset manager like karpatkey, which decides what the treasury holds. On Solana the equivalent role is bundled into 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 has no signer set, so the coordination bottleneck Den exists to solve has no surface to appear on. A proposal that passes is executed against the treasury by the contract after its execution delay; there is no interval in which a passed decision waits on individuals to sign.
Caper converges with Den on the gas question, from the other direction. Settling a large ballot is genuinely expensive work — the tally is crystallised in chunks across many transactions — and none of it depends on the proposal passing, so charging it to whoever clicks settle taxes one member for a public good. The contract reimburses each settle-path call from the caper's own treasury against a per-call ceiling (SETTLEMENT_GAS_PER_CALL) and a per-proposal budget (SETTLEMENT_GAS_BUDGET) sized to the proposal fee that proposal already paid in, so a proposal funds its own settlement and cannot draw down the treasury beyond its own contribution; past the budget the caller pays, which degrades the path rather than bricking it (contracts/logic/src/lib.rs). Den fixes the refund ceiling in the signature; a caper fixes it in a constant and a per-proposal allowance. Both refuse to leave execution costs on whoever happened to be available.
References
- Den, What is Den? and Safe Contracts.
- Den, Security Practices — the off-chain data and EIP-4361 ownership proof.
- Den, Paying gas from your Safe and its FAQ.
- Den, Notifications, Organizations and Supported Chains.
- Snapshot, SafeDAO space and SafeDAO delegation.
- Safe, safe-contracts — the audited contracts Den builds on.