# Locksmith > Non-custodial profit vaulting for on-chain traders. ## How it works ### The intercept When you connect your wallet to a dApp like Uniswap, the site gets access to `window.ethereum` — the provider object your wallet injects into every page. Every transaction you approve passes through `window.ethereum.request`. Locksmith wraps this method. When a swap transaction is submitted, it's paused before it reaches your wallet. The extension parses the calldata, identifies the token being sold, calculates whether the trade is at profit against your cost basis, and presents a confirmation overlay. If you confirm the lock, the sell proceeds as normal. Once the sell transaction confirms on-chain, Locksmith reads the actual output from the transaction receipt and deposits the net profit into your vault. The intercept is local — it runs in the page's JavaScript context, communicates with the extension via a nonce-authenticated message channel, and forwards nothing to any server. ### The vault Your vault is a personal smart contract deployed on Base. One address, one vault, one owner. It holds ETH from your locked profits. When profit is deposited: 1. A 0.5% service fee is deducted and sent to the Locksmith fee recipient 2. The remaining amount is locked with your chosen duration 3. A `LockedDeposit` entry is created with the amount and unlock time You can have up to 100 active deposits at once. ### The profit calculation Cost basis is tracked per token per wallet address. When you buy a token, the extension records the ETH spent. When you sell, it calculates the proportion of your position being sold and the corresponding ETH cost. ``` profit = ETH received from sell - cost basis for tokens sold ``` If profit is zero or negative, no overlay is shown and no deposit occurs. ### The full flow ``` User submits swap on Uniswap → Locksmith intercepts eth_sendTransaction → Calldata parsed: token, amount, expected output → Cost basis checked: is this trade at profit? → Overlay shown: "Lock X ETH profit?" → User confirms → Swap sent to wallet, user approves → Sell tx submitted to chain → Locksmith polls for receipt (every 500ms) → Sell confirms on-chain → Actual profit calculated from receipt → depositProfit() called with net profit → Profit locked in vault for chosen duration ``` If the sell fails on-chain, the deposit is aborted. Nothing is locked. ## Install the extension ### Chrome Web Store Install Locksmith from the [Chrome Web Store](#). Available for Chrome, Brave, and any Chromium-based browser. ### Setup 1. Install the extension 2. Click the Locksmith icon and connect your wallet 3. Deploy your vault — this is a one-time on-chain transaction via the factory contract 4. Choose a lock duration (30 min, 2 hr, or 12 hr) 5. Trade as normal on any Uniswap-compatible DEX From that point, Locksmith runs passively. You'll see an overlay whenever a profitable sell is detected. ### Supported wallets * MetaMask * Rabby * Rainbow * Any EIP-1193 compliant browser extension wallet ### Supported chains * Base * Arbitrum * Optimism * Ethereum mainnet ## What is Locksmith Locksmith is a Chrome extension and smart contract system that automatically locks a portion of your trading profits into a time-locked vault. The problem it solves: most crypto traders know they should take profits and hold them, but they don't. The money sits in the wallet and gets redeployed before it has a chance to compound. Locksmith removes the decision from the equation. When you sell a token at profit, Locksmith intercepts the transaction, calculates your net gain, and deposits it into your personal vault — all in the same flow as the original swap. The vault holds it for a fixed period (30 minutes, 2 hours, or 12 hours). You can claim it after the lock expires. ### What it isn't * Not a yield protocol. Your ETH sits in your own contract, not a pool. * Not custodial. Hopeware Ltd cannot access your vault. * Not a trading bot. It doesn't execute trades on your behalf. * Not a tax tool. It doesn't track cost basis for reporting purposes. ### Who it's for Traders who are consistently profitable but consistently give profits back. If you've ever sold a token, watched the price drop, and then bought back in with the proceeds — Locksmith is for you. ## How it works Locksmith sits between your wallet and Uniswap. When you sell a token, it calculates your profit and deposits a portion into a time-locked vault — in the same bundle as your swap, before you can spend it. ### The intercept The extension injects a script into every page at the `window` level, wrapping `window.ethereum.request`. When you trigger a swap, Locksmith intercepts the transaction before it reaches your wallet. It decodes the calldata using Uniswap's Universal Router ABI — supporting V2, V3, and V4 routes, including multi-hop paths and Permit2 signatures. If the transaction is a sell (token → ETH or token → stablecoin), it proceeds to profit calculation. ### Profit calculation Locksmith tracks your cost basis per position using the key `chainId:walletAddress:tokenAddress`. When a sell is detected, it computes: ``` profit = proceeds − cost_basis_of_tokens_sold ``` If profit is positive, the amount is queued for deposit. Cost basis is updated on every buy using a weighted average. Sells reduce the position proportionally. The calculation uses actual on-chain calldata amounts, not price estimates. ### The deposit flow When you click **Lock** in the confirmation overlay: 1. Your sell transaction is submitted to your wallet for approval. 2. Once you approve, the extension captures the transaction hash. 3. It polls the RPC for the transaction receipt (500ms intervals for the first 30 seconds, then every 2 seconds for up to \~3 minutes). 4. If the sell **fails** on-chain, the deposit is aborted. No ETH is locked. 5. If the sell **succeeds**, the extension reads the actual on-chain output from the receipt and calls `depositProfit()` on your vault contract. The deposit is a separate transaction — it will appear in your wallet for approval after the sell confirms. ### Chains Locksmith operates on Ethereum mainnet, Arbitrum, Base, and Optimism. Your vault is deployed per-chain. The extension detects the active chain from the connected wallet and routes accordingly. ### Block scanner fallback In addition to the intercept, Locksmith runs a background block scanner that watches for Uniswap swap events from your wallet address. This catches trades made outside the extension (e.g. directly on app.uniswap.org in another tab, or if the service worker restarted mid-session). Scanner-detected trades trigger a deposit prompt with a short delay once confirmed. ## The vault Each user deploys their own vault — a standalone smart contract on the target chain. No shared pool. No admin keys. No upgrade proxy. ### Deployment Vaults are deployed through `LocksmithFactory`. The factory enforces one vault per wallet address per chain — attempting to deploy a second vault reverts with `VaultAlreadyExists()`. ```solidity function deployVault(uint256 _lockDuration) external ``` The caller becomes the permanent owner. The `feeRecipient` address is set at factory deployment and is immutable — it can only ever receive the protocol fee on deposits. It cannot withdraw principal, modify lock durations, or interact with your vault in any other way. ### Deposits ```solidity function depositProfit(uint256 _discount) external payable onlyOwner ``` Only the vault owner can call `depositProfit`. The function: 1. Deducts the **0.5% service fee** (`SERVICE_FEE_BPS = 50`) and forwards it to `feeRecipient`. 2. Locks the remainder for `lockDuration − _discount` seconds. 3. Records the deposit with a timestamp, allowing early release penalties to be calculated at claim time. The `_discount` parameter is the time reduction earned through your [tier](/tiers). It is clamped on-chain to a maximum of 50% of `lockDuration` — a tier 11 discount cannot produce a lock shorter than half the base duration. The vault accepts a maximum of **100 concurrent deposits** (`MAX_DEPOSITS = 100`). ### Lock durations Three base lock durations are available, set at vault deployment: | Duration | Seconds | | ---------- | ------- | | 30 minutes | 1,800 | | 2 hours | 7,200 | | 12 hours | 43,200 | The duration is fixed per vault. If you want a different lock duration, you deploy a new vault. ### Early release Locked funds can be withdrawn before the lock expires, subject to a **15% penalty** (`EARLY_RELEASE_FEE_BPS = 1500`). The penalty is sent to `feeRecipient`. The remaining 85% is returned to the owner. ### ETH only The vault holds ETH. It does not accept ERC-20 tokens. The `receive()` and `fallback()` functions both revert — ETH cannot be sent to the vault directly. The only deposit path is through `depositProfit()`. ### Claiming Once a deposit's lock period expires, the owner can claim it at face value with no fee. Claiming is per-deposit, not all-or-nothing. ## Tier system As you vault profits, you progress through tiers. Each tier does two things: unlocks a cosmetic upgrade for your island, and applies a time discount to future lock deposits. ### Progression Tiers are based on cumulative ETH vaulted within a single cycle. A cycle resets when you claim your vault. Reaching a threshold unlocks that tier permanently for the current cycle. | Tier | ETH vaulted | Name | Time discount | | ---- | ----------- | ------------------ | ------------- | | 1 | 0.1 ETH | Nature's Touch | −3% | | 2 | 0.2 ETH | Architect's Vision | −5% | | 3 | 0.3 ETH | Light the Way | −8% | | 4 | 0.4 ETH | Life Finds a Way | −12% | | 5 | 0.5 ETH | Fortification | −16% | | 6 | 0.6 ETH | Royal Treasury | −20% | | 7 | 0.7 ETH | House Colors | −25% | | 8 | 0.8 ETH | Stronghold | −30% | | 9 | 0.9 ETH | Expanding Realm | −36% | | 10 | 1.0 ETH | Elemental Power | −42% | | 11 | 1.1 ETH | Ascension | −50% | The discount at each tier is **cumulative** — it represents the total reduction applied from your current highest tier, not an additional increment on top of the previous tier. ### Cosmetic upgrades Each tier unlocks one upgrade slot on your island — an isometric world that grows and changes as you progress. When a tier is reached, one option is randomly rolled from that tier's pool. Rarities are weighted: | Rarity | Weight | Chance | | --------- | ------ | ------ | | Common | 65 | \~65% | | Rare | 30 | \~30% | | Legendary | 5 | \~5% | You can reroll or choose a different option from the tier's pool. The roll is stored locally and locked in when you claim. Each tier has a distinct theme and a pool of 6–9 options spanning all three rarities. Examples: * **Tier 1 — Nature's Touch**: Pond, Stream, Grove, Cherry Blossoms, Mushroom Ring, Enchanted Mist, Waterfall * **Tier 5 — Fortification**: Watchtower, Chapel, Windmill, Phantom Walls, Prismatic Mist, World Tree * **Tier 11 — Ascension**: Starfield, Nebula Cloud, Giant Moon, Cosmic Aura, Eclipse, Ethereal Plane, The Eye, Black Hole, Constellation ### How the discount reaches the contract The extension computes your discount via `computeDiscountSeconds()`: ``` discountSeconds = lockDuration × (1 - tierMultiplier) ``` This value is passed as `_discount` to `depositProfit(uint256 _discount)` on the contract. The contract caps the discount at 50% of the lock duration regardless of what's passed in: ```solidity uint256 effectiveDiscount = _discount > lockDuration / 2 ? lockDuration / 2 : _discount; ``` At tier 11, the multiplier is 0.50, so the full 50% cap is reached. The contract enforces this bound — the extension cannot reduce lock times beyond the contract's hard limit even if it tried. ### Cycles When you claim your vault, the cycle resets. Your tier progress returns to zero, your island cosmetics are cleared, and the cycle begins again. The cosmetic upgrades are local to the extension — they don't exist on-chain. ## Trust model Locksmith is non-custodial. The extension never holds your funds. The contracts have no admin keys, no upgrade mechanism, and no recovery path. ### What the contracts can and cannot do #### `feeRecipient` The only privileged address in the system. It receives the 0.5% service fee on deposits and the 15% early release penalty. That's the full extent of its capability. It cannot: * Withdraw your locked principal * Modify your lock duration * Pause or disable your vault * Access your vault in any other way `feeRecipient` is set once at factory deployment. It is immutable. #### Your vault `depositProfit()` is gated behind `onlyOwner`. Only the wallet that deployed the vault can deposit into it, claim from it, or release early from it. There is no delegated caller, no operator role, and no secondary key. The vault has no `selfdestruct`, no `delegatecall`, and no proxy pattern. The bytecode deployed is the bytecode that runs — permanently. #### Factory The factory's only function is deployment. Once your vault is deployed, the factory has no further relationship with it. There is no registry the factory can modify to affect your vault. ### What the extension can and cannot do The extension reads your wallet address and monitors transactions. It **can**: * Read your on-chain transaction history to detect swaps * Prompt you to approve a `depositProfit()` call after a successful sell * Read your vault state (locked amounts, unlock times) for display It **cannot**: * Submit transactions without your explicit wallet approval * Access funds in your vault * Sign anything on your behalf * Operate without your wallet being connected and unlocked Every transaction — including deposits — requires your explicit approval in your wallet. The extension is a UI that constructs calldata. Your wallet is the only thing that can authorize it. ### What you are trusting * The smart contract code (audited with Slither, Mythril, and Echidna fuzz testing; full Hardhat test suite) * Your browser and wallet extension to correctly execute approvals * The extension not being replaced by a malicious version (standard Chrome extension update risk — mitigate by pinning the version) You are not trusting Locksmith's servers to remain online. The vault is on-chain. If the extension disappears, you can interact with your vault directly through any Ethereum interface using the contract ABI. ### Contract addresses | Chain | Vault Factory | | -------- | -------------------------------------------- | | Base | `0xC9DeF6FB8fD5434a78447bE55318f28b3716a764` | | Optimism | `0xC9DeF6FB8fD5434a78447bE55318f28b3716a764` | The vault address for your wallet can be retrieved by calling `getVault(address owner)` on the factory. ## Trust model ### One vault per user The factory deploys one vault per wallet address. Your vault is a standalone contract — `Locksmith.sol` — with your address hardcoded as owner at deployment. There is no shared contract, no proxy, and no way for the factory to interact with your vault after deployment. ### What the extension can do The extension can: * Read your local cost basis and deposit history * Propose a `depositProfit()` transaction to your wallet * Compute and pass a `_discount` value (capped by the contract at 50%) The extension cannot: * Submit any transaction without your wallet signature * Access or move ETH in your vault * Override lock durations beyond the contract's hard cap * Modify your vault contract Every on-chain action requires an explicit wallet approval. The extension is a transaction builder, not a custodian. ### `onlyOwner` on deposits `depositProfit()` reverts if called by any address other than the vault owner. This means no third party — not Locksmith, not the factory, not any other contract — can deposit into your vault. Your vault accumulates ETH only when you sign a transaction. ### `feeRecipient` is receive-only The `feeRecipient` address is set once at factory deployment and is immutable. It receives ETH from fees and early release penalties. That's its only capability — it has no `onlyOwner` access, no ability to call vault functions, and no upgrade authority. Compromising `feeRecipient` gives an attacker access to fee revenue only, not user funds. ### No upgrade proxy The vault and factory contracts are deployed as plain contracts. There is no `UUPS`, `TransparentUpgradeableProxy`, or any other upgrade mechanism. The deployed bytecode is what runs. Hopeware cannot push contract changes to existing vaults. ### No recovery mechanism There is no admin function to recover stuck funds, override a lock, or drain a vault. If you lose access to the wallet that owns a vault, those funds cannot be retrieved. This is a deliberate tradeoff — eliminating admin recovery also eliminates admin risk. ### No keeper bots The raid penalty system and lock expiry are evaluated lazily, at claim time, using deterministic on-chain inputs. There are no keeper bots, off-chain oracles, or privileged callers required for the protocol to function. All state transitions happen when you transact. ### Open source The contracts and extension source are available for review. The relevant contract addresses are: | Contract | Address | | ------------------------ | -------------------------------------------- | | Factory (Base, Optimism) | `0xC9DeF6FB8fD5434a78447bE55318f28b3716a764` | | Example vault | `0x4C55EC96297d3Ea36091a05817E5132C42d664A8` | The factory is the canonical deployment point. Vaults deployed outside the factory are not official and may not behave correctly. ## The vault Each user gets one vault. It's a standalone contract deployed by the factory — no shared state, no pooled funds. Your ETH is yours alone. ### Deployment The factory contract maintains a registry. When you first use Locksmith, it calls `deployVault(uint256 _lockDuration)` on your behalf, which deploys a fresh `Locksmith.sol` instance with your address as owner. Subsequent deposits go to the same contract. The factory will revert with `VaultAlreadyExists()` if you try to deploy twice. ### Lock durations Three options, set at vault deployment: | Duration | Use case | | ---------- | ----------------------- | | 30 minutes | Short discipline window | | 2 hours | Intraday cooling-off | | 12 hours | Swing trade commitment | The duration applies to all deposits into that vault. To change it, you would need to deploy a new vault — currently not supported in v1. ### Fees A 0.5% service fee (`SERVICE_FEE_BPS = 50`) is deducted on every deposit. The remainder is locked. The fee is sent directly to the `feeRecipient` address set at factory deployment — an immutable address that can only receive ETH. It has no other privileges. ### Early release You can claim a locked deposit before its unlock time by calling `releaseEarly()`. This costs 15% of the locked amount (`EARLY_RELEASE_FEE_BPS = 1500`), which is sent to `feeRecipient`. The remaining 85% is returned to you immediately. There is no admin override. Nobody can force an early release on your behalf, and nobody can block you from calling it yourself. ### Deposit cap A vault can hold a maximum of 100 active deposits (`MAX_DEPOSITS = 100`). Deposits past this limit revert. In practice this is unlikely to be hit — claimed deposits free up slots. ### Direct ETH transfers The vault's `receive()` and `fallback()` functions both revert. There is no way to deposit ETH directly. All ETH enters through `depositProfit()`, which enforces the fee logic and lock accounting. This is intentional — it prevents accidental sends and ensures every wei in the vault is accounted for. ### `onlyOwner` `depositProfit()` is guarded by `onlyOwner`. Only the wallet address that deployed the vault can deposit into it. Nobody else can put ETH into your vault, and nobody else can release your deposits. ## Claiming Once a deposit's lock period expires (and any raid penalty has cleared), you can claim it from the dashboard. ### Single claim Calls `claim(depositIndex)` on your vault contract. Transfers the full deposit amount to your wallet. ### Batch claim The dashboard lets you claim all expired deposits in one transaction via `claimBatch(startIndex, endIndex)`. This is more gas efficient than claiming one at a time if you have multiple deposits ready. ### Raid penalties Your effective unlock time may be later than the base unlock time if you had your shield turned off after depositing. See [How raids work](/raids/overview). The contract calculates raid penalties deterministically at claim time — no keeper bot, no oracle. The dashboard runs the same calculation in JavaScript so you can see your exact unlock time before you try to claim. ## Early release You can unlock any deposit before its lock expires by paying a **15% penalty** on the locked amount. ``` You receive: deposit amount × 0.85 Penalty paid: deposit amount × 0.15 ``` The penalty goes to the Locksmith fee recipient. It is not burned. Early release bypasses both the lock duration and any accrued raid penalty — you pay the flat 15% and the ETH is yours immediately. ### When to use it Early release exists for genuine emergencies. It's deliberately expensive enough to hurt, but not so expensive that it traps you. The 15% penalty is the cost of breaking your commitment. Using early release frequently defeats the purpose of the system. If you find yourself regularly releasing early, consider switching to a shorter lock duration. ### Batch early release `earlyReleaseBatch(startIndex, endIndex)` lets you release a range of deposits in one transaction, paying the 15% penalty on each. ## Fees ### Service fee **0.5%** of each deposited profit, taken at deposit time. This is deducted before the amount is locked — so if you deposit 0.01 ETH profit, 0.00005 ETH goes to the fee recipient and 0.00995 ETH is locked in your vault. The fee recipient address is set at factory deployment and is immutable per vault. ### Early release penalty **15%** of the locked amount, taken if you release a deposit before its lock expires. See [Early release](/vault/early-release) for details. ### No other fees There are no withdrawal fees, no gas surcharges beyond the actual transaction cost, and no ongoing subscription. The 0.5% service fee is the only recurring cost. ## Lock durations Three options: | Duration | Use case | | ---------- | ---------------------------------------------------- | | 30 minutes | Short-term trades, frequent activity | | 2 hours | Default. Enough friction to prevent impulse re-entry | | 12 hours | Aggressive savings mode | You set a duration when you deploy your vault. You can change it at any time with `setLockDuration()` — the new duration applies to future deposits only. Existing deposits are locked for whatever duration was active when they were created. ### Tier discounts Cosmetic tier upgrades (earned through trading volume in the dashboard) reduce your effective lock duration by a percentage. The maximum discount is 50% of your chosen lock duration, regardless of tier. A tier discount on a 2-hour lock can bring it down to a minimum of 1 hour. The discount is applied at deposit time and baked into the unlock timestamp — it isn't recalculated later. ## Contract addresses ### Base (production) | Contract | Address | | ---------------- | -------------------------------------------- | | LocksmithFactory | `0xC9DeF6FB8fD5434a78447bE55318f28b3716a764` | | Vault (example) | Deployed per-user via factory | ### Optimism | Contract | Address | | ---------------- | -------------------------------------------- | | LocksmithFactory | `0xC9DeF6FB8fD5434a78447bE55318f28b3716a764` | ### Source code The contracts are verified on-chain. View the source on Basescan: * [LocksmithFactory](https://basescan.org/address/0xC9DeF6FB8fD5434a78447bE55318f28b3716a764) * [Locksmith.sol](https://github.com/hopewareltd/locksmith) *(GitHub link)* ### Deployment Your personal vault is deployed by calling `deployVault(lockDuration)` on the factory. Each wallet address can only deploy one vault. The factory maps your address to your vault address — `getVault(yourAddress)` returns it. ## What the extension can see The extension wraps `window.ethereum.request` on every page. Here's what that means in practice. ### What it sees * Transaction calldata for swaps you submit through Uniswap (or any compatible DEX) * Your wallet address and chain ID (from `eth_accounts` / `eth_chainId`) * Token amounts and routing data in swap transactions ### What it doesn't see * Your private key (never — the extension never has access to this) * Transactions submitted through other applications or wallets simultaneously * Your full transaction history (it only processes transactions as they happen) * Tokens you hold but haven't traded through a supported DEX ### What it stores locally * Cost basis records: token address, amount held, ETH spent. Stored in `chrome.storage.local`. * Your vault address and lock duration preference * Shield and tier state Nothing is sent to any remote server. All data stays in your browser's extension storage. ### The nonce system The page script and content script communicate via `window.postMessage`. Every message is authenticated with a per-session UUID nonce, generated fresh each time the extension loads. This prevents malicious page scripts from injecting fake messages into the Locksmith message channel. ## Non-custodial design Your vault contract is owned by your wallet address. The `owner` variable is set at deployment and is immutable — it cannot be changed. Only your address can call: * `depositProfit()` * `claim()` / `claimBatch()` * `earlyRelease()` / `earlyReleaseBatch()` * `toggleShield()` * `setLockDuration()` * `setTitanBuff()` There is no admin key. There is no upgrade mechanism. There is no recovery function. Hopeware Ltd has no ability to move funds from your vault. ### What the fee recipient can do The fee recipient address receives the 0.5% service fee and early release penalties. That's it. It cannot interact with your deposits, change your lock durations, or trigger any vault functions. ### No backend The extension communicates directly with your wallet and the chain. There is no Locksmith server that your transactions pass through. Cost basis data is stored in `chrome.storage.local` on your machine. ### Audit status The contracts have been reviewed with Slither, Mythril, and Echidna fuzz testing. A full Hardhat unit test suite is maintained. The contracts have not yet had a formal third-party audit — this will be completed before any significant TVL accumulates. ## How raids work Raids are a gamification mechanic that adds time to your lock period when your shield is turned off. They exist to give the shield toggle meaningful stakes — turning the shield off isn't free. ### The mechanics Time is divided into 3-minute slots. For each slot where your shield was down after a deposit was created, a deterministic hash is computed: ``` keccak256(slotTimestamp, depositIndex, slotNumber) ``` If the result mod 100 is less than 25, that slot is a hit. Each hit adds **30 minutes** to that deposit's unlock time. At a 25% hit rate, you'd expect roughly one hit every 12 minutes of shield-down time. Over an hour of vulnerability, that's approximately 2 hours of added lock time. ### Lazy evaluation Raid penalties are not stored on-chain. They're calculated fresh each time `claim()` or `getDeposit()` is called, using the historical shield toggle timestamps. This means: * No keeper bot required * No gas cost at deposit time * The calculation is fully deterministic and reproducible The dashboard runs the identical calculation in JavaScript, so the unlock timer you see is exactly what the contract will produce. ### Titan buff Enabling the Titan buff halves the penalty per raid hit: 30 minutes becomes 15 minutes. The buff is toggled on-chain and costs a transaction. ## Shield mechanics The shield is a boolean flag on your vault contract. It's on by default when you deploy. ### What it does With the shield **on**, your deposits are not vulnerable to raid penalties. The shield-down windows are recorded as a chronological array of toggle timestamps on-chain. With the shield **off**, every 3-minute slot that passes may add 30 minutes to your lock durations. See [How raids work](/raids/overview). ### Toggling Call `toggleShield()` on your vault. Each toggle records `block.timestamp` to the `shieldToggleTimestamps` array. The shield state is derived from the length of this array: * Even length (0, 2, 4...) = shield ON * Odd length (1, 3, 5...) = shield OFF Since the shield starts ON and the constructor records nothing, a fresh vault has an empty array (even = ON). ### Why you'd turn it off The shield is a deliberate commitment mechanic. Turning it off while you have active deposits puts them at risk. The expected use case is leaving the shield on at all times unless you have a specific reason to accept the risk. Future versions may introduce mechanics that reward shield-down time, but currently there is no benefit to disabling it.