Den is a company that builds treasury software for organisations holding crypto assets. Its first product was an operations layer for organisations whose money sits in a Safe multisig: it deployed no contracts of its own, being, in its documentation's words, built on the Safe Contracts with no additional smart contract code, and it handled the work between a transaction being proposed and its threshold being met. Den's site now presents a different product, the Multi-Layer Security Wallet, 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.
A Safe is designed so that no minority can move funds, which also means no minority can move funds when they should. Den's documentation named coordination as the first problem it solved: teams "spend days getting everyone to sign multisig transactions", with hardware wallets far away and signers who forget. A 4-of-7 treasury that cannot assemble four signatures inside a week cannot act, and nothing about that failure shows on-chain: it shows up as proposals that passed and payments that never went out.
This differs from the failures catalogued under how DAOs fail: the vote carries, and execution stalls because the people who must sign are individuals with day jobs.
Den's Discord, Telegram, Slack and SMS bots posted when a transaction was created, executed or rejected, and reminders repeated at a set frequency until a pending transaction was executed. The bots tagged the signers who had not yet signed and produced statistics on the least active signers.
Those statistics give a DAO a record it otherwise lacks. A signer set is usually appointed by a vote and never measured again, and a signer who has stopped signing lowers the effective threshold without anyone voting on it. Measuring signers this way parallels what delegate scorecards do for voting, and bears on the participation-rate figures DAOs use to pay for governance work.
The second problem Den named was comprehension: complex parameters, numbers divided by 1018, and no context for what a payload does. Den decoded transaction data, let owners attach plain-language descriptions, ran a simulation when a transaction was created and again before execution, and offered a custom transaction builder and JSON upload, so teams no longer kept their own scripts to build treasury calls.
Den's security page set out the limit of this. Because Den added no contracts, it "is not able to modify the Safe Contracts or any transactions that a user has signed or executed". The descriptions and address labels signers read were off-chain data on Den's servers, visible to Safe owners who proved ownership with an EIP-4361 signature. The readable account of a transaction could change; the payload could not. Decoding and simulation read the payload itself, so they carry more weight than the description field.
Den set new transactions to have the Safe reimburse whoever executed them. Gas refunds are native functionality of the Safe contracts; Den turned them on by default and executed through a relayer, so a signer holding none of the chain's native token was no longer a blocker. The maximum refund was part of the signed transaction and enforced by the Safe contract, so the most a treasury could pay for gas was fixed when the owners signed, not left to the executor. A DAO that reimburses signers by hand pays for a second transaction each time, through a discretionary process with no such ceiling.
Above the single Safe, Den grouped related Safes into an organisation, gave non-signers permission to read and annotate the off-chain data, and exported categorised bookkeeping to accounting software, which its documentation described as a premium tier in limited early access.
Den also took a role the wiki covers under DAO service providers: it published two delegate addresses in SafeDAO, jgov.onchainden.eth and igov.onchainden.eth, and invited $SAFE holders to delegate to them on Snapshot. A vendor whose product depended on the Safe contracts held delegated votes in the DAO that stewards them, the same mix of alignment and conflict mapped on that page. Den disclosed the arrangement.
In the layering on the DAO tooling stack, the Safe-layer app was not a custody choice; the custody choice was Safe. Den ran operations over that choice, in the same band as Request Finance, which turns vendor invoices into batched multisig payments, and apart from an asset manager like karpatkey, which decides what a treasury holds. On Solana Squads bundles the same role into the multisig itself.
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 (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). 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).
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). 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). Den pays the network fees and bills usage above each plan's allowance (platform docs).
A caper has no signer set, so the signature bottleneck Den was built for has no place to appear. A proposal that passes is executed against the treasury by the contract, and anyone can resolve it when its window closes and execute the action it carries; 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 treasury reimburses nobody. How the rest of the industry pays for execution is covered at proposal execution costs.