Category Treasury · multisig operations What it does (Safe-layer app) · enterprise wallet (from 2026) Safe-layer app An operations layer on top of an existing Safe (/wiki/dao-g…rnance/tooling/treasury/safe) –: notifications, decoded transa…imulation and payment requests to get signatures collected Smart contracts None. "Built on the Safe Contracts…mart 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 ( doc, archived (https://web.archive.org/web/20260421200635/https://docs.onchainden.com/overview/safe-contracts) ) Current product Multi-Layer Security Wallet (https://docs.mls.onchainden.com/index) : Den's own wallet for company treasuries and for wallets issued to customers, with policies checked on the signing device, by Den's Guardian service and on-chain Contracts Safe-layer app: none. Wallet: open source (https://github.com/OnChainDen/mls-contracts) , audited by yAudit (April 2026) and Certora (May 2026) ( audits (https://docs.mls.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.ethsmart-contracts/audits) ) Networks Safe-layer app: 13 EVM chains where Safe's official deployments ran ( archived docs (https://web.archive.org/web/20260518174551/https://docs.onchainden.com/overview/supported-chains) ). Wallet: Ethereum, Arbitrum One, Base, Optimism, Ronin ( deployments (https://docs.mls.onchainden.com/smart-contracts/deployments) ) Site onchainden.com (https:….com/) · docs (https://docs.mls.onchainden.com/index) Related Safe (/wiki/dao-g…/tooling/dao-tooling-overview)

