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:

The factory is the canonical deployment point. Vaults deployed outside the factory are not official and may not behave correctly.