# Vault Source: https://docs.settlemint.com/docs/architecture/components/capabilities/vault The Vault capability provides contract-level treasury custody for ETH and ERC-20 tokens, with signer roles, EIP-712 transaction signatures, configurable signature thresholds, weighted-signature support, and emergency pause controls. The Vault is DALP's contract-level treasury custody capability. A vault can hold ETH and ERC-20 tokens, store proposed transactions, collect signer signatures, and execute the transaction when the configured threshold is reached. ## What the vault controls [#what-the-vault-controls] The vault controls treasury transactions for assets already held by the vault contract: * native ETH transfers * ERC-20 token transfers through contract-call calldata * general contract calls to a target address * transaction comments and on-chain events for operational traceability The vault does not issue assets, run investor identity checks, or decide whether a token transfer is compliant. Issuance, identity, and transfer compliance sit in the SMART Protocol and compliance layers. The vault can have its own on-chain identity, and governance controls whether claims can be added to or removed from that identity. ## Owned contracts [#owned-contracts] | Contract | Responsibility | | ------------------------------ | -------------------------------------------------------------------------------- | | DALPVault | Stores transactions, validates signatures, executes calls, and pauses operations | | DALPVaultFactoryImplementation | Deploys vault instances through the vault factory | ## Roles [#roles] | Role | Permissions | | ---------------- | ------------------------------------------------------------------------------------------------- | | SIGNER\_ROLE | Submit transactions and add valid signatures to pending transactions | | EMERGENCY\_ROLE | Pause and unpause vault operations | | GOVERNANCE\_ROLE | Change signature requirements, configure weighted signatures, and set the vault on-chain identity | Role separation keeps transaction approval separate from parameter changes. Signers can propose and sign transactions. Governance changes the rules that govern signing. Emergency operators can stop vault activity during an incident. ## Transaction lifecycle [#transaction-lifecycle] The vault follows a proposal-signature-execution model: 1. **Proposal**. A signer submits the target address, ETH value, calldata, comment, and required signature count. If the required count is `0`, the vault uses the default requirement. 2. **Signature collection**. Signers provide EIP-712 signatures for the stored transaction hash. The vault rejects unauthorized signers, invalid signatures, duplicate signatures, mismatched signature arrays, and signatures added after execution. 3. **Execution**. The vault executes automatically when the collected signatures satisfy the active threshold. If the underlying call fails, the vault reverts the execution and leaves the transaction unexecuted. There is no separate manual execute step in the current vault contract. Execution is attempted when signatures are processed and the threshold is met. ## Signature threshold modes [#signature-threshold-modes] | Mode | How execution threshold is evaluated | | ------------------- | --------------------------------------------------------------------------------------------------------------------- | | Standard signatures | The number of unique valid signer signatures must meet the transaction requirement | | Weighted signatures | Each signer contributes a configured weight, and the total collected weight must meet the configured weight threshold | Governance can enable or disable weighted signatures, set signer weights, set the total weight required, and change the default required signature count. In standard mode, a transaction can carry its own required signature count when submitted. In weighted mode, execution uses the configured total weight requirement instead of the per-transaction signature count. ## Transaction types [#transaction-types] | Type | Description | | --------------- | -------------------------------------------------------------------------- | | ETH transfer | Sends native currency from the vault to a recipient address | | ERC-20 transfer | Calls an ERC-20 token contract, typically with encoded `transfer` calldata | | Contract call | Calls any target contract with the submitted calldata and ETH value | All transaction types use the same stored transaction model. The vault validates signers and signatures, then executes the target call. The vault does not inspect whether the calldata represents a simple transfer, a token operation, or another contract interaction. ## Controls and operating limits [#controls-and-operating-limits] | Control | Behaviour | | ------------------------------- | --------------------------------------------------------------------------------------------------- | | Signer role check | Only accounts with `SIGNER_ROLE` can submit transactions or add signatures | | Duplicate signature rejection | The same signer cannot be counted twice for one transaction | | Pause control | When paused, ETH deposits, new submissions, and signature processing are blocked | | Governance-only configuration | Only `GOVERNANCE_ROLE` can change requirements, weighted-signature settings, and the vault identity | | One-time vault identity setting | The vault on-chain identity can be set once, either at construction or later by governance | | Execution failure handling | A failed target call reverts with no successful fund movement for that transaction | ## Events and evidence [#events-and-evidence] The vault emits events for deposits, submitted transactions, signature collection, execution, requirement changes, weighted-signature toggles, signer-weight updates, and on-chain identity assignment. These events give operators and auditors a chain-native record of treasury activity and governance changes. ## Failure modes [#failure-modes] | Failure | System behaviour | | ------------------------------ | ---------------------------------------------------------------------------- | | Insufficient signatures | The transaction stays pending and unexecuted | | Invalid or duplicate signature | The signature submission reverts and does not change the transaction state | | Unauthorized signer | The submission reverts because the address does not hold `SIGNER_ROLE` | | Paused state | Deposits, new proposals, and signature processing are blocked until unpaused | | Failed target call | Execution reverts and the transaction remains unexecuted | | Invalid requirement | Governance cannot set a requirement of zero or above the signer count | ## Related [#related] * [Capabilities layer overview](/docs/architecture/components/capabilities) for how capabilities extend the platform * [SMART Protocol integration (ERC-3643)](/docs/architecture/components/asset-contracts/smart-protocol-integration) for the compliance framework * [Custody provider integrations](/docs/architecture/integrations/custody-providers) for how external custody providers fit around DALP * [Key flows](/docs/architecture/start-here/key-flows) for a broader view of asset, identity, and transaction flows * [Component catalog](/docs/architecture/components) for the full platform inventory