Den is a company that builds treasury software for organisations holding crypto assets. Its first product was an operations layer for organi…oling/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: it deployed no contracts of its own, being, in its documentation's words, built on the Safe Contracts … smart contract code (https://web.archive.org/web/20260421200635/https://docs.onchainden.com/overview/safe-contracts) . What it adds is everything that happens, and it handled the work between a transaction being proposed and theits 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. Den's site now presents a different product, the Multi-Layer Security Wallet (https://onchainden.com/) , which holds funds in Den's own contracts. The Safe-layer documentation at docs.onchainden.com stopped answering by 24 October 2026 and still timed out on 29 October, so the sections on the Safe-layer app below cite the Internet Archive's copies.

The bottleneck is inaction, not theftSignatures that never arrive A Safe is designed so that no minority can move funds. The corollary, which gets far less attention, is that, which also means no minority can move funds even when they should. Den's own framing of the problem it solves names coordination firstdocumentation named coordination as the first problem it solved: teams " spend days getting e…ultisig transactions (https://web.archive.org/web/20230130152704/https://docs.onchainden.com/overview/den) ", with hardware wallets in the wrong citfar away and signers who simply forget. A 4-of-7 treasury that…four signatures inside a week is, operationally, a treasury that cannot act –, and unlike a capture attack, nothing about that failure is visibleshows on-chain. I: it shows up as proposals that p…ts that never went out. This is a distinct failure modediffers from the onfailures catalogued under how DAOs …epts/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 productbecause the people who must sign are individuals with day jobs.

Coordination as the product Den's answer is deliberately unglamorous.Reminders and signer statistics Den's Discord, Telegram, Slack and SMS bots fireposted when a transaction iwas created, executed or rejected, and then keep firing: reminder notification reminders repeated at a configuredset frequency (https://web.archive.org/web/20260518183833/https://docs.onchainden.com/notificati… until a pending transaction iwas executed. The bots tagged the signers who haved not yet signed, and generateproduced statistics on who the least active signers are ((https://web.archive.org/web/20230130152704/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: aose statistics give a DAO a record it otherwise lacks. A signer set is usually appointed by a vote and then never measured again, and a membsigner 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 tlowers the effective threshold without anyone voting on it. Measuring signers this way parallels what delegate scorecards (/wik…nce/tooling/analytics/karma) makedo for voting, applied to the custody layer – and itnd bears on the participation-rate arithmeticfigures (/wiki/dao-governance/concept…ate-incentive-programs) DAOs now use to priceay for governance work.

Reading what you sign The second problem Den names id was comprehension: complex calldataparameters, numbers divided by 1018 (https://web.archive.org/web/20230130152704/https://docs.onchainden.com/overview/d…no context for what a payload actually does. Den decodesd transaction data, lets owners attach plain-language descriptions, supports ran a simulation at creation time (when a transaction was created (https://web.archive.org/web/20260518183525/https://docs.onchainden.com/cr…in before execution (https://web.archive.org/web/20260710112928/https://docs.onchainden.com/signing-an…cuting/simulation) , and offersed a custom transaction builder (https://web.archive.org/web/20260710101505/https://docs.onchainden.com/creating-t…/custom-transaction-builder) plusand JSON upload, so that teams stop maintaining bespokeeams no longer kept their own scripts to constructbuild treasury calls. There is a structural point worth stating plainly here, and Den's own security page (https://web.archive.org/web/20260609171325/https://docs.onchainden.com/overview/security-practices) is the source for itset out the limit of this. Because Den addsed no contracts, it "is not able…a user has signed or executed" – the custody guarantee is untouched. But t. The descriptions and address labels that signers read awere off-chain data held on Den's servers, visible to Safe owners who proved ownership with an EIP-4361 (…rg/EIPS/eip-4361) signature. So the human-The 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 itselfcould change; the payload could not. Decoding and simulation read the payload itself, so they carry more weight than the description field.

Gas paid from the Safe Den defaultsset new transactions to havinge the Safe reimburse whoever executesd them. This is not a Den invention: gGas refunds are native functio…f the Safe contracts (https://web.archive.org/web/20260609182130/https://docs.onchainden.com/pay-gas-from-safe/how-it-works) , exposed in Safe.sol's execution parameters. Den's contribution is turning it; Den turned them on by default and routing executioned through a relayer, so a signer holding no native token on the chain in question ine of the chain's native token was no longer a blocker.The safety property is the part worth noting: the maximum refund is included in the signature itself ( maximum refund was part of the signed transaction (https://web.archive.org/web/20260609171447/https://docs.onchainden.com/pa… by the Safe contract, so the ceiling on whamost a treasury can pay outould pay for gas iwas fixed at signing time rather than trustedwhen the owners signed, not left to the executor. A DAO that reimburses signers manually insteaby hand 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 quesSafeDAO delegation Above the single-Safe view, Den groupsed related Safes into an organisation, letsgave non-signers holdpermission to read-and-annotate permissions on the off-chain data, and exportsed categorised bookkeeping to conventional accounting software. Den documents this as an upcoming, which its documentation described as a premium tier in limited early access (https://web.archive.org/web/20260710110623/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. Den also took a role the wiki covers under DAO se…s/dao-service-providers) : it votpublished two delegate addresses in SafeDAO (/wiki/daos/infrastructure/safe-dao) as a delegate, publishing two delegate addresses, jgov.onchainden.eth and igov.onchainden.eth, and invitinged $SAFE holders to delegate to…hot.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 dependsed on a set ofthe Safe contracts hoelding delegated voting poweres 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 disappearem, the same mix of alignment and conflict mapped on that page. Den disclosed the arrangement.

Where it sitsat in the stack In the layering described on the DAO tooling stack (/wi…oling/dao-tooling-overview) , Den ithe Safe-layer app was not a custody choice –; the custody choice iwas Safe. It is Den ran operations veneer over a custody decision already madover that choice, in the same band as Reques…ing/treasury/request-finance) ,(which turns vendor invoices into batched multisig payments), and distincapart from an asset manager like …rpatkey) , which decides what thea 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 partiesbundles the same role into the multisig itself.

How Caper approaches this A …r) has no signer set, so the coordinationsignature bottleneck Den exists to solvewas built for has no surfplace to appear on. A proposal (/wiki/governanc…i/governance/execution) , and both halves of that – resolving the proposalanyone can resolve it when its window closes, and executinge 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 – the 500 XRD floor and 1% rate of the proposal fee, the 100 XRD vote fee, window lengths – is written into the logic component at instantiation, and the deployed CaperMain exposes twenty-one 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 refu; no passed decision waits on individuals to sign. A passed action that nobody executes within its execution window lapses, so an approved payment cannot sit unexecuted indefinitely. Whoever resolves or executes a proposal pays their own network fee, and, 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)treasury reimburses nobody. How the rest of the industry…is/proposal-execution-costs) .

