Lazarus

Lazarus Protocol is a decentralized "Dead Man's Switch" designed to solve the critical problem of lost crypto assets due to inactivity, accidents, or lost keys. In the Web3 world, if you go silent, your assets usually die with your wallet. Lazarus changes this by allowing users to set up an automated, non-custodial digital will.

Users register a beneficiary and a custom timeout period (e.g., 7 days) on our Source Contract. To prove they are active, they simply sign gasless "Heartbeat" messages off-chain. As long as the heart beats, the assets remain safe in the user's wallet.

However, if the user fails to check in before the deadline, the protocol assumes the worst and triggers the "Lazarus Event." This automated process liquidates the user's defined tokens, swaps them into a stable asset, and bridges them cross-chain to a secure Vault on a destination chain for the beneficiary to claim. It ensures digital legacies are preserved and transferred autonomously, without requiring the beneficiary to have access to the original private keys.

I built Lazarus Protocol using a modern Web3 stack designed for security and automation.

The Core Stack: Smart Contracts (Foundry): I deployed LazarusSource.sol on Sepolia to manage user state and LazarusVault.sol on Arbitrum to receive funds.

Frontend: Built with Next.js, Wagmi, and RainbowKit for a seamless connection experience.

Watchtower (Backend): A Node.js server that acts as the "Keeper." It listens for heartbeats and runs a cron job to check for expired users.

Partner Technologies:

1. Yellow Network (State Channels): I utilized Yellow's architecture to implement a "Proof of Life" state channel. Users sign EIP-712 messages to prove they are alive. These are stored off-chain by the Watchtower and only settled on-chain (pingFor) once every 24 hours. This allows users to heartbeat continuously without paying gas fees.

2. LI.FI (Cross-Chain Evacuation): This is my evacuation engine. When a user is declared "dead," the bot queries the LI.FI API for the best route to swap assets to USDC and bridge them to Arbitrum. The smart contract executes this complex swap-and-bridge in a atomic transaction which makes it revert and retry if it fails.

3. ENS (Ethereum Name Service): To prevent critical "fat-finger" errors during inheritance setup, we integrated ENS resolution on the frontend. Users can simply type a human-readable name (e.g., grandson.eth) as their beneficiary. Our interface automatically resolves and validates this against Mainnet before registering it contract, ensuring assets are never sent to a typo-ridden address.

Hacky & Noteworthy: I implemented some clever engineering to handle edge cases and security risks:

1. "Deep Packet" Calldata Inspection (Security) Most protocols blindly execute cross-chain data. I realized a compromised Watchtower could swap user funds to their own wallet. To fix this, I wrote a custom Solidity loop in LazarusSource.sol that scans the raw bytes of the LI.FI bridge payload. It verifies that the user’s beneficiary address is actually present in the calldata before execution, preventing redirection attacks.

2. The "Omni-Liquidation" Algorithm (Reliability) Users often leave dust in contracts or revoke wallet allowances, breaking standard liquidators. My bot implements a "Dynamic Balance Sheet" logic. It simultaneously reads the user's wallet allowance and their deposited balance inside the contract (userDeposits). It sums them up (total = wallet + deposit) and bridges the entire amount in one atomic transaction, ensuring zero funds are left behind.

3. Atomic Failure & Revert (Safety) Cross-chain bridges often fail silently or leave tokens stuck in the source contract if a swap slips. I forced atomicity by checking the success boolean of the low-level lifiDiamond.call(_swapData). If the bridge call fails, I explicitly revert the entire transaction. This guarantees that user funds remain safe in their original location (wallet or contract) rather than getting stuck in limbo, allowing the bot to retry.

4. Optimistic Gasless Heartbeats (Cost Efficiency) To save users from paying gas daily, I implemented a "Proof of Life" state channel using Yellow Network's architecture. Users sign EIP-712 messages off-chain. My Watchtower verifies these instantly but only settles them on-chain (pingFor) once every 24 hours. I effectively compressed infinite user interactions into a single daily transaction per active user.

5. In Memory "Spam Lock" (Optimization) I noticed that if a user panic-clicks the heartbeat button, it could trigger multiple pending transactions, wasting gas. I built a custom in-memory locking mechanism (pendingUpdates Set) in my Node.js server. It tracks in-flight transactions by user address and rejects duplicate requests until the previous transaction is confirmed on-chain.

6. Greedy Relayer Prevention (Cross-Chain Security) On the destination chain, a malicious relayer could try to call depositAuthorized without actually bridging funds. I added a logic check in LazarusVault.sol that verifies the contract's actual token balance has increased by _amount before crediting the user. This ensures the vault only updates state if the funds have physically arrived.