Detailed Instructions

Begin by identifying the protocol's core smart contracts on the Layer 2's block explorer. Look for the primary vault, token, and controller contracts. Check the verification status of the source code; unverified code is an immediate red flag. Analyze the proxy pattern used for upgrades. A transparent proxy (like OpenZeppelin's) with clear timelocks is preferred over opaque, centrally-controlled upgrade mechanisms.

• Sub-step 1: Locate the contract addresses on the protocol's official documentation or GitHub.
• Sub-step 2: On the block explorer, verify the contract is marked as 'Verified' and review the source tab.
• Sub-step 3: Check for a TimelockController contract address linked to the admin functions and confirm the delay period (e.g., 48 hours).

solidityCopy
// Example of checking for a proxy implementation address via Etherscan/Blockscout
// Call the `implementation()` function on the proxy contract.

Tip: Use tools like Surya to generate inheritance and function call graphs from the verified source code to understand complexity.

Detailed Instructions

Scrutinize the protocol team's public identity and track record. Anonymous teams require extra diligence. Investigate the funding rounds and backers; reputable venture capital or ecosystem grants add legitimacy. Thoroughly review all public documentation, including the litepaper, technical specs, and fee structures. Incomplete or vague docs are a major warning sign.

• Sub-step 1: Search for team member profiles on LinkedIn and their history in previous, audited projects.
• Sub-step 2: Check funding announcements on Crypto news sites and the investors' portfolios for red flags.
• Sub-step 3: Read the docs end-to-end, testing any provided tutorials or examples for accuracy.
• Sub-step 4: Look for a public bug bounty program on platforms like Immunefi.

Tip: Cross-reference the team's claimed identities with their GitHub commit history and associated email addresses for consistency.

Detailed Instructions

Do not rely on a single audit. Examine all security audit reports from firms like Trail of Bits, OpenZeppelin, or Quantstamp. Check if the audit scope covered the current deployed version and if critical/high findings were fully resolved. Independently verify the audit by checking the auditor's official publication channel. Then, analyze the on-chain history for any unexpected pauses, admin key changes, or large, anomalous withdrawals.

• Sub-step 1: Find audit reports linked from the protocol's official website or security page.
• Sub-step 2: Compare the audited commit hash in the report to the verified contract's creation block code.
• Sub-step 3: Use the block explorer to filter the protocol's contracts for large Transfer or RoleGranted events.

javascriptCopy
// Example Etherscan event filter for a RoleGranted event (OpenZeppelin AccessControl)
// Event topic: 0x2f8788117e7eff1d82e926ec794901d17c78024a50270940304540a733656f0d

Tip: For newer protocols, check if they have undergone a testnet competition or audit contest on Code4rena or Sherlock.

Detailed Instructions

Understand the protocol's revenue model and where the fees flow (to token holders, treasury, LPs). Analyze the token emission schedule and inflation rate; hyper-inflationary rewards are unsustainable. Calculate the Total Value Locked (TVL) relative to the token's fully diluted valuation (FDV); a high FDV/TVL ratio can indicate overvaluation. Scrutinize any governance token distribution for excessive team/VC allocations with short lock-ups.

• Sub-step 1: Model the APY/APR by separating base trading fees from inflationary token emissions.
• Sub-step 2: Use a token unlock schedule tracker (e.g., Token Unlocks) to assess upcoming sell pressure.
• Sub-step 3: Check the treasury address to see if it holds diversified assets or is solely comprised of the native token.

Tip: High, persistent subsidies to liquidity providers often lead to a "farm and dump" cycle that collapses when emissions slow.

Detailed Instructions

A protocol on an L2 inherits the security assumptions of that chain. Identify the data availability layer (e.g., Ethereum calldata, Celestia). Understand the sequencer status; a single, centralized sequencer poses liveness and censorship risks. Examine the canonical bridge used for deposits and the protocol's exposure to it. Some protocols use third-party bridges for asset portability, introducing additional trust assumptions.

• Sub-step 1: Determine if the L2 is a rollup (ZK or Optimistic) and who validates proofs or fraud proofs.
• Sub-step 2: Check the protocol's documentation for any mention of emergency withdrawal procedures that bypass the sequencer.
• Sub-step 3: Verify that the protocol uses the L2's official bridge for its main wrapped assets (e.g., WETH).

solidityCopy
// Example: A contract might include a function for direct L1->L2 messaging via the canonical bridge.
function initiateWithdrawal(address _l1Receiver) external {
    // Calls the L2 bridge precompile or contract
}

Tip: For Optimistic Rollups, note the challenge period (e.g., 7 days), which is the delay for fully trusted withdrawals to L1.

Detailed Instructions

Begin by assessing the bridge's security model. Check its track record for exploits on platforms like DeFi Llama or Chainscore. Verify the source chain's finality and the destination chain's congestion using block explorers like Etherscan or Arbiscan. For the specific asset, confirm it is the canonical bridged version and not a vulnerable, unofficial wrapper.

• Sub-step 1: Query the bridge contract's total value locked (TVL) and audit history.
• Sub-step 2: Check real-time gas prices on the destination chain using a service like GasNow.
• Sub-step 3: Validate the token contract address on the destination chain against the bridge's official documentation.

javascriptCopy
// Example: Checking a token's canonical address on Arbitrum
const canonicalArbUSDC = '0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8';
const userProvidedAddress = '0x...';
if (canonicalArbUSDC.toLowerCase() !== userProvidedAddress.toLowerCase()) {
    console.error('Non-canonical token address detected.');
}

Tip: For large transfers, consider splitting the amount into smaller batches to mitigate slippage and smart contract risk.

Detailed Instructions

Incorrect configuration is a primary cause of lost funds. Set a slippage tolerance appropriate for the asset's liquidity; for stablecoins, 0.1% is often sufficient, while volatile assets may require 1-3%. Always define a transaction deadline (e.g., 20 minutes) to prevent a stale transaction from executing at an unfavorable price. Manually set the destination gas limit if the bridge interface allows it, accounting for potential congestion.

• Sub-step 1: In your wallet (e.g., MetaMask), enable advanced gas controls and set a custom nonce if managing multiple transactions.
• Sub-step 2: On the bridge UI, input the exact recipient address and verify the network ID for the destination chain.
• Sub-step 3: Calculate the minimum expected output using the bridge's quoted rate minus your slippage buffer.

solidityCopy
// Example slippage check in a hypothetical swap function
function swapWithSlippage(uint amountIn, uint minAmountOut) external {
    uint estimatedOut = getQuote(amountIn);
    require(estimatedOut >= minAmountOut, "Slippage too high");
    // ... execute swap
}

Tip: Use a gas estimation API for the destination chain to set a realistic gas limit, adding a 20% buffer for safety.

Detailed Instructions

After signing the transaction on the source chain, immediately copy the transaction hash (txid). Use a cross-chain block explorer like LayerScan or the specific bridge's dashboard to track the asset's journey through its messaging layer. Monitor for two key events: the burn/ lock confirmation on the source chain and the mint/ release initiation on the destination. This period is vulnerable to bridge delay attacks or network halts.

• Sub-step 1: Submit the transaction and confirm it is pending in the source chain's mempool.
• Sub-step 2: Use the bridge's status page with your txid to see the current processing stage (e.g., 'Validating', 'Relaying').
• Sub-step 3: Watch for the corresponding transaction hash generated on the destination chain.

bashCopy
# Example: Using a CLI to monitor transaction status on Ethereum
cast receipt <TXID> --rpc-url https://eth-mainnet.g.alchemy.com/v2/KEY
# Look for `status: 1` for success and `logs` for bridge-specific events.

Tip: For optimistic rollup bridges (e.g., Arbitrum), remember the inherent 7-day challenge period for withdrawals; only use for assets where this delay is acceptable.

Detailed Instructions

Do not assume success upon seeing assets in your wallet. Perform on-chain verification by checking the token's contract for your new balance via a read call. Verify the transaction's finality on the destination chain—for PoS chains, wait for 10+ confirmations. Reconcile the received amount against the initial quote minus fees, ensuring no unexpected bridge tolls or liquidity provider fees were applied.

• Sub-step 1: Query your token balance directly on the destination chain using the contract's balanceOf function.
• Sub-step 2: Check the destination transaction for any internal transfers or fee events in its logs.
• Sub-step 3: Record the final details (txids, amounts, timestamps) in your personal transaction log for accounting and future reference.

javascriptCopy
// Example: Verifying a balance on Polygon using ethers.js
const provider = new ethers.providers.JsonRpcProvider('https://polygon-rpc.com');
const tokenContract = new ethers.Contract(tokenAddress, ['function balanceOf(address) view returns (uint256)'], provider);
const balance = await tokenContract.balanceOf(yourAddress);
console.log(`Verified Balance: ${ethers.utils.formatUnits(balance, 6)}`);

Tip: For maximum security, perform a small test transfer with the same parameters before moving large sums to validate the entire workflow.