References - Den, What is Den? (https://web.archive.org/web/20230130152704/https://docs.onchainden.com/overview/d… and Safe Contracts (https://web.archive.org/web/20260421200635/https://docs.onchainden.com/overview/safe-contracts) (Internet Archive copies). - Den, Security Practices (https://web.archive.org/web/20260609171325/https://docs.onchainden.com/overview/security-practices) –: the off-chain data and EIP-4361 ownership proof (Internet Archive copy). - Den, Paying gas from your Safe (https://web.archive.org/web/20260609182130/https://docs.onchainden.com/pay-gas-fr…works) and its FAQ (https://web.archive.org/web/20260609171447/https://docs.onchainden.com/pay-gas-from-safe/faq) (Internet Archive copies). - Den, Notifications (https://web.archive.org/web/20260518183833/https://docs.onchainden.com/notificati…ew) , Organizations (https://web.archive.org/web/20260710110623/https://docs.onchainden.com/organizati…nd Supported Chains (https://web.archive.org/web/20260518174551/https://docs.onchainden.com/overview/supported-chains) . - Snapshot, SafeDAO space (https://snapshot.org/#/safe.eth) and (Internet Archive copies). - Den, Multi-Layer Security Wallet documentation (https://docs.mls.onchainden.com/index) : Platform (https://docs.mls.onchainden.com/core-concepts/platform) , Policies (https://docs.mls.onchainden.com/core-concepts/policies) , Security Layers (https://docs.mls.onchainden.com/enterprise-security/security-layers) , Disaster Recovery (https://docs.mls.onchainden.com/enterprise-security/disaster-recovery) , Security Audits (https://docs.mls.onchainden.com/smart-contracts/audits) and Deployments (https://docs.mls.onchainden.com/smart-contracts/deployments) . - Den, mls-contracts (https://github.com/OnChainDen/mls-contracts) : the wallet's open-source contracts. - Den, How to plan a migration from Safe to a policy-based wallet (https://onchainden.com/blog/migrating-from-safe-to-policy-based-wallets) (5 August 2026). - Snapshot, SafeDAO delegation (https://…safe-fndn/safe-smart-account) –: the audited contracts Den builds on. (Renamed from safe-global/safe-contracts; the old path now redirects.)the Safe-layer app built on.

The Multi-Layer Security Wallet Den's current product holds funds in Den's own contracts rather than in a Safe, and Den's blog publishes a guide to moving a treasury from a Safe to a policy-based wallet (https://onchainden.com/blog/migrating-from-safe-to-policy-based-wallets) (5 August 2026) with its wallet as the destination. An organisation in it has members, groups, accounts that hold funds, admins, and policies that say which transactions are allowed and who approves them ( platform docs (https://docs.mls.onchainden.com/core-concepts/platform) ). A policy either approves a matching transaction automatically or requires approval from named members or groups, can match on token, recipient, amount, contract, function and arguments, and can cap how much moves in a day, week or month ( policies (https://docs.mls.onchainden.com/core-concepts/policies) ). Every transaction is checked against the policies three times: by the signing client, a mobile app or Den's SDK, before anything is signed; by Den's off-chain Guardian service, which co-signs; and by the contracts on-chain, where a transaction that fails the check reverts ( security layers (https://docs.mls.onchainden.com/enterprise-security/security-layers) ). If the Guardian becomes permanently unavailable, two recovery paths behind timelocks of 2 to 30 days let the organisation replace the Guardian or transact without it, the second bypassing the policies ( disaster recovery (https://docs.mls.onchainden.com/enterprise-security/disaster-recovery) ). Den pays the network fees and bills usage above each plan's allowance ( platform docs (https://docs.mls.onchainden.com/core-concepts/platform) ).

Category Treasury · multisig o…nance/tooling/treasury/safe) —– notifications, decoded transa…fe's official deployments run —– Ethereum, Polygon, Optimism, …/tooling/dao-tooling-overview)

Den is an operations layer for…d and the threshold being met —– the part of treasury operati…ther than a cryptographic one.

The bottleneck is inaction, no…y, a treasury that cannot act —– and unlike a capture attack, …lection itself as the product.

Coordination as the product D… applied to the custody layer —– and it bears on the particip… use to price governance work.

Reading what you sign The sec… user has signed or executed" —– the custody guarantee is unto…t is not a flaw in the design —– it is where the design draws …rived from the payload itself.

Gas paid from the Safe Den de… second transaction each time —– and, more importantly, pays i… process with no such ceiling.

Organisations, bookkeeping and…a substantial governance body —– 17,720 followers and 55 prop… make the structure disappear.

Where it sits in the stack In…, Den is not a custody choice —– the custody choice is Safe. I…low above it to third parties.

References - Den, What is De…overview/security-practices) —– the off-chain data and EIP-43…; the old path now redirects.)

How Caper approaches this A …sal funded its own settlement.The redeploy of 11 September 2…nction, none of them a setter.Changing any of it takes a new…is/proposal-execution-costs) .

How Caper approaches this A … A caper’s fee schedule – the flat 500 XRD proposal fee, thefloor and 10% execution-fee ratrate of the proposal fee, the 100 XRD vote fee, windo…is/proposal-execution-costs) .

How Caper approaches this A …loyed CaperMain exposes twenty-one public methods and one instan…is/proposal-execution-costs) .

How Caper approaches this A … one. A caper’s fee schedule – trade fee, the flat 500 XRD proposal fee…is/proposal-execution-costs) .

How Caper approaches this A …loyed CaperMain exposes twenty-two public methods and one instan…is/proposal-execution-costs) .

How Caper approaches this A …n individuals to sign. Caper used to converges with Den on the gas question, from the other direction. Cranking a permissionless public good costs whoever happens to call it, and none of that cost depends on the proposal passing, so leaving it there taxes one member on everyone’s behalf. Tand since 11 September 2026 it does not. Until that date the contract contingently reimbursesd each settle-path call out of the caper’s own treasury, against a per-call ceiling (S…NT_GAS_PER_CALL, 5 XRD) and a single per-proposal allowance (SETTLEMENT_GAS_BUDGET, 500 XRD) that covers the resolve and the execution it enables together. The ceiling is a ceilingwritten 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 nbot a charge – the engine refh constants – after a pen-test founds the unused part of each lock – and the allowance is deliberately set equal to the flat proposal fee (PROPOSAL_FEE, also 500 XRD) that the proposal already banked at creation and keeps whether it passes or fails, so a proposal funds its own settlement and cannot draw 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 treasury below what it contributed. Where the two part company ishan 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 thea number. Den fixes its refund …-sign a different one. A caper cannot: the deployed CaperMain exposes twenty-two public methods and one instantiation function, and not one of them is a setter, so the whol’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 onceinto the logic component at instantiation, and fixed for that component’s life, with the two settlement-gas numbers compiled into the package itselfthe deployed CaperMain exposes twenty-two public methods and one instantiation function, none of them a setter. Changing any of it takes a n…(contracts/logic/src/lib.rs). Both designs refuse to leave execution costs on whoever happened to be available; only one of them pIn 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 the refund policy beyondit within seven days of its resolution (EXECUTION_WINDOW_SECONDS). How the reachst of the people it paysindustry pays for execution is covered at proposal execution costs (/wiki/dao-governance/concepts/analysis/proposal-execution-costs) .

Organisations, bookkeeping and…antial governance body — 17,71720 followers and 55 proposals (h…fe.eth) on its Snapshot space as of August, read from Snapshot's GraphQL API on 3 September 2026. A vendor whose product … make the structure disappear.

How Caper approaches this A …deliberately set equal to the flat proposal-fee floor (PROPOSAL_FEE_MIN, also 500 XRD) that the proposal already banked at creation and keeps whether it passes or fails, so a proposal funds its own …he deployed CaperMain exposes eighteentwenty-two public methods and one instantiation function, and not one of them is a sett…he whole schedule – trade fee, flat proposal fee rate and floor, settlement allowanc, 10% execution-fee rate, vote fee, window lengths – is written…ixed for that component’s life, with the two settlement-gas numbers compiled into the package itself. Changing any of it takes a n…e reach of the people it pays.

How Caper approaches this A …on) , and both halves of that —– resolving the proposal when i…ecuting the action it carries —– are permissionless. There is …is a ceiling and not a charge —– the engine refunds the unused part of each lock —– and the allowance is delibera…setter, so the whole schedule —– trade fee, proposal fee rate …ent allowance, window lengths —– is written once at instantiat…e reach of the people it pays.

How Caper approaches this A … (/wiki/governance/execution) , after its execution delay; tnd 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…on, from the other direction. SettlCranking a large ballot is genuinely expensive work, since the ballots are released to the immortal record three at a time across many transactionspermissionless public good costs whoever happens to call it, and none of ithat cost depends on the proposal passing, so chargleaving it to whoever clicks settle taxes one member for a public goodhere taxes one member on everyone’s behalf. The contract contingently reimburses each settle-path call fromout of the caper'’s own treasury against a per-c…iling (SETTLEMENT_GAS_PER_CALL) and a, 5 XRD) and a single per-proposal allowance (SETTLEMENT_GAS_BUDGET, a contract constant of 500 XRD)500 XRD) that covers the resolve and the execution it enables together. The ceiling is a ceiling and not a charge — the engine refunds the unused part of each lock — and the allowance is deliberately set equal to the proposal-fee floor (PROPOSAL_FEE_MIN, also 500 XRD) that the proposal already banked, so a proposal funds its own settlement and cannot draw down the treasury beyondlow what it contributed. The direction of that guarantee Where the two part company is who can change the number. Den fixes its refund ceiling isn the opposite of what it looks like: the allowance is fixed in the csignature, so the signers can re-sign a different one. A caper cannot: the deployed CaperMain exposes eighteen public methodes and the fee is what bends to it, because update_fees asserts proposal_fee >= SETTLEMENT_GAS_BUDGET — an admin can raise the proposal fee and can never cut it below the allowance. 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 pnot one of them is a setter, so the whole schedule — trade fee, proposal fee rate and floor, settlement allowance, window lengths — is written once at instantiation and fixed for that component’s life. 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 allowance. Both(contracts/logic/src/lib.rs). Both designs refuse to leave execution cos…oever happened to be available; only one of them puts the refund policy beyond the reach of the people it pays.

How Caper approaches this A …r cut it below the allowance. pPast the budget the caller pays…ever happened to be available.

How Caper approaches this A …_PER_CALL) and a per-proposal budgetallowance (SETTLEMENT_GAS_BUDGET) sized to the proposal fee that proposal already paid in, a contract constant of 500 XRD), so a proposal funds its own …draw down the treasury beyond its own contribution;what it contributed. The direction of that guarantee is the opposite of what it looks like: the allowance is fixed in the code and the fee is what bends to it, because update_fees asserts proposal_fee >= SETTLEMENT_GAS_BUDGET — an admin can raise the proposal fee and can never cut it below the allowance. past the budget the caller pa…ever happened to be available.

How Caper approaches this A …ot is genuinely expensive work —, since the tbally is crystallised in chunksots are released to the immortal record three at a time across many transactions —, and none of it depends on the…ever happened to be available.

References - Den, What is De…te/safe.eth) . - Safe, safe-contractssmart-account (https://github.com/safe-global/safe-contractsfndn/safe-smart-account) —– the audited contracts Den builds on. (Renamed from safe-global/safe-contracts; the old path now redirects.)

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,717 followers and 55 proposals (https://snapshot.org/#/safe.eth) 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 (/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) 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? (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-contracts (https://github.com/safe-global/safe-contracts) — the audited contracts Den builds on.