Security Frameworks by SEAL

Reviewed by:

Communities might be the key of many Web3 projects, but they also represent a significant security challenge. From casual users to top-level executives, everyone within an organization can be targeted by social engineering tactics across platforms like Telegram, Discord, X (formerly Twitter), Google, and more. When a community channel is compromised—whether by phishing, fraudulent links, or account takeovers—it can quickly become a vehicle for wider attacks, putting both users and organizational reputations at risk.

Here, we present essential best practices to safeguard your community. In the following sections, we will explore platform-specific recommendations in more depth.

Best Practices for Community Security

Strong Passwords and Two-Factor Authentication (2FA)

Use unique, complex passwords for each service and store them securely in a reputable password manager. Refer to the Operational Security Framework and Wallet Security Framework for more information on this.
Secure the email account linked to your community platforms with a unique password and 2FA.
Always enable 2FA. Prefer hardware-based tokens (e.g., Yubikey) or mobile authenticator apps over SMS-based methods, which are vulnerable to SIM-swapping.
If you use an authenticator app like Authy, 1Password, or Aegis to generate time-based one-time passwords (TOTP). Ensure that the secret keys are stored encrypted and protected with robust security measures.
Configure your app to require a password, PIN, or biometric authentication (e.g., fingerprint or face recognition) to unlock access to the tokens. This prevents unauthorized access and ensures the tokens remain secure even if someone gains physical or remote access to your device.
Keep password generation and 2FA codes separate; do not use your password manager to generate 2FA codes. Otherwise, if the password manager is compromised, it could render the 2FA ineffective, allowing unauthorized access to your accounts.
Encourage community members to adopt these practices as well.

Phishing Awareness

Educate members on recognizing and reporting phishing attempts.
Clearly communicate to community members that your team will never send the first direct message to them. This is important because attackers often impersonate team members and initiate direct messages to trick users into believing they are legitimate, thereby gaining their trust and potentially compromising their security.
Publicly define all official communication channels used by your organization.

Refer to the Security Awareness framework to learn more about social engineering techniques and security training best practices.

Operational Security (OpSec)

Be mindful of the devices you use to manage community channels. Malware or compromised hardware can give attackers an entry point.
Regularly update software, run antivirus checks, and avoid installing untrusted applications that may compromise your security.

For a comprehensive understanding of Operational Security, including additional strategies and guidelines, please refer to the dedicated Operational Security framework.

Emergency Response Plan

Prepare a clear protocol for handling security incidents, including how to quickly remove compromised accounts and warn community members.
Adopt a proactive mindset: it's not a matter of if but when a breach will occur. Having a plan in place helps you act decisively and contain damage.

As part of the communication team, it is crucial to know when and how to communicate effectively during an incident. This involves understanding the appropriate timing and messaging to ensure clarity and prevent misinformation. For more insights on where this role fits within an incident, refer to the Incident Management framework.

Discord Security

Community & Marketing

Security Specialist

Authored by:

Reviewed by:

NFTDreww | PocketUniverseZ

Verified by:

🔑 Key Takeaway for Discord: To secure your Discord server, focus on implementing robust access controls and enforcing two-factor authentication for all administrators. Regularly audit roles and permissions, and maintain vigilant moderation. Educate your community about security best practices to prevent unauthorized access and protect against potential threats.

Discord offers a variety of security features that are essential to use. Despite these, users should stay alert to threats like phishing, which can target server moderators. Such threats may appear as QR code scams, fake login screens, or misleading direct messages pretending to be from Discord support.

To enhance the security of your Discord server, take into account these suggestions. They cover important aspects like server settings, roles and permissions, moderation, bots, channels, invites, member screening, logging, and other security measures.

Essential Security Measures

Server Settings

a) Enable 2FA Requirement for Moderation

Go to Server Settings > Safety Setup > Moderation
Toggle on "Require 2FA for moderation"
This ensures all moderators have an extra layer of security

b) Set Appropriate Verification Level

Go to Server Settings > Safety Setup > Verification Level
Choose from: None, Low, Medium, High, Highest
Recommended: "Moderate" for public servers (requires users are registered on discord for longer then 5 min.)
Higher levels protect against spammers and raids

c) Enable Explicit Content Filter

Go to Server Settings > Safety Setup > Content Filter
Set to "Scan messages from all members"
This automatically blocks messages containing explicit images in non-age-restricted channels
Age-restricted channels are exempt from this filter

d) Enable Raid Protection and CAPTCHA

Go to Server Settings > Safety Setup > Raid Protection and Captcha
Activate all relevant settings to require CAPTCHA for new user actions
This protection uses machine learning to detect and block bot-driven join-raids
When activated:
- Sends alerts to a specified channel
- Requires CAPTCHA verification for new users for one hour after detection

Roles and Permissions

a) Implement Role Hierarchy

Go to Server Settings > Roles
Create roles like: Cold Admin, Team, Moderator, & Verified.
Drag to reorder; higher roles override lower roles
Restructure the role hierarchy by dragging roles higher or lower in the roles list:
- Cold Admin
- Team
- Moderator
- Verified

b) Restrict Administrative Permissions

For each role, carefully review the 32 available permissions
Key permissions to restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels
Never give Admin or Kick permissions to anyone you don't fully trust
Good permissions for moderators: Manage Channels, Manage Roles, Manage Messages, Ban Members, Delete Messages
Good permissions for members: View Channels, View audit logs, Create Invite, Manage Messages, Read Message History, Connect, Speak & Use Voice Activity, & Ban/Kick/Timeout

c) Use Channel-Specific Permissions

Right-click on a channel > Edit Channel > Permissions
Set custom permissions for roles or members in specific channels

d) Use the "View Server as Role" Feature

Go to Server Settings > Roles > Select a role > View Server as Role
This allows you to see what members with a certain role can see and access

Advanced Security Measures

Moderation

a) Set Up Auto-Moderation Rules

Go to Server Settings > AutoMod
Set up rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words
Configure custom keyword filters and exempted roles
Customize the response to spam, like blocking the message, sending an alert, or timing out the member
Add to the existing automod rule to block keywords in a users name, and put Support, Bot, Admin, Tech, Helpdesk, etc.

b) Configure Timeout Duration

Go to Server Settings > Safety Setup > Timeout
Set default duration (e.g., 60 minutes)
Educate moderators on using timeouts effectively

c) Establish Clear Server Rules

Create a #rules channel
Use Discord's built-in rules screening feature
Include sections on: Behavior, Content, Moderation Actions, Appeals Process

Extra Moderation Best Practices

a) Leverage "Default Notifications to Mentions Only"

Go to Server Settings > Overview and set Default Notifications to Mentions Only.
Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content.

b) Stay Alert to New Features & Potential Exploits

Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels.
Configure their permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers.

c) Regularly Check Third-Party Bot Security

Ensure bots are from reputable sources and receive frequent updates.
Review bot permissions after each significant update to avoid newly introduced vulnerabilities.

Bots

a) Audit Bot Permissions

Go to Server Settings > Integrations
Review each bot's permissions
Remove unnecessary permissions
Remove permissions for bots that ask for Admin or other permissions that aren't needed, use least privilege with permissions at the role level and channel level.

b) Remove Unnecessary Bots

Uninstall any bots that aren't actively used or needed

c) Implement Security/Moderation Bots

Consider bots like:
- Dyno for advanced moderation and logging
- Carl-bot for reaction roles and custom commands
- Set up security Bots

Security-Specific Bots

Various third-party Discord bots offer valuable security and protection features, facilitating automated moderation for your server. In the sections below, we'll explore different categories of security bots and highlight popular options for each category.

Anti-Impersonation Bots

Set up custom rules to prevent other users from joining using the same username and PFP (profile picture) to impersonate you or other important members of the server. A popular bot in this category is Wick Bot.

Anti-Raid Bots

to prevent spam bots from joining your server all at once, an attack known as raiding, you can also set up bots with particular rules. Beemo is a good example of a bot in this category.

Anti-Nuke Bots

This is a monitoring system to observe and note any changes (spontaneous or planned) that take place in your discord server. Some key observation markers are channel and role creation/deletions, banning or kicking members, and webhook creation/deletion.

Moderation & Link Whitelisting Bots

Only allows approved links to be used in the discord server. A popular bot in this category is Goodknight Bot.

The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in these categories.

Enhanced Server Configuration

Channels

a) Organize Channels Logically

Use categories to group related channels
Suggested categories: Information, General, Voice Channels, Topic-Specific

b) Set Slow Mode Where Needed

Channel Settings > Overview > Slow Mode
Set appropriate cooldown (e.g., 5-30 seconds) for busy channels

c) Use Age-Restricted Channels Appropriately

Channel Settings > Overview > Age-Restricted Channel
Enable for channels with mature content

Invites

a) Disable Permanent Invites

Server Settings > Invites
Un-check "Allow anyone with administrative permissions to create invites"

b) Set Invite Expiration and Usage Limits

When creating an invite: Set "Expire After" and "Max Number of Uses"
Recommended: 24 hours expiration, 50-100 uses

c) Regularly Audit Active Invites

Server Settings > Invites
Review and delete unnecessary or old invites

Member Screening

a) Enable Membership Screening

Server Settings > Safety Setup > Membership Screening
Toggle on "Enable Membership Screening"

b) Set Up Screening Questionnaire

Add questions about server rules, age verification, etc.
Require members to agree to rules before joining

c) Set Up Membership Requirements

Require users to react to a message or post an introduction
This helps filter out bots and spam accounts from joining

Logging

a) Enable Audit Logs

Ensure admin/mod roles have "View Audit Log" permission

b) Set Up a Private Logging Channel

Create a private channel visible only to admins/mods
Use a logging bot like Logger or Dyno to send detailed logs

Best Practices & Administrative Security

Regular Reviews

a) Conduct Periodic Permission Audits

Monthly: Review all role permissions
Use a spreadsheet to track changes and justifications

b) Review and Update Server Rules

Quarterly: Assess if rules need updating
Announce any changes in a dedicated announcements channel

c) Check for Unused Channels/Roles

Bi-annually: Delete or archive inactive channels
Remove roles that are no longer needed

Cold Admin Accounts

a) Set Up a "Cold" Admin Account

Create a new account on a separate device never used for chatting or clicking links
This account is highly resistant to phishing and provides an extra layer of security for the server owner

b) Secure the Cold Account

Create a new email account for the cold account
Factory reset the device used for this account

c) Use the Cold Account for Critical Actions

Manage bots, modify server settings, and respond to compromises
Never use this account for regular server activities

d) Disable QR Code Login on Cold Device

In User Settings > Privacy & Safety, deselect any quick login or QR scan options.
Prevents attackers from using QR phishing tactics to hijack this high-privilege account.

Additional Community Features

a) Enable the Community Feature (Newer Discord Update)

Go to Server Settings > Community to activate the Community Feature.
Unlocks tools like membership screening, server insights, welcome screen, and discovery settings.
Helps maintain a structured, secure environment by surfacing official rules and critical info to newcomers.

b) Review Updated Discord Moderation Resources

Consult the official Discord Moderator Academy for ongoing best practices and new features.
Implement recommended strategies (e.g., improved spam filters, updated role recommendations).

Platform-Specific Security Considerations

Additional Security Measures

a) Verification Systems

Implement a verification bot like Wick
Require users to complete an in-channel captcha before accessing the server
Advance Settings: Have verification bot filter based on account age, PFP set, and timeout for incomplete captcha

b) Raid Protection

Use anti-raid bots like Wick or Dyno
Configure automatic lock-down settings for suspicious activity

c) Privacy Settings

Server Settings > Privacy Settings
Disable "Allow direct messages from server members"

d) Integration Whitelisting

Server Settings > Integrations > Allow new integrations to be added by:
Set to "Only Administrators" to prevent unauthorized bot additions

e) Server Insights

Enable Server Insights for detailed analytics
Use this data to inform moderation strategies and server improvements

f) Backup Systems

Use a bot like ServerBackup to regularly backup your server configuration
Store backups securely off-platform

g) Audit New Integration/Link Safety Settings

Regularly review Server Settings > Integrations for newly added apps or link shorteners.
Disable suspicious integrations or automate link scanning with a bot that checks URLs against known phishing databases.

h) Enable Safe Direct Messaging for All Users

In User Settings > Privacy & Safety, select Keep Me Safe for direct messages.
Encourages moderators and community members to adopt the same setting to minimize phishing DMs.

Additional Resources

X (Twitter) Security

Community & Marketing

Authored by:

Reviewed by:

🔑 Key Takeaway for Twitter (X): To secure your Twitter account, prioritize using an authenticator app or security key over SMS-based 2FA, remove your phone number, and regularly review third-party app permissions. Ensure your recovery settings are robust and frequently monitor account activity to safeguard your online presence and maintain community trust.

A compromised X account can harm not only you but also your community. Attackers often use phishing tactics—like SIM swaps or fake login screens—to seize control of your profile. A few simple steps can significantly reduce these risks.

Securing your Twitter account is not particularly hard or time consuming, so consider following the best practices below.

Essential Security Measures

Remove your phone number

There are no good reasons to keep a phone number attached to your account, and it's the easiest way for a hacker to get into your account after SIM swapping you. Getting verified requires you to add a phone number, but you can remove it afterward.

Go to: Phone Settings
Remove: Click Delete phone number if one is listed.

After removing your phone number, it's crucial to navigate to Settings > Security and Account Access > Security > Two-Factor Authentication > Backup Codes. Store these codes offline, just like your seed phrase. Anyone with these codes can bypass your 2FA, so it's extremely important to write them down and keep them secure. Remember, when you change your password, new backup codes are generated.

Configure 2FA

Two-factor authentication is a great way to keep hackers at bay, but it's not foolproof if you're relying on SMS 2FA and someone gets hold of your phone number. It's generally better to use an authenticator app or a security key. Also, ensure your backup codes are stored safely, ideally printed on paper rather than saved on your device.

Go to: Login Verification
Disable: Un-check Text message
Enable: Choose Authentication app and/or Security key
1. If using an authentication app, store your secret (TOTP) in a reliable app (Authy, Google Authenticator), but disable syncing for added security.
2. If using security keys, keep at least two (e.g., from Yubico) in case one fails.
Under Additional methods, below, select Backup codes and create a new backup code. Store this code securely, offline, ideally in a physical format like a printout, to ensure that if one device is compromised, the code remains safe.

Enable password reset protect

Twitter provides a feature that requires users to input their email or phone number linked to the account before they can initiate a password reset. This adds an extra layer of security by ensuring that hackers must know your email, rather than receiving a hint.

Go to: Security Settings
Toggle On: Check Password reset protect.

Advanced Security Measures

Revoke access from delegated accounts

It's possible to allow other accounts to access your Twitter account. If your account was previously compromised, attackers could exploit this feature to maintain access even after you've regained control.

Go to: Delegate Members
Review: Remove any unfamiliar accounts.

Revoke access from unnecessary apps

It's possible that you've linked your Twitter account to several apps, and some might have more permissions than necessary. To check and manage these permissions, follow these steps:

Go to: Connected Apps
Review: Check each app's permissions and Revoke if it's no longer needed or trusted.

Log Out of Unnecessary Sessions

It's possible you've accessed Twitter from devices you don't regularly use, like a friend's phone. Review your active sessions and log out of any that are unfamiliar or unnecessary.

Old sessions on unfamiliar devices can be risky.

Go to: Sessions
Log Out: For any device or session you don't recognize.

Verify Your Email is Current

If you've changed your email since creating your Twitter account, ensure your current email is linked to receive security alerts and updates.

Go to: Email Settings
Confirm: Update to your current email if needed.

Refresh Your Password

Using a unique password for Twitter is crucial. If you haven't set one, now is the time to do so.

Go to: Password Settings
Change: Select a long, complex password.

Best Practices & Additional Tips

Disable Email and Phone Discoverability
- Go to: Discoverability and Contacts
- It is recommended to turn both email and phone discoverability off.
Privacy & Safety Settings:
- In Privacy & Safety, consider disabling "Allow message requests from everyone" to limit spam DMs and phishing attempts and enabling "Filter low-quality messages".
Monitor for Suspicious Alerts:
- X (Twitter) may notify you about unusual activity. If you suspect a breach, log out of all sessions, revoke suspicious apps, and change your password immediately.
Use Unique Recovery Methods:
- If you choose to use a recovery phone number, which we generally strongly advise against, make sure it isn't your main mobile number. Instead, use a separate VoIP or alternative line to minimize the risk of SIM swapping.
If you received an email about any content moderation, login, or any email from "X"; ensure the email is from "@x.com"

Telegram Security

Community & Marketing

Authored by:

Reviewed by:

🔑 Key Takeaway: Stay vigilant with group chats on Telegram. Implement verification steps and secure communication practices to protect against sophisticated interception attacks.

While Telegram is widely used in the crypto community, it's crucial to understand its security limitations. Telegram does not offer end-to-end encryption (E2EE) by default, which means your messages could potentially be accessed by third parties. Additionally, Telegram's reliance on phone numbers for account creation can expose users to SIM swapping attacks, and its peer-to-peer call feature can reveal your IP address to other users. If E2EE is a priority, consider using Signal.

However, if you choose to use Telegram, the following best practices can help enhance your security.

Essential Security Measures

Configure 2FA

Telegram sign-ups require a phone number, but you can also enable two-factor authentication via a password—your main protection if you're ever SIM-swapped. Don't reuse this password anywhere else.

Go to: Settings > Privacy and Security > Two-Step Verification
Set: A strong password and recovery email (store both in a password manager)

Hide Your Phone Number

Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info.

Go to: Settings > Privacy and Security > Phone Number
Who can see my phone number?: Select Nobody
Who can find me by my number?: Select My contacts

Disable P2P Calling

By default, Telegram calls can connect you directly to the other user, potentially revealing your IP address.

Go to: Settings > Privacy and Security > Calls
Use peer-to-peer with: Select Nobody

Manage Inactive Sessions

Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions.

Go to: Settings > Privacy and Security > Active sessions
Review: Delete any sessions you don't recognize
Auto-terminate: Set inactive sessions to end after 1 month

Implement Device-Level Security

Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages.

Enable Full Device Encryption:
- Ensure your device has full disk encryption enabled
- For iOS: This is enabled by default with a passcode
- For Android: Go to Settings > Security > Encryption and follow instructions
Set Strong Device Passcodes:
- Use alphanumeric passwords rather than simple PINs
- Enable biometric authentication as a secondary measure
Keep Your Device Updated:
- Install OS updates promptly to patch security vulnerabilities
- Update Telegram to the latest version regularly
Install Security Software:
- Use reputable anti-malware software on your device
- Consider privacy-focused apps that detect network anomalies
Secure Your Backups:
- Ensure any device backups containing Telegram data are encrypted
- Be cautious about cloud backups that might store Telegram messages

Advanced Security Measures

Consider Using a Different Phone Number

Even if you implement all the recommended security measures, there are still valid reasons to use a separate phone number. For instance, it can help prevent your contacts from discovering your Telegram account or reduce the risk of accidental number exposure. This is particularly important because the "Share My Phone Number" option is enabled by default whenever you add a new contact.

Using a VoIP Number

Telegram restricts many VoIP providers, but services like Google Voice or Burner might work. Purchase a burner number solely for Telegram if you prefer additional anonymity.

Using an Anonymous Number

In December 2022, Telegram introduced support for anonymous numbers purchased through its TON blockchain infrastructure. You can also check out Fragment for such options.

Turn On Auto-delete Messages

Consider the photo you shared with a friend several months ago. While it might have slipped your mind, an attacker who gains access to your account could find such information quite valuable.

Go to: Settings > Privacy and Security > Auto-Delete Messages
Set: Choose a time frame (e.g., 1 week) based on your risk tolerance

Use Secret Chats for Enhanced Privacy

For conversations that require an extra layer of security, use Telegram's Secret Chats, which offer end-to-end encryption.

Start a Secret Chat: Open the chat with the desired contact, tap on their name, and select Start Secret Chat
Benefits:
- Messages are encrypted and can only be read by you and the recipient
- Offers self-destruct timers for messages
- Prevents forwarding of messages to other chats

Regularly Update the Telegram App

Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features.

Check for Updates: Visit your device's app store regularly
Enable Automatic Updates: If possible, turn on automatic updates to stay current

Be Cautious with Third-Party Bots and Integrations

Third-party bots can enhance functionality but may also introduce vulnerabilities.

Use Trusted Bots: Only add bots from reputable sources
Review Permissions: Limit the permissions you grant to bots
Regular Audits: Periodically review and remove unnecessary bots

Manage Group and Channel Admin Permissions

If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security.

Limit Admin Privileges:
- Go to your group/channel, tap the group name, select Administrators
- Only grant necessary permissions to each admin
- Avoid giving "Add Users" permission to untrusted admins
Implement Admin Verification:
- Establish a verification process before promoting members to admin
- Use separate channels (like voice calls) to confirm admin identities
- Document when admin changes occur and why
Configure Group Settings:
- Restrict member actions such as sending media or links
- Enable "Slow Mode" for large groups to prevent spam
- Use discussion groups for channels to control information flow
Audit Admin Activities:
- Regularly review admin actions in the group
- Remove inactive or suspicious admins
- Consider using admin action logs if available
Handle Admin Transitions Securely:
- Have protocols for transferring ownership if needed
- Revoke admin rights immediately when team members leave

Enhanced Privacy Settings

Passcode Lock

Settings > Privacy and Security > Passcode Lock: This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour."
- Recommendations:
  - Store Passcode Securely: Do not lose this passcode—store it offline if needed.
  - Unique Passcode: Ensure it is different from your phone's unlock passcode.

Privacy and Security Settings

Go to: Settings > Privacy and Security

Security

Two-Step Verification

Overview: Telegram does not require a login by default. However, you can set up a password that acts as a "second" 2FA method when logging in from a new device.
Security Measures:
- SMS Codes: Telegram sends a code via SMS, which is not secure.
- Email Recovery: Offers email recovery, which is more secure but lacks options for authenticator apps or hardware keys.
Important:
- Backup Password: If you lose this password, access to your account may be compromised.
- Secure Storage: Write it down offline and ensure it is not lost.

Additional Privacy Settings

Consider adjusting the following settings based on your country, usage, and purpose for using Telegram:

Phone Number: Set to Nobody to prevent exposure.
Last Seen & Online: Set to Nobody to enhance privacy.
Profile Picture: Set to Everybody to stop scammers from impersonating your profile picture.
Bio: Set to Nobody (depending on use of Telegram).
Date of Birth: Set to Nobody.
Forwarded Messages: Set to Nobody.
Calls: Set to Nobody or Contacts Only (depending on use of Telegram).
Voice Messages: Set to Contacts Only (depending on use of Telegram).
Messages: Set to Everybody or Contacts Only (depending on use of Telegram).
Invites: Set to Contacts Only or Nobody to prevent being added to random groups that may impersonate legitimate groups and lead to scams.

Data Settings

Go to: Settings > Privacy and Security > Data Settings

Sync Contacts: Disable (depending on use of Telegram) to prevent syncing your contacts.
Suggest Frequent Contacts: Disable (depending on use of Telegram) to avoid unsolicited contact suggestions.

Best Practices & Tips for Safe Use

Use Secret Chats: When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions.
Verify Group Invites and Authenticity: Always triple-check group invitations and confirm the legitimacy of group chats through separate channels to avoid joining impostor groups that share malicious links.
Beware of Unsolicited DMs: Never trust direct messages from anyone sending links or posing as "support," "exchanges," or "team" members.
Double-Check Payment Details: Verify payment information through multiple methods before transferring funds to prevent fund redirection.
Block and Report Scammers: Use the block function to prevent further contact, and report spammers/scammers instead of just deleting chats.
Limit Group Permissions: Restrict who can add members to groups to prevent unauthorized cloning and protect against raids.

Educate Community Members on Security Practices

If you're managing a community on Telegram, educating your members about security is vital for collective protection.

Regular Security Announcements:
- Schedule periodic reminders about security best practices
- Pin important security announcements in your group/channel
- Create dedicated security FAQ channels or posts
Clear Verification Procedures:
- Establish and communicate how official communications will occur
- Create verification steps for new members to follow
- Document how to verify the authenticity of admins and official messages
Threat Awareness Training:
- Share examples of common scams targeting your community
- Post screenshots of phishing attempts (with sensitive info redacted)
- Explain the "Man-in-the-Group Attack" and how to avoid it
Incident Reporting Protocol:
- Create clear guidelines for reporting suspicious activity
- Designate security-focused admins to handle reports
- Acknowledge reports publicly (without specifics) to encourage vigilance
Security Resources:
- Develop simple, accessible security guides for members
- Share platform-specific security updates when Telegram releases them
- Create a security checklist for new community members

Exercise Caution with Mini Apps: Avoid logging in or providing information to mini apps that redirect outside of Telegram. Triple-check the username of the mini app to ensure its legitimacy, as Telegram lacks a bot verification system. Never download or run any commands from Telegram on your device.
Enhance Privacy with a VPN: Advanced tip: Set up a proxy or VPN to hide your IP address while using the Telegram app.
Stay Vigilant Against Scam Ads: Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements.

Platform-Specific Risks: Man-in-the-Group Attack

Attackers can exploit Telegram's group chat features to intercept and manipulate communications between two parties. Here's a concise example of how such an attack might occur:

Scenario: Intercepting a Payment Deal

Step 1: Initial Communication

Alice and Bob decide to finalize a cryptocurrency deal using a Telegram group chat named "Crypto Deals".

Step 2: Attackers Create Cloned Groups

Attacker 1 creates Group A impersonating Alice.
Attacker 2 creates Group B impersonating Bob.

Step 3: Replicating Conversations

In Group A (Impersonating Alice):
- The attacker, posing as Alice, relays Alice's messages from Group B to maintain the conversation.
In Group B (Impersonating Bob):
- The attacker, posing as Bob, mirrors Bob's messages from Group A, acting as a middleman without altering the content.

Step 4: Swapping Payment Details

In Group A:
- Fake Alice and Bob agree to the terms of the deal.
- Bob shares his payment address.
In Group B:
- Fake Bob shares his swapped payment address.
- The conversation continues normally, with neither Alice nor Bob aware of the swap.

Step 5: Execution of the Scam

Alice sends the payment to what she believes are Bob's details but are actually those of Fake Bob.
The attacker now controls both ends of the conversation, having successfully redirected the funds.

Google Security

Community & Marketing

Security Specialist

Authored by:

Reviewed by:

🔑 Key Takeaway: Enhance your Google account security by implementing robust 2FA, eliminating redundant recovery options, and diligently overseeing third-party access.

Google provides a wide range of services—from email to file storage. Safeguarding your Google account is among the most critical steps you can take to protect your personal and professional data. Below are simple yet effective measures to improve your Google account security.

Essential Security Measures

This section does not include Google Suite or more advanced security configurations. For that, refer to the Operational Security Framework, under Google Suite Security.

Configure 2FA

Properly setting up two-factor authentication (2FA) is one of the most crucial steps you can take. Disable SMS 2FA to avoid SIM swaps, and instead use an authenticator app or a hardware security key (preferred).

Go to Google 2-Step Verification
Disable: "Voice or text message" if it's enabled
Enable: "Authenticator app" and/or "Passkeys and security keys". You can also can continue using Google prompts.
Store Backup Codes: Keep them offline in a secure place

Remove Recovery Methods

By default, Google allows account recovery using phone numbers and emails. Attackers can exploit these if they compromise your phone or email.

Go to: Google Recovery Phone
Remove: Any phone number listed
Optional: If you're confident you won't need standard recovery processes:
1. Go to: Google Recovery Email
2. Remove: Any recovery email present

Manage Active Sessions

Keeping track of active sessions helps you detect unauthorized access.

Go to: Google Device Activity
Terminate: Any session you don't recognize

Manage OAuth Applications

Some apps request extensive permissions (e.g., full inbox or file access). Regularly review these to minimize risks.

Go to: Google Connections
Review: Each connected app's permissions; remove if unnecessary or excessive

Hide Personal Information

Publicly visible personal info can aid attackers in impersonating you.

Go to: Google Profile
Check Visibility: If any info is set to "Anyone," switch it to private if unnecessary
- Birthday: Consider making it private

Advanced Security Measures

Extended Security Settings

Start from: Google Security.
Go to:"Your connect to third-party apps & Services".
Revoke: all applications that should not be connected.
Go to: "Log out of all unknown devices"
Turn off: "skip password when possible" (below previous step)
Go to: "How you sign in with Google"
Setup: your 2FA or Security Key in this section
Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all.

Once these steps are completed, please change your password. Remember to note down your backup codes.

If using Google Authenticator as a 2FA app on your phone, disconnect it from the cloud, as backup codes are then stored in the google cloud associated to email. Use it without an account and ensure backup codes are written down offline.

Advanced Protection Program

For those who are public figures or need heightened security, Google's Advanced Protection Program is worth considering. It requires the use of security keys, limits access to unverified apps, and makes the process of account recovery more challenging.

Go to Google Advanced Protection Program
Enroll: Follow the on-screen steps

Best Practices & Additional Tips

Review Security Alerts: Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes.
Perform a Security Checkup: Regularly visit Google's Security Checkup to identify potential issues and resolve them.
Consider using identity monitoring apps like Push Security.

Security Awareness

Security Specialist

Operations & Strategy

Community & Marketing

Engineer/Developer

Authored by:

Reviewed by:

Key Takeaway Stay vigilant, your awareness is your strongest defense against cyber threats. Recognizing red flags and questioning unexpected requests can prevent costly breaches.

This framework is all about understanding the threat landscape, recognizing risk signals, and cultivating a security-aware mindset. It serves as a high-level guide to help individuals and organizations identify potential vulnerabilities and remain vigilant—without overlapping with the detailed, technical scenarios covered in other sections.

Introduction & Objectives

The modern digital landscape is filled with sophisticated attacks, including web3-specific threats like crypto drainers and rug pulls. This section lays the foundation for why a high level of security awareness is essential. It's about empowering you to notice, question, and respond appropriately when something feels off. Trust, but verify!

Objectives

Recognize Threats: Understand common tactics used by cybercriminals, including both traditional and web3-specific attack vectors.
Adopt a Proactive Stance: Learn how early recognition can stop an attack in its tracks.
Foster a Security Culture: Build an organizational environment where security is everyone's responsibility.
Implement Effective Training: Develop structured approaches to security education for all team members.
Separate Awareness from Implementation: Focus here on "being aware" rather than the step-by-step controls, which are covered in other sections.

Core Awareness Principles - Foundational security concepts and mindsets that form the basis of security awareness
Understanding Threat Vectors - Comprehensive overview of attack methods, indicators, and preventive measures
Cultivating a Security-Aware Mindset - Behavioral practices and organizational strategies for building a security culture
Staying Informed & Continuous Learning - Training frameworks, educational approaches, and information sources
Resources & Further Reading - External tools, references, and resources for ongoing security education

1. Core Awareness Principles

Security Specialist

Operations & Strategy

Community & Marketing

Engineer/Developer

Authored by:

Reviewed by:

🔑 Key Takeaway: Security awareness is built on fundamental principles like threat recognition, risk assessment, and zero trust verification. These principles form the foundation of a security-conscious culture where every individual plays a vital role in protecting organizational assets.

Key concepts

Threat Recognition: Understand that threats come in various forms—phishing, social engineering, malware, and insider risks. For instance, a social media message urging immediate action might be a scam designed to exploit urgency.
Risk Perception: Assessing risk means evaluating both the likelihood of an attack and the potential impact. For example, if you frequently receive messages from unknown sources on a platform like Twitter, you should view these interactions with increased skepticism.
Zero Trust Mindset: Always verify before trusting. Even messages from familiar contacts should be confirmed if they involve unexpected requests or sensitive information.
Filtering Credible Information: In an era of information overload, it's critical to identify and rely on reputable sources. This means following established security blogs, official alerts from cybersecurity agencies, or verified community channels.
Organizational Responsibility: Security is a shared responsibility that requires commitment at all levels of the organization. Leadership must demonstrate strong commitment by prioritizing and investing in security initiatives, while every team member should understand their role in maintaining security.

Real-World Example: A company might receive a seemingly routine email from a "vendor" requesting updated banking details. An employee with a strong zero trust mindset will independently verify the request through known contact numbers or an established internal process, thereby avoiding a potential fraud.

2. Understanding Threat Vectors

Security Specialist

Operations & Strategy

Community & Marketing

Engineer/Developer

Authored by:

Reviewed by:

🔑 Key Takeaway: Understanding the various ways attackers can target you and your organization is essential for effective defense. By recognizing common attack patterns like phishing, social engineering, and emerging threats in digital spaces, you can better protect yourself and your team from potential security breaches.

2.1. Traditional Attack Vectors

Phishing Emails: Look for red flags like misspellings, odd URLs, and urgent language. Scenario Example: An email that claims "Your account will be locked in 24 hours" but uses a suspicious domain.
SMS & Messaging Scams: Attackers may use text messages or direct social media messages to bypass email filters. Scenario Example: A text message that claims to be from a delivery service asking for a confirmation code.
Voice Phishing (Vishing): Phone calls that pretend to be from a trusted organization, often using spoofed caller IDs. Scenario Example: A staff member receives a voicemail warning about a potential security breach and instructing them to call a specific number immediately.
Pretexting: Attackers create a fabricated scenario to steal personal information or gain access. Scenario Example: Someone pretending to be a new contractor who needs urgent access to systems or information.
Baiting: Offering something enticing to entrap the victim. Scenario Example: Leaving infected USB drives in public places or offering free downloads that contain malware.
Tailgating: Physically following authorized personnel into restricted areas without proper credentials. Scenario Example: An unknown person following an employee through a secure door by claiming they forgot their access card.
Shoulder Surfing: Observing someone's screen, keyboard, or device to gather information. Scenario Example: A threat actor monitoring your screen in a shared co-working space to capture sensitive information or credentials.

2.1.2. Malware & Technical Attacks

Ransomware: Malicious software that encrypts files and demands payment for decryption. Scenario Example: An organization finds their critical files encrypted with a ransom note demanding cryptocurrency payment.
Man-in-the-Middle Attacks: Intercepting communications between two parties. Scenario Example: An attacker on a public Wi-Fi network intercepts unencrypted traffic to steal credentials.
Credential Stuffing: Using stolen username/password combinations to attempt access to multiple services. Scenario Example: After a data breach at one service, attackers try the same credentials on financial or email accounts.

2.2. Web3-Specific Threats

2.2.1. Crypto-Focused Attacks

Crypto Drainers: A common attack where a threat actor suggests users can participate in an airdrop by visiting a provided link. Unsuspecting users who click the link are directed to a counterfeit website, where they are asked to authenticate their wallet and sign a transaction. Once signed, the threat actor gains access to steal funds from the wallet.
Rug Pulls: In the context of web3 and cryptocurrencies, these scams typically involve fraudulent schemes designed to swindle individuals out of their digital assets. For example, an enticing new project may promise revolutionary technology and unprecedented returns. However, the project developers quickly vanish, leaving investors with worthless tokens and empty promises.
Token Approval Exploits: Attackers may trick users into approving smart contracts that give unlimited access to tokens in their wallet. These "allowances" permit the approved contract to transfer any amount of a specific token without further permission. Always verify what permissions you're granting when signing transactions and set specific approval limits when possible.

2.2.2. Smart Contract Vulnerabilities

Reentrancy Attacks: Exploiting a contract's execution flow to repeatedly withdraw funds. Scenario Example: A malicious contract calls back into the victim contract before the first execution is complete, draining funds with each call.
Flash Loan Attacks: Using uncollateralized loans to manipulate market prices and exploit vulnerabilities. Scenario Example: An attacker borrows a large amount of cryptocurrency, manipulates a price oracle, exploits a vulnerability, and repays the loan in a single transaction.

2.3. Common Indicators & Red Flags

2.3.1. Behavioral Cues

Inconsistencies: Look for changes in tone or style in communications from known contacts. Scenario Example: A normally formal manager sends a casual message with unexpected requests.
Unusual Requests: Requests for urgent transfers of money, sensitive information, or changes in process should always trigger caution.
Environmental Anomalies: Spotting unexpected logins or unfamiliar devices in account activity reports can indicate compromised accounts.

2.3.2. Technical Indicators

Unexpected Authentication Prompts: Sudden requests to re-authenticate without clear reason. Scenario Example: Being asked to provide credentials on a site you're already logged into.
Browser Certificate Warnings: Alerts about invalid or expired security certificates. Scenario Example: Your browser displays a warning that a connection is not secure when visiting a familiar website.
Unusual System Behavior: Slowdowns, crashes, or unexpected pop-ups. Scenario Example: Your computer suddenly runs significantly slower or displays unfamiliar advertisements.

2.3.3. Checklist for Suspicious Communications

Does the message contain spelling errors or unusual formatting?
Is the sender's email or username slightly different from the norm?
Are there requests for urgent action without proper verification channels?
Does the message create a sense of fear, urgency, or excitement?
Is there an unexpected attachment or link?
Does the request bypass normal security procedures?

2.4. Preventive Measures

2.4.1. General Security Practices

Double-Check Requests: Always verify the identity of individuals requesting sensitive information, especially if the request is unusual or urgent. Scenario Example: If you receive an email from your CEO asking for an urgent wire transfer, call them directly using a known phone number to confirm.
Use Secure Channels: Communicate through official channels and avoid sharing sensitive information over unsecured methods. Scenario Example: Use your organization's established communication platforms rather than responding to external email links.

2.4.2. Web3-Specific Protections

Check & Remove Token Approvals: Regularly check which smart contracts have approvals to handle funds in your wallet and revoke unnecessary approvals to improve your security posture. Useful Tools:
- Unrekt
- Etherscan Token Approval Checker
Scrutinize Transaction Requests: Never sign a transaction unless you are completely sure exactly what you are signing. Be especially skeptical of offers that seem too good to be true.
Hardware Wallets for Critical Assets: Use hardware wallets for storing significant cryptocurrency holdings. Scenario Example: Keeping your long-term investments on a hardware wallet while only maintaining small amounts in hot wallets for daily transactions.

3. Cultivating a Security-Aware Mindset

Security Specialist

Operations & Strategy

Community & Marketing

Engineer/Developer

Authored by:

Reviewed by:

🔑 Key Takeaway: Developing a security-aware mindset is about building habits that prioritize caution and verification. By questioning unusual requests, pausing before acting, and leveraging peer support, you transform security from a set of rules into an intuitive approach to daily interactions.

3.1. Behavioral Best Practices

Practical Tips

Question Unusual Requests: Always verify any request for sensitive information or financial transactions through a separate communication channel.
Pause Before Reacting: Take a moment to think before clicking a link or downloading an attachment. Example: If you get an unexpected file from a colleague, call them directly to confirm they sent it.
Peer Verification: Leverage your team by asking a colleague's opinion if something seems off.

Scenario Example A community manager receives a direct message on Discord that looks like it comes from a well-known project partner, asking for private credentials. Instead of immediately responding, they cross-check the message in a team meeting or via a known contact method.

3.2 Awareness in Community Settings

Platform-Specific Red Flags: Each community platform—Discord, Twitter, Telegram—has its own quirks. Example: On Telegram, unsolicited group invites with suspicious usernames could be phishing attempts.
Community Role Awareness: Moderators and administrators should be extra cautious since they have higher privileges. Example: A moderator on a crypto project Discord might notice a sudden spike in login attempts from an unfamiliar IP range.
Culture of Reporting: Foster an environment where suspicious behavior is immediately reported and discussed, not brushed aside.

Scenario Example During a routine community chat, several members report receiving odd messages that urge them to click on a link. The community manager organizes a quick session to remind members of red flags and the correct reporting channels, reinforcing collective vigilance.

3.3 Organizational Strategies for Security Culture

Leadership Commitment: Ensure that leadership demonstrates a strong commitment to security by prioritizing and investing in security initiatives. Leaders should model security-conscious behavior and allocate appropriate resources to security efforts.
Regular Communication: Communicate the importance of security regularly through team meetings, newsletters, and other channels. Keep security topics visible and relevant to all team members.
Security Policies and Procedures: Develop and enforce clear security policies and procedures that outline expectations and responsibilities for all team members.
Encourage Reporting: Create an environment where team members feel comfortable reporting security incidents, suspicious activities, and potential vulnerabilities without fear of retribution.
Recognition and Rewards: Recognize and reward team members who demonstrate exemplary security practices and contribute to the organization's security efforts.
Continuous Improvement: Continuously assess and improve the project's security culture through feedback, assessments, and audits.
Shared Responsibility: Instill a sense of responsibility for security at all levels of the project, emphasizing that security is everyone's job.
Collaboration: Promote collaboration and information sharing among team members to enhance overall security awareness and response capabilities.

Scenario Example A project implements a monthly "Security Spotlight" where different aspects of security are highlighted, and team members can share their experiences or ask questions. This regular touchpoint keeps security top-of-mind and encourages ongoing dialogue about best practices.

3.4 Essential Security Practices

3.4.1. Password Management

Strong, Unique Passwords: Use complex, unique passwords for each account to prevent credential stuffing attacks. Example: A passphrase like "correct-horse-battery-staple" (with four random words) is both strong and memorable, while being more secure than shorter passwords with special characters like "P@ssw0rd!".
Password Managers: Utilize a reputable password manager to securely store and generate complex passwords. Example: Tools like Bitwarden, 1Password, or KeePassXC can generate and store unique passwords for all your accounts.

3.4.2. Multi-Factor Authentication (MFA)

Enable MFA Everywhere Possible: Add an extra layer of security beyond just passwords. Example: Even if someone obtains your password, they still can't access your account without the second factor.
Choose Secure MFA Methods: Hardware tokens and authenticator apps are more secure than SMS-based verification. Example: Use YubiKeys or authenticator apps like Authy instead of SMS, which can be vulnerable to SIM swapping attacks.

3.4.3. Secure Communication

End-to-End Encryption: Use messaging platforms with end-to-end encryption for sensitive communications. Example: Signal provides strong encryption for messages, ensuring only the intended recipient can read them.
Verify Communication Channels: Be cautious of unexpected platform changes for important communications. Example: If a colleague suddenly asks to switch from your company's official channel to a personal messaging app for work discussions, verify this request directly.

3.4.4. Device Security

Keep Systems Updated: Regularly update your operating system and applications to patch security vulnerabilities. Example: Schedule automatic updates or set a weekly reminder to check for and install updates.
Secure Your Workspace: Be mindful of physical security in shared or public spaces. Example: Use privacy screens when working in public and lock your device when stepping away.

3.5. Incident Response Awareness

3.5.1. Recognizing Security Incidents

Know the Warning Signs: Understand what constitutes a potential security incident. Example: Unexpected account lockouts, strange system behavior, or unusual access requests could indicate a breach.
Immediate Actions: Know what steps to take when you suspect a security incident. Example: Disconnect from networks, document what happened, and report to your security team immediately.

3.5.2. Reporting Procedures

Clear Reporting Channels: Ensure everyone knows how and where to report security concerns. Example: Have a dedicated email address or communication channel specifically for security reports.
No-Blame Culture: Encourage prompt reporting by focusing on solutions rather than blame. Example: Acknowledge and thank team members who report potential issues, even if they turn out to be false alarms.

Scenario Example A team member notices unusual login attempts to their account. Instead of ignoring it or feeling embarrassed, they immediately report it to the security team, who can then investigate whether this is part of a larger attack pattern affecting other users.

4. Staying Informed & Continuous Learning

Security Specialist

Operations & Strategy

Community & Marketing

Engineer/Developer

Authored by:

Reviewed by:

🔑 Key Takeaway: Security is not a one-time achievement but an ongoing journey of learning and adaptation. By establishing regular training routines, staying current with emerging threats, and fostering a culture of continuous improvement, you ensure your security awareness remains effective against evolving challenges.

4.1. Comprehensive Security Training Framework

4.1.1. Training Approaches

Bite-Sized Learning: Security training doesn't need to be lengthy or overwhelming. Short, focused sessions of relevant information can be more effective than infrequent, lengthy presentations. Example: Weekly 5-minute security tips delivered via team chat or email.
Role-Based Training: Tailor security training to specific roles and access levels within your organization. Example: Developers might need more in-depth training on secure coding practices, while community managers might focus more on social engineering awareness.
Recurring Schedule: Make security training a regular, ongoing activity rather than a one-time event. Example: Monthly security topics with quarterly refreshers on critical subjects.
Practical Application: Include hands-on exercises that allow people to apply what they've learned. Example: Conduct simulated phishing tests followed by immediate feedback and learning opportunities.
Interactive Training Methods: Use interactive training methods, such as SEAL Wargames or workshops to engage team members and enhance learning.
Real-World Scenarios: Incorporate real-world scenarios and case studies to illustrate the impact of security breaches and the importance of preventive measures.
Assessments and Quizzes: Use assessments and quizzes to evaluate the effectiveness of training and identify areas where additional training may be needed.

4.1.2. Training Delivery

Regular Awareness Sessions: Schedule quarterly webinars or short training refreshers focusing on the latest trends and emerging threats.
Interactive Simulations: Participate in phishing simulations or scenario-based exercises that allow you to practice identifying and responding to threats in a risk-free environment.
Security Awareness Campaigns: Implement periodic campaigns that focus on specific security themes to reinforce key messages. Example: A "Phishing Awareness Month" with targeted activities and resources.

4.1.3. Measuring Training Effectiveness

Baseline Assessments: Conduct assessments before and after training to measure improvement.
Behavioral Metrics: Track security-related behaviors such as reporting rates for suspicious emails or incidents.
Feedback Collection: Gather participant feedback to continuously improve training content and delivery methods.

4.2. Essential Training Topics

Phishing and Social Engineering: Educate team members on recognizing and responding to phishing attacks and social engineering tactics, with special focus on web3-specific threats.
Password Management: Provide best practices for creating and managing strong passwords and using password managers.
Data Protection: Teach methods for protecting sensitive data, including encryption, access controls, and secure data handling practices.
Incident Reporting: Instruct team members on how to report security incidents and suspicious activities promptly.
Secure Coding Practices: For developers, provide training on secure coding practices and common vulnerabilities in web3 environments.
Device and Account Security: Cover best practices for securing devices and accounts, including updates, encryption, and access controls.
Emerging Threats: Keep team members informed about new and evolving security threats relevant to your organization.

4.3. Trusted Information Sources

4.3.1. Security Newsletters

Industry News: Subscribe to newsletters from sources such as FIRST.org for broader cybersecurity trends. Example: The SANS NewsBites provides twice-weekly summaries of the most important security news.
Vendor Updates: Follow security updates from the software and hardware vendors in your project stack. Example: Subscribe to security bulletins from cloud providers, operating system vendors, and key software dependencies.

4.3.2. Security Communities

Online Forums and Groups: Join online communities dedicated to security topics. Example: The SEAL Discord provides a space to discuss security challenges specific to web3 projects.
Local and Virtual Meetups: Attend security-focused events to network and learn. Example: Conferences like DeFi Security Summit offer insights into emerging threats and defenses.

4.3.3. Security Blogs and Podcasts

Technical Blogs: Follow security researchers and organizations that regularly publish detailed analyses. Example: Trail of Bits blog provides in-depth technical security content.
Security Podcasts: Listen to podcasts that cover current security topics. Example: The Daily Stormcast from FIRST.org offers brief daily updates, while Darknet Diaries provides longer-form stories about notable security incidents.

4.4. Implementing a Learning Culture

Share Knowledge: Create channels for team members to share security articles, news, and insights. Example: A dedicated Slack channel for security-related content.
Recognize Vigilance: Acknowledge and reward security-conscious behavior. Example: Highlight team members who identify and report potential security issues.
Learn from Incidents: Use security incidents (both internal and external) as learning opportunities. Example: After major industry breaches, conduct brief sessions to discuss what happened and how similar issues could be prevented in your organization.

5. Resources & Further Reading

Security Specialist

Operations & Strategy

Community & Marketing

Engineer/Developer

Authored by:

Reviewed by:

🔑 Key Takeaway: Expanding your security knowledge requires reliable resources and continuous engagement with the security community. By leveraging curated learning materials, self-assessment tools, and professional networks, you can deepen your expertise and stay ahead of emerging threats.

5.1. Additional Learning Materials

Security Awareness Blogs: Subscribe to blogs like "Security Week" or "Dark Reading" for the latest on cyber threat trends.
Self-Assessment Tools: Use downloadable checklists and online quizzes to periodically test your awareness.
Community Forums & Discussion Groups: Engage with professional security communities on platforms such as Reddit's r/cybersecurity or specialized Discord groups.
Case Studies and Whitepapers: Read detailed incident reports and analysis (available from sources like Verizon's Data Breach Investigations Report) to learn from past events.

Example Resources:

Personal security checklist: Digital Defense (we are currently developing a version of this based on frameworks, will be available at https://check.frameworks.securityalliance.dev).
Interactive phishing simulation: Phishing Dojo.
SEAL's blog on frameworks.

5.2. Recommended Security Newsletters

SANS NewsBites - Twice-weekly summaries of the most important security news
FIRST.org - Forum of Incident Response and Security Teams newsletters and resources
The Hacker News - Cybersecurity news and analysis
Krebs on Security - In-depth security news and investigation

5.3. Security Podcasts and Media

Daily Stormcast - Daily 5-10 minute updates from SANS Internet Storm Center
Darknet Diaries - Stories from the dark side of the internet
Security Now - Weekly deep dives into security topics
Risky Business - Weekly information security podcast

5.4. Security Training Resources

OWASP - Open Web Application Security Project resources and guides
Cybrary - Free and premium cybersecurity training
SANS - Professional information security training
Phishing.org - Anti-phishing training and awareness resources

5.5. Web3-Specific Security Resources

DeFi Security Summit - Conference focused on DeFi security
SEAL news & SEAL Discord - Security Alliance's initiatives related to news and events
Immunefi - Educational resources about web3 security
Consensys Diligence - Smart contract security blog
Blockthreat - Web3 security news and analysis
The Red Guild - Web3 security awareness and education

5.6. Web3 Security Tools

Token Approval Management:
- Unrekt - Check and revoke token approvals
- Etherscan Token Approval Checker - Monitor smart contract approvals
Wallet Security:
- wise-signer - Game to learn how to verify transaction information on your wallets
- Qualified Signer Certification - Certification for verifying transaction information
- Software and Hardware Wallets comparison - Compare security features of different crypto wallets
- Hardware Wallets comparison - Compare security features of different hardware wallets
- Wallet Scrutiny - Analyze wallet security and features
- Hardware Wallet Resources - Educational content about hardware wallet security

5.7. Security Tools and Services

Password Managers:
- Bitwarden - Open-source password management
- 1Password - Premium password management solution
- KeePassXC - Free, open-source, cross-platform password manager
Two-Factor Authentication:
- Authy - Multi-device 2FA application
- YubiKey - Hardware authentication device
Secure Communication:
- Signal - End-to-end encrypted messaging
- ProtonMail - Encrypted email service

Wallet Security

Authored by:

Reviewed by:

In cryptocurrency, the security of digital assets is directly tied to how control over the funds is protected. This section provides a technical deep-dive into wallet security, covering the range from fundamental concepts to advanced practices for safeguarding assets against theft, loss, and unauthorized access.

The goal is to move beyond introductory concepts and provide actionable, technical knowledge for securely managing crypto assets.

Custodial vs Non-Custodial - Comparing custodial and non-custodial wallet solutions.
Cold vs Hot Wallet - Understanding the security trade-offs of online and offline wallets.
Wallets For Beginners & Small Balances - Recommended setups for users with non-critical funds.
Wallets For Intermediates & Medium Funds - Security upgrades for users with significant assets.
Multisig Wallets For Advanced Users & High Funds - Best practices for setting up and managing multisig wallets.
Account Abstraction Wallets - Exploring the security features of smart contract wallets.
Signing & Verification - An overview of secure transaction signing and verification.
- Verifying Standard Transactions (EOA) - How to safely verify transactions from standard wallets.
- Multisig Signing Process - Detailed guide for secure multisig transaction signing.
- Using EIP-7702 - Enabling smart contract features for EOAs and mitigating new risks.
Private Key & Seed Phrase Management - Best practices for securing your seed phrase.
Tools & Resources - A curated list of security tools and resources.

In this section you can learn:

Explore wallet fundamentals, analyzing the security trade-offs of hot vs. cold wallets and the ownership implications of custodial vs. non-custodial models.
Receive guidance on choosing the right wallet for your threat model, from basic setups to advanced configurations like Multisignature (Multisig) and Account Abstraction wallets.
Master transaction verification techniques, from basic smart contract interactions to the advanced verification.
Implement security best practices for private key and seed phrase management.

Mastering wallet security is a critical skill for any developer, user, or organization operating in the web3 ecosystem.

security

xkcd

Custodial vs. Non-Custodial Wallets

Engineer/Developer

Security Specialist

Operations & Strategy

Authored by:

Reviewed by:

The distinction between custodial and non-custodial wallets centers on who controls the private keys. This control directly impacts ownership, security responsibility, and the ability to interact with the web3 ecosystem.

Custodial Wallets

What Are They?

Custodial wallets are managed by a third party, such as a centralized exchange (CEX) or a dedicated wallet service provider. In this model, the third party holds and manages the private keys on behalf of the user.

Characteristics

Managed Private Keys: The third party has full control over the private keys. You do not possess them.
Recovery Options: It is often easier to recover account access if login credentials are lost, as the custodian can assist.
Security Dependence: The security of your assets is entirely dependent on the custodian's security practices, infrastructure, and operational integrity.
Ease of Use: Provides a simpler user experience, abstracting away the complexities of private key management.

Use Cases

New Users/Beginners: Suitable for users who are new to cryptocurrency and prefer a simpler, managed solution.
Convenience Over Control: Ideal for users who prioritize convenience and ease of use over full control.

Non-Custodial Wallets

What Are They?

Non-custodial (or self-custody) wallets are managed directly by the user, who has sole and complete control over their private keys. The user is entirely responsible for the security, backup, and management of these keys.

Characteristics

User-Controlled Private Keys: The user has exclusive control and possession of their private keys.
Eliminates Counterparty Risk: Assets are not exposed to the risk of a third-party custodian being hacked, becoming insolvent, or freezing funds. Security becomes dependent on the user's own practices.
Full Responsibility: The user is solely responsible for backing up their seed phrase and securing their private keys. Loss of these keys means irreversible loss of funds.
Web3 Interaction: Enable seamless interaction with dApps.

Use Cases

Experienced Users & Developers: Preferred by users who understand blockchain and wallet security best practices.
Security & Control Prioritization: Ideal for users who prioritize full control over their assets and are willing to undertake the responsibility of self-custody.

Comparison

Feature	Custodial Wallets	Non-Custodial Wallets
Private Key Control	Third Party	User
Recovery Options	Custodian-assisted	User responsibility
Web3 Interaction	Limited	Direct and Full
Primary Risk	Counterparty Risk, Centralization	User Error, Loss of Keys
Use Case	New Users, Trading on CEX, Convenience	Full Control, dApp Use, Long-Term Storage

Cold vs. Hot Wallets

Engineer/Developer

Security Specialist

Operations & Strategy

Authored by:

Reviewed by:

The primary distinction between wallet types is their connectivity to the internet. This factor dictates their security threat model, risk profile, and ideal use cases.

Cold Wallets

What Are They?

Cold wallets are cryptocurrency wallets that store private keys in an offline environment. By being disconnected from the internet, or "air-gapped," by default, they provide the highest level of security against online attacks like malware and phishing.

Transactions are signed offline and then broadcast to the network using a connected device, ensuring the private keys are stored on device with minimal connectivity.

❓ Did you know?

Most cold wallets come with some way to connect to the internet, such as via a USB connection. This technically makes them "hot" when connected. However, the key distinction is that they are not continuously online and are designed to minimize exposure to online threats.

Types of Cold Wallets

Hardware Wallets: Dedicated physical devices that store private keys offline and sign transactions without exposing the keys to a connected internet device.
Paper Wallets: Physical printouts or handwritten notes of private keys and QR codes.
Software Wallets on Air-Gapped Devices: Standard wallet software installed on a device that is permanently disconnected from the internet, used for offline transaction signing.
Brain Wallets: Private keys that are memorized.
Account Abstraction Wallets: Using smart contracts to manage keys and transactions without exposing private keys.
Multisig Wallets: Require multiple signatures to authorize a transaction, enhancing security.

Use Cases

Long-Term Storage: Ideal for storing large amounts of cryptocurrency for extended periods.
High-Security Needs: Essential for individuals securing significant value and operating with a low risk tolerance.

Hot Wallets

What Are They?

Hot wallets are actively and consistently connected to the internet. This connectivity makes them highly convenient for daily use but also inherently more vulnerable to online attacks.

Types of Hot Wallets

Browser Wallets (Extensions): Software that integrates directly into a web browser, allowing seamless interaction with dApps.
Mobile Wallets: Apps installed on smartphones.

Use Cases

Daily Transactions & dApp Interaction: Perfect for users who need quick and frequent access to their funds for interacting with applications.
Small Balances: Suitable for storing smaller, non-critical amounts of cryptocurrency that are used regularly.

Comparison

Feature	Cold Wallets	Hot Wallets
Convenience	Low	High
Use Case	Long-term storage	Daily transactions
Risk	Physical loss/damage	Online attacks, malware

Key Security Considerations

Regardless of the type, non-custodial wallets place the full burden of security on the user:

Online Vulnerabilities: If the device they are on (computer or phone) is compromised, your assets can be stolen.
Supply Chain Attacks: Be cautious of both software and hardware integrity. Always download wallet software from official sources and purchase hardware wallets directly from the manufacturer to avoid receiving a tampered device.

For Beginners & Small Balances

Engineer/Developer

Security Specialist

Authored by:

Reviewed by:

User Profile

A user with foundational web3 knowledge who is actively learning and interacting with dApps. The asset value is typically non-critical, where a potential loss would not be financially significant. This profile prioritizes ease of use and learning over protections against online threats.

Primary Goal

The primary objective is a low-friction setup for convenience and dApp interaction. This includes frequent transactions, exploring DeFi protocols, and engaging with NFTs.

Recommended Setup

The standard setup for this profile is a hot wallet, which provides the necessary internet connectivity for active use. The most common types are:

Browser Extension Wallets: Integrate directly into a web browser for seamless dApp interaction.
Mobile Wallets: Applications installed on a smartphone, offering convenience and on-the-go access.
Desktop Wallets: Software applications installed on a computer, which can sometimes offer more advanced features than mobile or browser counterparts.

Key Considerations & Trade-offs

While convenient, this setup carries inherent risks that the user must understand and accept.

Online Threat Vector: As hot wallets are internet-connected, they are inherently vulnerable to malware and exploits targeting the browser or operating system.
Supply Chain Risk: It is critical to download wallet software only from official, verified sources.

How to Select a Wallet

When selecting a wallet, prioritize those whose code is open-source, as this allows for public scrutiny and independent verification by the security community. For users who are not developers, several platforms provide independent analysis to help evaluate a wallet's security.

For example, Wallet Scrutiny focuses on verifying if a wallet's code is verifiably open-source. Others, like Wallet Security Ranking, provide a security score based on specific criteria such as transaction clarity, protection against known threats, and how it handles dApp permissions.

Using these tools can provide valuable data points to help you assess a wallet's security posture and make an informed decision.

For Intermediates & Medium Balances

Engineer/Developer

Security Specialist

Authored by:

Reviewed by:

User Profile

An intermediate user who is comfortable with web3 interactions and is now managing a significant, but not life-altering, amount of assets. This user understands the inherent risks of hot wallets and is actively seeking to upgrade their security posture to protect their capital.

Primary Goal

The main objective is to secure balances against online threats while still retaining the ability to interact with dApps when necessary. This involves separating the bulk of assets from daily operational balances.

Recommended Setup

A hardware wallet is the core of this setup. This dedicated physical device stores private keys offline in a secure, tamper-resistant environment, acting as a vault for the majority of the user's balances.

Key Considerations & Trade-offs

Adopting a hardware wallet introduces a new set of security considerations focused on physical and supply chain vectors.

Physical Security: A hardware wallet is a physical asset that must be protected from theft, damage, or coercion.
Supply Chain Integrity: Hardware wallets must only be purchased directly from the manufacturer or an authorized reseller to avoid receiving a tampered device.
Convenience vs. Security: Using a hardware wallet introduces friction into the transaction process, as it requires physical access and approval on the device for every signature.

How to Select a Hardware Wallet

Open Source: Evaluate if the wallet's firmware and software are open-source, which allows for public auditing and verification by the security community.
Secure Element (SE) Look for devices with a SE certified, tamper-resistant chip that protects against physical attacks. Check for high assurance ratings like EAL6+ and features like attestation, which verifies the device is genuine.
Reputation & Incident: Investigate the manufacturer's security track record, including their response to past vulnerabilities, data breaches, and overall transparency.
Verify Device Integrity: A legitimate hardware wallet will arrive uninitialized, requiring you to perform the initial setup. Reject any device that comes with a pre-set PIN, a pre-generated recovery phrase, or appears to be already configured, as it is likely compromised.

Multisig Wallets For Advanced Users & High Funds

Security Specialist

Operations & Strategy

Engineer/Developer

Authored by:

engn33r

Reviewed by:

User Profile

Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for managing protocol treasuries, smart contract ownership, or significant personal/collective assets.

Primary Goal

The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value assets and critical smart contract functions.

Core Concept: M-of-N Scheme

A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals M from a total set of authorized signers N to execute a transaction. This is known as an M-of-N scheme (e.g., 2-of-3, 3-of-5).

By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to authorize the movement of funds or execute a privileged action.

Setup Best Practices

Threshold Selection: The M-of-N threshold should be chosen to balance security and operational resilience. Avoid N-of-N schemes, as the loss of a single key would result in a permanent loss of access to all funds.
Strategic Signer Distribution: The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing multiple signer keys on the same device or in the same physical location negates the security benefits. Effective distribution strategies include:
- Using different hardware wallet models and manufacturers.
- Maintaining geographical separation for devices holding signer keys.
- Assigning signer keys to different trusted individuals within an organization.
- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software vulnerability.
Practice on Testnet: Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network.
Timelocks: Enforce a mandatory delay between the approval of a transaction and its execution. This provides a critical window for the community or team to detect and react to malicious proposals.
Role-Based Access Control (RBAC): Implement modules that grant specific, limited permissions to certain addresses (e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
Disaster Recovery Plan: Establish a clear, documented process for what to do when a signer is compromised, the multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.

Operational Best Practices

Signer Key Revocation and Replacement: A feature of multisigs is the ability to add, remove, or replace signer keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate funds.
Secure Signing Environment: For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference.
Independent Transaction Verification: Before signing, always verify the raw transaction data (target address, function call, parameters) to ensure it matches the intended operation.
Out-of-Band Verification for Admin Changes: Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
Active Monitoring: Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like Safe Watcher ).
Documented Procedures: Maintain clear, secure, and accessible documentation for all multisig procedures, including transaction creation, signing, and emergency recovery plans.

Acknowledgements

Some ideas were borrowed from the EF's multisig SOP notes and Manifold Finance multisig best practices.

Account Abstraction Wallets

Engineer/Developer

Security Specialist

Operations & Strategy

Authored by:

Reviewed by:

User Profile

Advanced users, developers, and organizations interested in programmable security, customizable transaction rules, and moving beyond the limitations of standard Externally Owned Accounts (EOAs) to eliminate single points of failure like seed phrase loss.

Primary Goal

To leverage the power of smart contracts at the account level, enabling features like social recovery, gas sponsorship, batch transactions, and flexible security policies that are not possible with an EOA.

Core Concept: ERC-4337

Account Abstraction (AA) turns a user's account into a smart contract, making it programmable. Instead of being controlled directly by a single private key, the account's logic is defined by its code. This is achieved through ERC-4337, a standard that enables AA without requiring changes to the core Ethereum protocol. It introduces a higher-level pseudo-transaction system with several key components:

Smart Contract Account: The user's wallet itself is a smart contract, containing custom logic for validating transactions.
UserOperation: A data structure that bundles the user's intent, calldata, and signature. This object is sent to a dedicated, alternative mempool.
Bundlers: Specialized nodes that package multiple UserOperation objects from the mempool into a single transaction and submit it to the EntryPoint contract.
EntryPoint: A singleton smart contract that acts as the central orchestrator. It verifies and executes the bundled UserOperations, ensuring that accounts and paymasters have sufficient funds to pay for gas.
Paymasters: Optional smart contracts that can sponsor gas fees on behalf of the user, enabling gasless transactions for the end-user or allowing fees to be paid in ERC-20 tokens.

Key Benefits & Features

Enhanced Security:
- Social Recovery: Mitigate the risk of losing a primary key by designating trusted "guardians" (other accounts or devices) who can collectively approve an account recovery.
- Customizable Policies: Implement robust security rules directly into the wallet, such as daily spending limits, whitelisting trusted contracts, or requiring multisig confirmation for transactions over a certain value.
Improved User Experience:
- Gasless Transactions: Enjoy a smoother experience where dApps can sponsor gas fees, or pay for transactions using ERC-20 tokens instead of needing the chain's native asset (e.g., ETH).
- Simplified Interactions: Perform complex, multi-step actions (like approve and swap) in a single, atomic transaction, reducing clicks and potential points of failure.

Security Considerations & Best Practices

Smart Contract Risk: The security of an AA wallet is entirely dependent on the quality and security of its underlying smart contract code. Bugs or vulnerabilities in the account's implementation can lead to a total loss of funds. Thorough audits of the account logic are non-negotiable.
Guardian Selection and Security: The strength of the social recovery model depends on the security and independence of the guardians. They should be diverse and not susceptible to a single common threat.
EntryPoint Centralization: The EntryPoint contract is a central trust point for the entire ERC-4337 ecosystem. A vulnerability in the official EntryPoint could have widespread consequences. Use only the canonical, heavily audited EntryPoint contract.
Paymaster and Factory Security: Malicious or poorly coded Paymasters and Factories can introduce DoS vectors or other risks. The ERC-4337 standard includes a reputation system and staking mechanisms to throttle or ban misbehaving entities, but users should only interact with trusted and audited Paymasters.
Gas Overhead: The added logic in a smart contract account means that transactions can be more expensive than those from a standard EOA. This trade-off between features and cost should be considered, though it can be offset by gas sponsorship.
Key Revocation: If the primary signing key is compromised, the recovery process allows you to swap it out for a new one without having to move all assets to a new wallet address.
Advanced Guardian Setups: For enhanced security, guardian roles can be implemented using Multi-Party Computation (MPC). In an MPC-based recovery, guardians hold cryptographic shares that are used collectively to authorize a recovery action. This method allows guardians to produce a valid signature through a distributed computation using their individual shares, without ever reconstructing a single master key on any device.

Signing & Verification

Engineer/Developer

Security Specialist

Operations & Strategy

Authored by:

Reviewed by:

This section provides a guide to transaction verification, from basic EOA interactions to advanced multisig operations.

The rule is to never sign blindly. Always take the time to verify what your wallet is asking you to approve. A compromised dApp front-end or a misunderstanding of a transaction's parameters can lead to a complete loss of funds, even with a wallet that is not compromised.

Core Principles of Secure Signing

Before diving into specific use cases, it's critical to adopt a security-first mindset built on these foundational principles:

Verify, Don't Trust: Never trust a user interface blindly. The raw transaction data is the ground truth of what you are authorizing. Always use independent tools to confirm that what you see is what you sign.
Simulate Before Signing: Before approving any non-trivial transaction, use a simulation tool. These tools act as a "sandbox," showing you the human-readable outcome before you commit, protecting you from unexpected results and malicious contracts.
The Hardware Wallet is the Source of Truth: Your hardware wallet's trusted display is your last line of defense against UI spoofing. If the information on your computer screen does not perfectly match what is on your hardware device, reject the transaction immediately.
Demand Clear Signing: Prioritize hardware and software that can decode and display a transaction's intent in a human-readable format. If a wallet requires "blind signing" (approving a raw, unreadable hash), you are accepting a significant level of risk.

In This Section

This chapter breaks down transaction verification into key areas:

Standard Transaction Verification: An overview of the foundational security principles that apply to all types of transactions.
Verifying Multisig Transactions: A detailed guide to the two-phase process of securely signing and executing multisig transactions, including how to verify EIP-712 hashes and execTransaction calldata.
Verifying EIP-7702 Transactions: An analysis of the new security considerations introduced by EIP-7702, which allows EOAs to temporarily act as smart contracts, with specific guidance for both users and developers.

To apply these principles, this framework provides a curated list of verification and simulation tools in the Tools & Resources.

Verifying Standard Transactions (EOA)

Engineer/Developer

Security Specialist

Authored by:

Reviewed by:

When interacting with a dApp using a standard Externally Owned Account (EOA) via a wallet, you must verify several key components of the transaction request before signing.

1. Verify the Origin

What to check: The URL of the website initiating the transaction request.
Why it's critical: A malicious site can perfectly clone a legitimate dApp's interface to trick you into signing a malicious transaction. Always ensure you are on the correct, official domain.

2. Verify the Smart Contract Address

What to check: The contract address listed under a field like "Interacting With" in your wallet's transaction prompt.
Why it's critical: This is the actual on-chain address your transaction is being sent to. A malicious dApp will substitute a fraudulent contract address here.
Verification Methods:
- Official Documentation: The most reliable source. Find the "Contract Addresses" or "Deployments" section in the protocol's official documentation and confirm the address matches.
- Block Explorer (Etherscan, Blockscout, etc.): Paste the address into a block explorer. Look for verification checkmarks, official labels, and a healthy transaction history.

3. Verify the Function and Parameters

What to check: The function name (e.g., depositETH) and the parameters in the "Data" tab of your wallet.
Why it's critical: This is the exact action you are authorizing the smart contract to perform. A malicious transaction might look legitimate on the surface but contain a harmful function call.
Verification Methods:
- Cross-reference with Documentation: The protocol's developer documentation will define the function and what each parameter represents.
- Scrutinize Recipient Addresses: For any function that directs assets (e.g., onBehalfOf, recipient, to), ensure the address is your own or the intended recipient.
- Understand Amounts: Verify token amounts, paying attention to the number of decimals.

4. Sanity-Check the Network Fee (Gas)

What to check: The estimated gas fee for the transaction.
Why it's critical: An unusually high gas fee for a simple operation can be a red flag, potentially indicating an inefficient or malicious contract designed to waste user funds.

Verifying Multisig Transactions

Security Specialist

Operations & Strategy

Engineer/Developer

Authored by:

engn33r

Reviewed by:

The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one.

The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction.

Phase 1: Signing the Off-Chain Message

When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the EIP-712 standard.

Goal: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the transaction you intend to approve.

Process

Initiate Signing: Start the signing process in the multisig wallet's web interface.
Verify on Hardware Wallet: Your hardware wallet will display an EIP-712 hash for you to sign.
Independently Compute Hash: Use an independent, local tool like safe-hash to re-calculate the expected hash. The tool will ask for the transaction's parameters (nonce, to, value, data, etc.) to generate the hash locally on your machine.

For less technical users, a web-based tool like Safe Utils can perform this calculation, but a local command-line tool offers superior security against browser-based attacks.
Compare Hashes: Compare the SafeTxHash generated by the local tool with the hash displayed on your hardware wallet's screen. They must match perfectly.
Sign: If the hashes match, you can confidently sign the message on your hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised.

Phase 2: Executing the On-Chain Transaction

Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain transaction that calls the execTransaction function on the multisig contract, passing in all the previously signed data.

Goal: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and other signers approved.

Process

Initiate Execution: In the multisig interface, start the execution of the fully signed transaction.
Verify Calldata: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw transaction data (calldata), which should show a call to the execTransaction function.
Decode and Compare: Use a calldata decoder (e.g.,calldata.swiss-knife.xyz) to parse the data shown on your hardware wallet.
Confirm Parameters: Carefully check the decoded parameters within the execTransaction call, especially the internal destination address (to), value, and data payload. Ensure they match the original, intended transaction.
Sign and Broadcast: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to the network.

Operational Best Practices

⚠️ Beware of DELEGATECALL: In a smart contract multisig transaction, an operation: 1 (DELEGATECALL) is dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control over your wallet's context and storage.

Transaction Simulation: Before signing, use a simulator like Tenderly or Alchemy to preview the transaction's outcome. This helps confirm that it will not revert and will result in the expected state changes.
Hardware Wallet Standard: All multisig signers should use hardware wallets to protect their keys from online threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI.
Alternative Frontends: To further reduce reliance on a single public UI, consider using an alternative or self-hosted multisig interface.

Using EIP-7702

Engineer/Developer

Security Specialist

Authored by:

Reviewed by:

The Pectra network upgrade introduces EIP-7702, which allows a standard Externally Owned Account (EOA) to temporarily function like a smart contract wallet. This is achieved via a new transaction type (0x04) that lets an EOA delegate its authority to a smart contract's code for the duration of a transaction or until it's changed.

Benefits of EIP-7702

This EIP unlocks several key user experience improvements:

Transaction Batching: Users can combine multiple operations (e.g., an ERC-20 approve and a swap) into a single, atomic transaction, saving on gas fees and reducing confirmation fatigue.
Gas Sponsorship: It enables third parties to pay for a user's transaction fees, which can simplify onboarding and abstract away gas management for the user.
Privilege De-escalation: Users can delegate to contracts that enforce specific permissions, such as daily spending limits or interactions with only certain dApps.

Risks of EIP-7702

While powerful, this feature introduces a new attack vector. If an attacker tricks a user into signing a message that sets the wallet's code to a malicious contract, the attacker can gain full control and drain all assets.

Phishing Attacks: The primary threat is phishing sites or scams that trick users into signing a SetCode delegation to a malicious contract under the guise of a wallet "upgrade."
Multi-Chain Replay Attacks: A signature authorizing a delegation with chain ID 0 can be replayed on other EVM chains. An attacker could deploy a malicious contract at the same address on a different chain and use the replayed signature to take control there.

Guidance for Users

Trust Your Wallet's Implementation: Major wallets mitigate phishing risks by hardcoding the only valid delegation contract. This prevents malicious websites from tricking you into delegating to an unsafe contract. Only approve delegations to contracts vetted and integrated by your wallet provider.
Verify Delegation Targets: Only delegate your account to contracts that are well-known and audited.
Understand Revocation: You can revoke a delegation and return your account to a standard EOA by authorizing a new transaction that sets the delegation address to the zero address (0x0000000000000000000000000000000000000000).
Protect Your Private Key: Delegation does not eliminate the fundamental risk of a private key compromise. If your key is stolen, an attacker can still authorize delegations.
Beware of Phishing: Be skeptical of any request to "upgrade" or "enable" smart account features, especially if it comes from an external link or pop-up.

⚠️ Wallets will only prompt you to switch to a smart account within the wallet's native. Any request to do so via email, a website, or a direct message is a phishing scam.

Private Key & Seed Phrase Management

Engineer/Developer

Security Specialist

Operations & Strategy

Authored by:

Reviewed by:

The seed phrase (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all its derived private keys and assets. The management of this phrase is the single most important aspect of self-custody security.

⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must consider it compromised. Immediately create a new, secure wallet and transfer all assets to it.

Secure Storage Practices

The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats (hacking, malware). The foundational principle is to keep your seed phrase offline at all times.

As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have access to your seed phrase and cannot help you recover it.

Physical Written Copies: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a personal safe, a trusted family member's home, a bank deposit box).
Durable Metal Storage: For superior protection against physical damage, etch or stamp your seed phrase onto a metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in secure, separate locations.

Prohibited Practices

Under no circumstances should you ever store your seed phrase in any of the following ways:

Taking a digital photograph of it.
Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
Sending it via text message or any messaging app.
Sending it in an email, even to yourself.
Storing it in a plain text file on a computer or phone.
Sharing it with anyone. Wallet providers will never ask for your seed phrase.
Never use a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace, as it may be tampered with.

Ongoing Security Hygiene

1. Periodic Security Audits

On a recurring basis (e.g., every 6 months), conduct a security review by asking:

Do I know the physical location of all my seed phrase backups?
Are my storage methods still secure and uncompromised?
If my primary device were destroyed, do I have a clear plan to recover my assets?

2. Key Rotation

While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new wallets.

3. Succession Planning

Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death. This may involve sealed instructions stored with a lawyer or in a safe deposit box.

Tools & Resources

Engineer/Developer

Security Specialist

Authored by:

Reviewed by:

This section provides a curated list of tools and resources to help users select wallets, practice safe signing habits, and verify transactions. Using these tools is a critical part of a robust security strategy.

Wallet Selection

Before choosing a wallet, it is essential to consult independent, community-trusted resources.

ethereum.org/wallets: The official, community-maintained list of wallets, filterable by features. A reliable starting point for discovering wallets.
Wallet Scrutiny: An in-depth review site that focuses on transparency, verifiability, and reproducibility. It flags wallets that are closed-source or have other potential security concerns.
Wallet Security Ranking: Evaluates wallets by permissions, intent clarity, device security, and threat prevention to help users choose safer, more trustworthy options.
Wallet Beat: Aims to provide a comprehensive list of wallets, their functionality, practices, and support for certain standards.

Transaction Simulation

Transaction simulators allow you to preview the exact outcome of a transaction before signing it, preventing errors and security risks.

Tenderly: A platform that allows you to simulate transactions and preview, helping to prevent transaction failures, security risks, and unnecessary gas costs.
Alchemy Simulation APIs: An API suite that predicts the precise impact of a transaction before it reaches the blockchain.

Transaction Verification

These tools are designed to help you independently verify the integrity of transaction data, especially for multisig operations.

safe-hash: A command-line tool for locally verifying Safe transaction data and EIP-712 messages before signing. It is designed to protect against phishing by allowing you to independently generate the hash your wallet will ask you to sign.
Safe Utils: A user-friendly web interface for calculating and verifying Safe transaction hashes. While convenient, remember the security advantages of using a local, offline tool like safe-hash for high-value transactions.
calldata.swiss-knife.xyz: Web-based tool for quick decoding of transaction data.
Foundry cast: A powerful command-line tool for local, offline decoding.

Security Training

These tools allow you to practice identifying threats in a safe, simulated environment.

Wise Signer: An interactive platform that challenges users to identify safe and dangerous transactions before signing them. It is an excellent tool for learning to recognize common phishing attacks and deceptive transaction patterns without risking real assets.
Web3 Wallet Security Courses: Offers a structured curriculum for hands-on security training, guiding users from foundational concepts in "Web3 Wallet Security Basics" to advanced techniques. The advanced course covers critical topics like Safe multisig configuration, EIP-712 signature verification, and real-world hack analysis.
How to Multisig: A dedicated resource with best practices on how to implement secure standard operating procedures for multisig wallets.

External Security Reviews

Security Specialist

Operations & Strategy

Devops

Authored by:

An external security review is a time-boxed, security-based assessment of software systems, applications, and infrastructure to enhance security and identify vulnerabilities. External security reviews are essential for organizations to protect against threats and build trust with users and stakeholders.

Why Are External Security Reviews Important?

According to research, significant value and data have been compromised due to security vulnerabilities in software systems. Modern applications face complex threats from malicious actors, and security issues can lead to data breaches, financial losses, and reputation damage.

Beyond preventing security incidents, external security reviews provide several key benefits:

Enhanced Security: Find and fix vulnerabilities before they can be exploited
Team Education: Level up your engineering team's knowledge through security best practices
Trust Building: Demonstrate maturity and safety to users and stakeholders
Risk Mitigation: Identify business logic issues and implementation flaws
Compliance: Meet regulatory and industry security requirements

Scope of External Security Reviews

Security reviews can encompass multiple layers of an organization's technology stack:

Applications: Web applications, mobile apps, APIs, and microservices
Infrastructure: Cloud configurations, network security, access controls, and deployment pipelines
Data Systems: Databases, data processing pipelines, and storage security
Third-party Integrations: External APIs, libraries, and vendor services
Documentation: Technical specifications, security policies, and incident response procedures

External security reviews are not foolproof and cannot guarantee absolute security. They represent an ongoing commitment to safety rather than a one-time event.

There are many different kinds of external security reviews, and we have some context on many of them here.

Smart Contract Security Reviews

Security Specialist

Operations & Strategy

Devops

Authored by:

Smart contract security reviews are specialized assessments focused on identifying vulnerabilities in blockchain-based smart contracts and protocols. These reviews are critical for web3 projects due to the immutable nature of blockchain deployments and the high-value targets that smart contracts often represent.

Why Smart Contract Security Reviews Are Critical

Smart contracts operate in a unique environment that makes security paramount:

Immutability: Once deployed, smart contracts cannot be easily changed
Financial Risk: Smart contracts often handle significant value in cryptocurrencies
Public Accessibility: All code and transactions are visible on the blockchain
Adversarial Environment: Attackers are incentivized by potential financial gains
Complex Interactions: DeFi protocols involve intricate interactions between multiple contracts

According to industry data, billions of dollars have been lost due to smart contract vulnerabilities, making security reviews essential for protecting user funds and maintaining protocol integrity.

Smart Contract Security Review Process

A security review engagement is typically divided into four phases:

Scoping Phase: The project team prepares the codebase and defines specific scope for security researchers
Initial Assessment Phase: Researchers conduct preliminary analysis to identify potential security issues
Mitigation Phase: The team works on fixing identified issues with ongoing auditor support
Final Report Phase: Auditors review implemented fixes and provide a comprehensive final report

Audit Methodologies

Static Analysis: Automated code scanning for known vulnerability patterns
Dynamic Analysis: Runtime testing and fuzzing
Manual Review: Expert analysis of business logic and complex vulnerabilities
Formal Verification: Mathematical proofs of contract correctness (where applicable)

Types of Smart Contract Audits

Private Audits

Dedicated security researchers assigned to your project
Confidential and personalized attention
Higher cost but comprehensive coverage
Direct communication with audit team

Public/Competitive Audits

Multiple researchers competing for prizes
Diverse perspectives and approaches
More cost-effective option
Broader coverage through competition

This section contains detailed guidance on different aspects of smart contract security reviews:

Audit Expectations - What to expect during the audit process
Preparation Guide - How to prepare for a successful audit
Vendor Selection - Choosing the right security auditor

Expectations

Security Specialist

Operations & Strategy

Authored by:

Scoping Phase

The team looking for a security review will agree with the auditors/security researchers the exact parameters of the review. What exact contracts should they review? What should they not review? This is incredibly important so the can clearly estimate timelines on how long a review may take. This is also where compensation is discussed, usually the more aspects a team wants to review, the more expensive the audit will be.

Initial Assessment Phase

Automated Testing: Auditors will run various automated security tools including static analysis, fuzz testing, formal verification, and unit testing to identify basic vulnerabilities
Manual Code Review: Security researchers will manually analyze the code to understand context, complexity, and identify deeper vulnerabilities that automated tools might miss
Documentation Review: Auditors will review project specifications and documentation to understand intended functionality

Deliverables

A comprehensive security review will generate the following:

Initial Report

Vulnerability Identification: Security vulnerabilities classified by severity (High, Medium, Low)
Proof of Concept: Demonstration of potential exploit scenarios where applicable
Gas Optimizations: Recommendations for improving contract efficiency
Informational Findings: Code quality improvements and best practice recommendations
Mitigation Strategies: Specific recommendations for addressing each identified issue

Mitigation Phase

Fix Review Period: Time allocated for your team to address identified vulnerabilities
Collaborative Support: Ongoing communication with auditors during the fix implementation
Code Re-review: Assessment of implemented fixes to ensure issues are properly resolved

Final Report

Updated Assessment: Review of all implemented fixes and their effectiveness
Residual Risk Analysis: Documentation of any remaining risks or limitations
Public Publication: In web3, audit reports are commonly published publicly to build community trust

Timeline and Cost Expectations

The following are incredibly rough estimates for timelines/costs based on Solidity smart contract audits from around the industry. Actual timelines and costs will vary significantly based on the complexity of the codebase, the number of contracts, and the specific requirements of the project.

Duration

Small Projects (< 1000 lines): 1-2 weeks
Medium Projects (1000-4000 lines): 2-5 weeks
Large Projects (> 4000 lines): 5+ weeks

Cost Range

Per Week: $1,000 - $60,000 depending on complexity and auditor expertise
Factors Affecting Cost: Codebase size, complexity, timeline requirements, auditor reputation

Important Limitations

No Guarantee: Audits do not guarantee bug-free code or complete security. However, the engagement with the team should still provide value (teaching better security practices, improving code quality, etc.)
Snapshot in Time: Audits assess code at a specific commit hash - any changes create unaudited code
Ongoing Process: Security should be viewed as a continuous journey, not a one-time event
Emergency Preparedness: Even audited protocols should have incident response plans and emergency communication channels

Preparation

Security Specialist

Operations & Strategy

Devops

Authored by:

A common misconception is that when doing a security review, you can just hand off the written code and let reviewers do their work. This approach is inefficient and costly, as auditors will spend time on issues you could have resolved beforehand. Proper preparation maximizes the value of your security review investment and helps auditors focus on complex vulnerabilities rather than basic issues.

How to Get the Most Out of Your Security Review

Set a Goal for the Review

This is the most important step of a security review and often the most overlooked. By setting a scope that is not too large or undefined, you are more likely to have a successful audit. If the project is very large, you may want to focus on the most critical aspects of the project.

Internal Due Diligence

Conduct internal testing before engaging an external security provider. You can do this by creating and running test vectors for your code, and leverage automated tools to identify low-hanging fruit. Here’s a list of free/open-source tools your project could use:

Solidity: slither, mythril, semgrep-smart-contracts
Golang: golangci-lint, go-critic, gosec
Rust: cargo audit, cargo outdated, clippy, cargo geiger, cargo tarpaulin

Write Clear Documentation

Providing comprehensive documentation is essential for auditors to understand your protocol's intended functionality. Since 80% of all bugs are due to business logic issues, auditors need to understand what your protocol should do, not just what the code does.

Documentation should include:

Project Overview: Describe your protocol in plain English—what it does and its components.
Flow Diagrams: Outline all possible interaction paths within your system.
Design Choices: Document design decisions and any known potential issues.
Known Restrictions / Limitations: Document centralization risks and known limitations (e.g., limited TVL, token support).
Dependencies: List all external dependencies.
Access Control / Privileged Roles: Record all roles and their privileges.

Provide a Robust Test Suite

Maintaining a comprehensive test suite that covers significant portions of your codebase allows auditors to focus on finding vulnerabilities rather than understanding basic functionality. Before an audit, ensure you have:

Unit Tests: Test individual functions and components
Integration Tests: Test interactions between different parts of your system
Fuzz Testing: Automated testing with random inputs to find edge cases
High Code Coverage: Aim for substantial coverage of your critical code paths
Formal Verification: If applicable, use formal methods to prove correctness of critical components

Conduct an Initial Code Walkthrough

The first step in a security audit should be a high-level video walkthrough where you:

Explain your codebase architecture and key components
Describe how the code is intended to function
Highlight critical areas that need special attention
Provide context for design decisions and trade-offs
Guide auditors on where to find answers to common questions

This walkthrough helps auditors understand your system quickly and focus their time on security analysis rather than code comprehension.

Vendor Selection

Security Specialist

Operations & Strategy

Authored by:

Choosing the right security vendor is crucial for getting maximum value from your security review. There are numerous security vendors in both the web3 and web2 ecosystems, each with different specializations and approaches.

Types of Security Audits

Understanding the different types of security audits available helps you choose the right approach for your project:

Private Security Audits

Private smart contract security audits are performed by security companies or solo auditors, typically involving one or multiple security researchers specifically chosen by your team or assigned by the security firm.

Characteristics:

Confidential engagement with limited access to code
Dedicated focus from chosen security researchers
Personalized attention and direct communication
Typically higher cost but more thorough coverage

Public/Competitive Security Audits

Public or competitive audits involve tens or hundreds of security researchers competing to find the highest number of issues to win a share of a prize pool.

Characteristics:

Open participation from multiple researchers
Competitive environment drives thorough analysis
Often more cost-effective than private audits, but less personalized
Can identify a broader range of issues through diverse perspectives

Vendor Selection Criteria

1. Track Record and Reputation

Evaluate potential vendors based on their track record, reputation, and experience in your specific technology stack
Look for vendors with a proven history of addressing security challenges similar to your project's needs
Check for published audit reports and client testimonials

2. Domain Expertise

Web3 Focus: For smart contracts, DeFi protocols, or blockchain infrastructure, choose vendors with deep web3 security expertise
Web2 Focus: For traditional infrastructure, APIs, or backend systems, consider vendors with strong web2 security backgrounds
Specialized Knowledge: If building an L2, DEX, or other specialized system, prioritize vendors with relevant experience

3. Technical Capabilities

Ensure the vendor has experience with your specific:
- Programming languages (Solidity, Rust, Go, etc.)
- Blockchain platforms (Ethereum, Polygon, Arbitrum, etc.)
- Protocol types (DeFi, NFTs, DAOs, etc.)
- Architecture patterns (proxy contracts, multisig, etc.)

4. Security Methodology

Tool Usage: Verify they use appropriate automated security tools
Manual Review: Ensure they conduct thorough manual code reviews
Testing Approach: If applicable, look for comprehensive testing methodologies including fuzz testing or formal verification

Due Diligence Process

Request References: Ask for previous client references and audit examples
Evaluate Methodology: Understand their specific audit process and deliverables
Assess Communication: Ensure clear communication channels and responsive support
Review Pricing: Compare costs against scope and expected value
Timeline Alignment: Confirm availability matches your project timeline

Red Flags to Avoid

Vendors who guarantee finding all vulnerabilities
Extremely low pricing without clear scope limitations
Lack of relevant experience in your technology stack
Poor communication or unresponsive during initial discussions
No clear methodology or standardized reporting process

Audit the Auditors

As of today, the best review of the security reviewers that we have is the historical performance of security reviewers. One of the best ways to evaluate this is to review the historical performance of the security team.

If you see codebases that they reviewed were hacked, this doesn't mean that the team is bad. There are two types of security teams out there:

Those who have had codebases they have reviewed hacked
Those who have not reviewed enough codebases

Additionally, comparing sequential audits of the same codebase can be misleading. If auditor A reviews codebase X, and then auditor B reviews the same codebase and finds more bugs, some insight from auditor A could have been used to find those extra bugs. However, if two auditors review the same codebase at the same time, this can be a much better comparison of the two auditors.

Security Policies and Procedures

Security Specialist

Legal & Compliance

Operations & Strategy

Authored by:

As part of the external security review, it could be beneficial to also review the internal security policies and procedures as well. Some of the things that could be relevant to review are:

Ensure there is a developed and maintained plan for responding to security incidents.
Ensure there are defined roles and responsibilities, and enforce the principle of least privilege.
Ensure there are processes implemented for managing changes to the codebase and infrastructure.
Ensure there are regular training sessions conducted for all team members on security best practices.
Ensure adherence to any potentially relevant regulatory and industry standards for your project.

Security Testing

Engineer/Developer

Security Specialist

Operations & Strategy

Devops

SRE

Authored by:

The objective of Security testing, while most likely impossible, is to ensure that applications and systems are resilient to attacks and free from vulnerabilities. This section covers various security testing methodologies, including dynamic and static application security testing, fuzz testing, and security regression testing.

There are several types of testing:

Unit Testing: Tests individual components or functions of the codebase.
Integration Testing: Tests the interaction between different components or systems.
Fuzz Testing: Tests the application by providing random or unexpected inputs to identify vulnerabilities.
Static Analysis: Analyzes the code without executing it to find potential vulnerabilities.
Formal Verification: Uses mathematical methods to prove the correctness of algorithms and protocols.

Some types of testing overlap, for example, a unit test could also be a fuzz test. We will focus on testing and how it applies to smart contracts, and use solidity as an example.

Goal

The goal of security testing is to identify vulnerabilities and weaknesses in the codebase, while also making sure that the code behaves the same way even after changes. Different types of testing can help achieve this goal in different ways. There is no "one size fits all" solution, and the choice of testing methodology depends on the specific requirements and constraints of the project.

Smart Contracts

For smart contracts in particular, here is when to use each type of testing:

Unit Testing: Always. And aim for high "code coverage" (i.e. unit test as many paths as possible)
Integration Testing: Always. This can also be combined with fork testing.
Fuzz Testing: Always. Most unit tests can be fuzz tests.
Static Analysis: Always. Use tools like Slither and Aderyn to analyze the code for vulnerabilities.
Formal Verification: Dependent. Anywhere functions are math heavy, stateless, or functionality matches another system, this should be used.

Dynamic Application Security Testing

Fuzz Testing

Engineer/Developer

Security Specialist

Operations & Strategy

Devops

SRE

Authored by:

Fuzz testing (or fuzzing) is when you supply random data to your system in an attempt to break it. Most of the time, hacks come from scenarios you didn't think about and write a test for. What if I told you that you could write one test that would check for almost every possible scenario?

What is Fuzz Testing?

For example, if a balloon was our system/code, it would involve doing random stuff to the balloon to break it.

Punch it
Squeeze it
Throw it
etc

Why would we want to do all that? Let's look at an example.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract MyContract {
    uint256 public shouldAlwaysBeZero = 0;
    uint256 private hiddenValue = 0;

    function doStuff(uint256 data) public {
        if (data == 2) {
            shouldAlwaysBeZero = 1;
        }
        if (hiddenValue == 7) {
            shouldAlwaysBeZero = 1;
        }
        hiddenValue = data;
    }
}

Let's say we have this function named doStuff, which takes an integer as input. We additionally have a variable named shouldAlwaysBeZero that we want always to be zero.

The fact that this variable should always be zero is known as our invariant, or "property of the system that should always hold."

Invariant: The property of the system that should always hold.

Our invariant in this contract is that: Invariant: shouldAlwaysBeZero MUST always be 0

Why Normal Unit Tests Aren't Enough

Let's look at a normal unit test:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {MyContract} from "../src/MyContract.sol";
import {Test} from "forge-std/Test.sol";

contract MyContractTest is Test {
    MyContract exampleContract;

    function setUp() public {
        exampleContract = new MyContract();
    }

    function testIsAlwaysZeroUnit() public {
        uint256 data = 0;
        exampleContract.doStuff(data);
        assert(exampleContract.shouldAlwaysBeZero() == 0);
    }
}

With this single unit test testIsAlwaysZeroUnit, we might think our code has enough coverage, but if we look at the doStuff function again, we can see that if our input is 2, our variable will not be zero.

function doStuff(uint256 data) public {
    // WHAT IS THIS IF STATEMENT???
    // 👇👇👇👇👇👇
    if (data == 2) {
        shouldAlwaysBeZero = 1;
    }
    // 👆👆👆👆👆👆

    // Ignore this one for now
    if (hiddenValue == 7) {
        shouldAlwaysBeZero = 1;
    }
    hiddenValue = data;
}

This seems obvious with our example function, but more often than not, you'll have a function that's much more complex with numerous edge cases that are impossible to manually test.

Stateless Fuzz Tests

In Foundry, you'd write a fuzz test like so:

function testIsAlwaysZeroFuzz(uint256 randomData) public {
    exampleContract.doStuff(randomData);
    assert(exampleContract.shouldAlwaysBeZero() == 0);
}

Foundry will automatically input semi-random values to randomData and over many runs, input them to the doStuff function and check that the assertion holds.

This would be equivalent to writing many tests where randomData had different values, all in one test!

Now I say "semi-random" because the way your fuzzer (in our case, Foundry) picks the random data isn't truly random, and should be somewhat intelligent with the random numbers it picks. Foundry is smart enough to see the if data == 2 conditional, and pick 2 as an input.

If we run our fuzz test, it tells us exactly what input fails our test:

$ forge test -m testIsAlwaysZeroFuzz

Failing tests:
Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest
[FAIL. Reason: Assertion violated Counterexample: calldata=0x47fb53d00000000000000000000000000000000000000000000000000000000000000002, args=[2]] testIsAlwaysZeroFuzz(uint256) (runs: 6, μ: 27070, ~: 30387)

We can see that it found out if it passed args=[2] to the test, it was able to break our assert(exampleContract.shouldAlwaysBeZero() == 0). So now, we can go back into our code, and realize we need to fix the edge case where data == 2, and now we are safe from the exploit!

Stateful vs Stateless Fuzzing

The Hidden Bug

Now you may notice that there is another scenario where our code could have an issue, and that's when hiddenValue == 7. In order for this revert to happen, you have to:

First call doStuff with the value 7 (which sets hiddenValue to 7)
Then call this function again with any other number

It takes 2 calls for our invariant to be broken:

Call doStuff with 7
Call doStuff with any other number

Our fuzz test written above will never be able to find this example because as it's currently written, our test is what's known as a "stateless fuzz test."

Stateless Fuzzing: Fuzzing where the state of a previous run is discarded for the next run.

Stateful Fuzz Tests (Invariant Tests)

So, in smart contract testing, we can do "stateful fuzzing" instead.

Stateful Fuzzing: The state of our previous fuzz run is the starting state of our next fuzz run.

To write a stateful fuzz test in Foundry, you'd use the invariant keyword, and it requires a little more setup:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {MyContract} from "../src/MyContract.sol";
import {Test} from "forge-std/Test.sol";
import {StdInvariant} from "forge-std/StdInvariant.sol";

contract MyContractTest is StdInvariant, Test {
    MyContract exampleContract;

    function setUp() public {
        exampleContract = new MyContract();
        targetContract(address(exampleContract));
    }

    function invariant_testAlwaysReturnsZero() public {
        assert(exampleContract.shouldAlwaysBeZero() == 0);
    }
}

Instead of just passing random data to function calls, a stateful fuzz test (invariant test) will automatically call random functions with random data.

We use the targetContract function to tell Foundry that it can use any of the functions in exampleContract. There is just one function for this example, so it will just call doStuff with different values across multiple calls.

If we run this test, we can see it finds out that if you call doStuff twice (once with the value 7), it will break our invariant!

$ forge test -m invariant_testAlwaysReturnsZero

Failing tests:
Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest
[FAIL. Reason: Assertion violated]
        [Sequence]
                sender=0x000000000000000000000000000000000000018f addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[7]
                sender=0x0000000008ba49893f3f5ba10c99ef3a4209b646 addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[2390]

Perfect! It shows us the exact sequence of calls that broke our invariant.

Real-World Smart Contract Invariants

In an actual smart contract, your invariants won't be that a balloon shouldn't pop or some function should always be zero; they'll be something like:

New tokens minted < inflation rate
There should only be 1 winner of a random lottery
Someone shouldn't be able to take more money out of the protocol than they put in
The protocol must always be over-collateralized
Total supply should equal sum of all balances

Fuzz Testing Tools

Best Practices

Start with Unit Tests: Build your foundation with comprehensive unit tests first
Identify Invariants: Clearly define what properties must always hold
Use Stateful Fuzzing: Most real bugs require multiple function calls to trigger
Bound Your Inputs: Use realistic parameter ranges in handlers
Document Invariants: Make your invariants clear in comments and documentation

References

Much of this document was inspired by the Cyfrin Updraft fuzzing curriculum.

Security Regression Testing

Static Application Security Testing

ENS Best Practices

Engineer/Developer

Security Specialist

Authored by:

🔑 Key Takeaway: To securely implement ENS in your applications, prioritize direct L1 data verification, enforce proper name normalization, and validate bidirectional resolution. Always verify interface support before interaction, respect chain-specific cointype parameters, and implement CCIP-Read functionality correctly. These practices prevent address spoofing, ensure cross-chain compatibility, and maintain data integrity throughout the ENS ecosystem.

The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain.

ENS maps human-readable names like 'alice.eth' to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, metadata, and more. ENS also supports 'reverse resolution', making it possible to associate metadata such as primary names or interface descriptions with Ethereum addresses.

What This Framework Covers

This best practices framework includes guidance on:

Data Integrity & Verification - Ensuring reliable and secure name resolution
Cross-Chain Compatibility - Supporting ENS across multiple blockchain networks
Smart Contract Integration - Leveraging ENS in smart contract systems
Interface Compliance - Correctly implementing and verifying ENS interfaces
Name Handling & Normalization - Properly processing and displaying ENS names

These recommendations are designed for developers integrating ENS into applications, wallets, smart contracts, or other blockchain systems. Following these practices will help create more secure, reliable, and user-friendly ENS implementations.

Data Integrity & Verification

Engineer/Developer

Security Specialist

Authored by:

Use On-chain Resolution for Financial Transactions

Always resolve fresh data directly from Ethereum mainnet whenever conducting financial transactions
Do not rely on indexer or API data when moving or managing funds
Preferably run an Ethereum node for high-value transactions, or if not feasible, use reputable L1 RPC providers while still verifying the integrity and audit status of all software involved in the resolution process

Rationale: Indexers and third-party APIs may have delayed updates or inconsistencies that could lead to payments being sent to outdated or incorrect addresses. By querying L1 directly, applications work with the most current and authoritative ENS data, dramatically reducing the risk of misdirected funds. This is particularly crucial for high-value transactions where the consequences of using stale data could be severe.

Verify Forward Resolution on Reverse Records

Always perform forward resolution on reverse records to verify address matches
Check that name → address → name completes a valid loop
Clearly indicate to users when there's a mismatch

Rationale: ENS supports both forward resolution (name → address) and reverse resolution (address → name). However, reverse records can be set independently, creating the possibility for spoofing or impersonation if not properly verified. By performing forward resolution on the result of a reverse lookup and comparing it to the original address, applications can ensure the bidirectional integrity of the ENS data, preventing potential phishing or impersonation attacks.

Cross-Chain Compatibility

Engineer/Developer

Security Specialist

Authored by:

Respect Cointype for Chain-Specific Resolution

Always use the correct cointype parameter when resolving addresses on specific chains
For EVM-compatible chains, derive cointypes from chain IDs according to ENSIP-11

Rationale: An ENS name can resolve to a different address for each different blockchain network, which ENS supports through the cointype field in address records (following SLIP-44 standards). With the rise of smart contract wallets and account abstraction, users may have different addresses across different chains. Failing to respect the cointype when resolving addresses can lead to funds being sent to addresses that don't exist on the target chain or that belong to different entities altogether.

Implement CCIP-Read Support

Properly support and handle CCIP-Read functionality EIP-3668
Set reasonable timeouts and fallbacks for CCIP-Read operations

Rationale: CCIP-Read (EIP-3668) enables off-chain data retrieval for ENS resolution, allowing for more complex resolution patterns and greater flexibility for name owners. This protocol allows resolvers to redirect resolution requests to off-chain services that can implement custom logic beyond what's practical on-chain. Applications that ignore CCIP-Read requests limit the functionality available to ENS users and may provide incorrect resolution results. Supporting this standard ensures compatibility with advanced ENS use cases.

Test Multi-Chain Implementations

Test ENS resolution across all chains your application supports
Implement proper error handling for unsupported chains
Document which chains are supported by your implementation

Rationale: As blockchain ecosystems expand, users expect applications to work across multiple networks. Testing ENS resolution across different chains ensures consistent behavior regardless of which network a user is connected to. Clear documentation about chain support also helps users understand the limitations of your application.

Smart Contract Integration

Engineer/Developer

Security Specialist

Authored by:

Name Your Smart Contracts

Register ENS names for core contracts in your project's ecosystem
Set appropriate reverse records for your contracts
Document contract ENS names in project documentation
Consider naming contracts at deployment time to ensure immediate resolvability
Use a standard pattern for contract naming to improve discoverability

Rationale: Smart contracts typically have complex hexadecimal addresses that are error-prone when shared or referenced. By assigning ENS names to smart contracts, developers can significantly improve user experience, make documentation more approachable, and reduce the risk of address errors. This practice is especially important for contracts that interact directly with users or serve as key infrastructure components. Human-readable names also aid in contract verification, as users can more easily confirm they're interacting with official protocol contracts rather than potential phishing imitations.

Leverage ENS as an Infrastructure Component

Use ENS for service discovery between contract components
Build upgradeability mechanisms that leverage ENS for implementation pointers
Consider ENS as a registry for official protocol extensions and integrations
Use ENS records to store protocol metadata in a human-readable format

Rationale: ENS can serve as more than just a human-readable address layer, it can function as critical infrastructure for contract systems. Using ENS for implementation pointers enables flexible and upgradeable architectures, as contract dependencies can be redirected without requiring contract redeployment. This pattern supports robust governance models while maintaining a consistent user interface. Additionally, using ENS to register official extensions creates a trust layer that helps users identify legitimate protocol integrations, while storing protocol metadata in ENS records improves discoverability and system documentation.

Interface Compliance

Engineer/Developer

Security Specialist

Authored by:

Verify Resolver Interface Support

Always check if a resolver supports your target interface using EIP-165
Call supportsInterface() before attempting to use specific resolver methods
Implement graceful fallbacks when interfaces aren't supported
Cache interface support results to minimize redundant on-chain calls

Rationale: ENS resolvers can implement various interfaces, each providing different functionality (addresses, text records, content hashes, etc.). Not all resolvers implement all interfaces, so checking interface support before calling specific methods prevents failed transactions and improves reliability. This verification step is especially important as the ENS ecosystem evolves and new resolver interfaces are introduced. Without proper interface verification, applications may fail when encountering resolvers with limited functionality or custom implementations.

Signal Supported Interfaces in Custom Resolvers

When writing custom resolvers, properly implement EIP-165
Signal all supported interfaces via supportsInterface()
Document which interfaces your resolver supports
Consider incremental implementation of interfaces based on user needs

Rationale: Implementing EIP-165 interface detection allows other contracts and applications to programmatically discover what functionality your resolver supports. This promotes interoperability and ensures your custom resolver can seamlessly integrate with the broader ENS ecosystem. Proper interface signaling is not just a technical requirement but a key element of good blockchain protocol citizenship. Without it, other contracts and applications can't reliably determine the capabilities your resolver offers, leading to poor user experiences and potential security risks.

Stay Updated with ENS Improvement Proposals (ENSIPs)

Regularly monitor the ENS GitHub repository for new ENSIPs
Participate in ENSIP discussions to provide implementer feedback
Implement support for new ENSIPs after they reach "Final" status
Plan for deprecation of older interfaces as specified by ENSIPs
Test implementations against the reference implementations provided in ENSIPs

Rationale: The ENS protocol evolves through the ENSIP process, which introduces new interfaces, standards, and recommended practices. Staying current with these proposals ensures your implementation remains compatible with the broader ecosystem and can leverage new functionality as it becomes available. ENSIPs often address security vulnerabilities, improve user experience, or add valuable new features that users will come to expect. Implementers who track and promptly adopt new ENSIPs gain competitive advantages while contributing to the overall health and advancement of the ENS ecosystem.

Name Handling & Normalization

Engineer/Developer

Security Specialist

Authored by:

Normalize Names per ENSIP-15

Always normalize ENS names before creating namehash, labelhash, or DNS-encoding
Use established libraries that correctly implement ENSIP-15 normalization (like @adraffy/ens-normalize)
Apply normalization at the earliest possible point in your ENS handling logic
Include normalization checks in validation procedures for user-entered names

Rationale: ENS uses a specific normalization algorithm defined in ENSIP-15 to ensure consistent handling of Unicode characters and emoji sequences. Failing to normalize names correctly can result in different hash values for what users perceive as the same name, leading to resolution failures, security vulnerabilities, and poor user experience. Proper normalization is fundamental to the correct operation of any ENS integration and must be performed before any cryptographic operations (namehash, labelhash) or encoding. Using established libraries ensures compliance with the complex requirements of ENSIP-15.

Implement Security Measures for Homograph Attacks

Detect and warn users about visually confusable characters in ENS names
Display names using fonts that clearly differentiate similar-looking characters
Consider displaying the script/language of characters in multi-script names
Implement visual indicators for mixed-script names or potentially deceptive names
When displaying ENS names, highlight or annotate unexpected character sets

Rationale: Homograph attacks use visually similar characters from different Unicode scripts to create deceptive names (e.g., using Cyrillic 'о' instead of Latin 'o'). While ENSIP-15 addresses some confusables, it cannot eliminate all visual ambiguities. Implementing additional security measures helps users identify potentially deceptive names before interacting with them. These protections are particularly important in financial applications or any context where users might send assets to an ENS name, as homograph attacks can lead to irreversible asset loss.

Properly Handle Emoji in ENS Names

Ensure your UI correctly displays emoji in ENS names at appropriate sizes
Be aware that emoji rendering varies across platforms and fonts
Handle emoji sequences correctly, including skin tone modifiers and ZWJ sequences
Test thoroughly with emoji-containing names on multiple platforms and browsers
Use libraries that correctly implement UTS-51 (Unicode Emoji) for handling emoji

Rationale: Emoji are increasingly common in ENS names but introduce technical challenges. Emoji can be composed of multiple code points, including zero-width joiners (ZWJ) and variation selectors, making proper handling critical. Incorrect emoji implementation can cause names to appear differently across platforms or fail to resolve correctly. Emoji rendering also varies significantly between operating systems and browsers, requiring thorough cross-platform testing to ensure consistent user experience.

SEAL Whitehat Safe Harbor

SEAL/Initiative

Protocol

DAO

Whitehat

Authored by:

→ Apply for the SEAL Onboarding Waitlist

💡 An industry-standard framework, letting your protocol pre-authorize whitehats to rescue funds during active exploits

What is Safe Harbor?

When your protocol is under attack, every second counts. Safe Harbor gives you a way to fight back.

Safe Harbor is a legal and technical framework that lets your protocol pre-authorize whitehats to step in during active exploits, rescue funds, and return them - fast, safely, and with clear legal protection for everyone involved.

By adopting Safe Harbor, protocols allow:

Empower whitehats to act immediately during an exploit
Remove legal ambiguity and delays
Boost the odds of recovering user funds

Why we started Safe Harbor

💡 We started Safe Harbor after the Nomad hack, where over $190M was drained over the course of hours while whitehats stood by, willing to help, but unable to act without legal protection. With Safe Harbor, our goal is to make sure that never happens again and to empower whitehats to rescue funds.

Vetted by industry leaders and top Web3 lawyers:

Safe Harbor was developed over two years with direct input and rigorous legal review from experts at a16z Crypto, Cooley, Debevoise & Plimpton, Filecoin Foundation, MetaLeX, Paradigm, Piper Alderman, Powerhouse, and more.

Who’s Adopted Safe Harbor:

Safe Harbor is already protecting $16B+ in assets across leading DeFi protocols. Current adopters include Uniswap, Pendle, PancakeSwap, Balancer, Silo Finance, Zksync, and more. See the full up-to-date list.


Gov Proposal	Non-DAO Adoption	Gov Proposal	Gov Proposal

How Does Safe Harbor Work?

Protocols pre-authorize rescues: You clearly define when and how whitehats are allowed to step in - covering what assets are protected, where to return funds, and what bounty terms apply, etc
Whitehats act only during active exploits: Safe Harbor only applies when an exploit is already in progress or imminent - e.g., in the mempool, or after initial funds have been drained. It’s not for bug bounty reports, and it does not protect blackhats. Only whitehats who rescue funds without initiating the exploit are covered.
Funds are returned, bounty is automatic: Whitehats must send rescued funds to your official recovery addresses within 72 hours. Bounties are enforceable and pre-defined - no negotiation, no chaos.

Other key protections:

You can choose to allow anonymous whitehats or require KYC.
Whitehats must follow established guidelines for responsible intervention
You define exactly which contracts, and chains are protected.
The agreement is only valid if funds are returned and the protocol’s rules are followed

How to adopt?

Adopting Safe Harbor is fast, simple, and works whether you're a DAO or a centralized team. You can complete the whole process in under an hour.

Here are a few options:

1. Get Help from SEAL

For protocols that want white-glove support, SEAL offers guided onboarding at no cost. We’ll walk you through scoping, governance language, on-chain registration, etc.

Space is limited - we prioritize high-impact protocols and critical infrastructure

2. Self-Adopt Using Our Guide

For teams that want to do it themselves, we provide a clear step-by-step guide, including templates for scope definitions, template DAO proposals, and on-chain registration instructions.

→ View the Self-Adoption Guide

3. Adopt Through a Third-Party Provider

Safe Harbor is also supported by select ecosystem partners who offer adoption workflows as part of their existing services.

→ Adopt via Immunefi

Safe Harbor doesn’t require a legal entity, legal counsel, or new infrastructure. Just define your terms, publish your scope, and your protocol is protected.

Whether you're a DAO or not, adopting Safe Harbor is a low-lift way to enable real-time defense and recover funds during live exploits.

Whitehats Work

💡 SEAL911 and the broader whitehat community have already helped protocols recover over $150M from live attacks - proving that fast, responsible intervention is possible.

FAQ

What counts as an active exploit?

An active exploit is one that’s already in progress or imminent - for example, a malicious transaction sitting in the mempool or a vulnerability that's already being exploited. Safe Harbor only applies when immediate action is required to prevent or stop fund loss. It does not apply to situations where there is no imminent threat and where responsible disclosure can prevent fund loss.

How is it different than a Bug Bounty?

Bug bounties reward whitehats for responsibly disclosing vulnerabilities before they’re exploited. Safe Harbor kicks in after an exploit is underway - when there’s no time for disclosure, and whitehats need legal cover to intervene and recover funds in real time.

What are the risks?

There is little to no risk. The status quo is the protocol is hacked and the hacker gets 100% of funds. But with Safe Harbor, we unlock the upside of whitehats stepping in and rescuing funds. So the worst case scenario is the status quo, while the best case scenario is all funds are rescued by the protocol.

Whitehats only receive protection if they follow every requirement. If no exploit happens, nothing changes. If they do not follow Safe Harbor, they’re a blackhat

Can DAOs adopt it?

Yes. Safe Harbor was built with DAOs in mind. No legal entity is required - just a governance vote and public on-chain registration. Many protocols who have adopted are DAOs (ex: Uniswap, Balancer, Zksync)

Can Non-DAOs adopt it?

Yes. Centralized teams and foundations can also adopt Safe Harbor by publishing their scope and adoption terms. No DAO is required. Many protocols who have adopted are centralized teams (Pendle, Polymarket)

Who is the agreement with?

The Safe Harbor agreement is structured as a public unilateral offer - a legally binding offer made by your protocol to any whitehat who acts under the published terms. There’s no need to know or pre-approve the individual. If a whitehat follows your rules (e.g. intervenes during an active exploit, returns funds to the recovery address, meets any KYC requirements), the agreement becomes binding. No signatures or formal negotiation required.

Do we need to sign a legal contract (like DocuSign)?

Nope. Safe Harbor uses on-chain registration and public adoption details - no signatures or lawyers required. If you’re a DAO, a governance vote is enough.

What if a blackhat initiates a hack with one account, then “whitehats” it with another account to get the bounty?

They’re not covered. Safe Harbor protections only apply to whitehats who are fully independent from the original exploit. If someone initiates a hack and then tries to “rescue” the funds with another address, they’re still considered a blackhat - no bounty, no legal protection, and fully liable.

To reduce this risk even further, we recommend protocols set their Safe Harbor bounty cap at or below their existing bug bounty. This way, there’s no financial incentive to attempt an exploit - it's easier, safer, and more profitable to report the bug through your standard disclosure process than to fake a whitehat rescue under legal risk.

Can we modify the Safe Harbor legal contract?

We strongly discourage protocols from modifying the legal language of the Safe Harbor agreement. The framework is designed as a standard across the industry, so whitehats can understand the rules quickly and act confidently during emergencies.

That said, the agreement is built with flexibility where it matters: you define your scope - such as which contracts are covered, Asset Recovery Addresses, bounty terms, and KYC requirements. These parameters are designed to give you control without breaking the shared standard that makes Safe Harbor effective.

Should our legal team review the Safe Harbor agreement?

It’s optional. The agreement has already been vetted by leading law firms (Cooley, Debevoise & Plimpton, Piper Alderman) and adopted by top-tier protocols like Uniswap, Balancer, and Pendle.

That said, if your legal team wants to review it for extra peace of mind, they absolutely can. Just keep in mind: the agreement is a community standard designed for consistency, so major edits aren’t recommended (and usually unnecessary).

Safe Harbor Eligibility Checklist

SEAL/Initiative

Protocol

DAO

Whitehat

Authored by:

Use this checklist to evaluate whether adopting the SEAL Whitehat Safe Harbor Agreement makes sense for your protocol.

❓Can Safe Harbor Help Your Protocol?

Do you hold user funds in smart contracts? Without Safe Harbor, whitehats who could save your users' funds might hesitate to act due to legal uncertainty around unauthorized access.
Do you want whitehats to help during active attacks? Safe Harbor gives ethical hackers legal protection to intervene immediately, before attackers can drain your protocol.
Do you already have a bug bounty or security disclosure program? Safe Harbor fills the critical gap your bug bounty can't cover - live attacks happening right now when disclosure timelines don't matter.
Do you want to increase the odds of recovering funds? Safe Harbor encourages rescue attempts by trusted whitehats.

If you checked any of the above - you can benefit from adopting our Safe Harbor.

🎯 What Does Adoption Involve?

Define your scope (what’s covered, where funds go, bounty %, etc.)
(If DAO) Pass a governance proposal
Register on-chain
Update your Terms of Service and documentation
Make a public announcement to inform users and whitehats

It’s fast, flexible (DAO or non-DAO), and aligns with industry standards.

🚀 Ready to Get Started?

You have 3 ways to adopt:

Self-adopt using our guide:

→ Self-Adoption Guide
Get help from SEAL (free):

→ Apply for onboarding
Adopt via a third-party:

→ Immunefi: Immunefi Integration Form

Find out more about Safe Harbor here

If you ever need help or have any questions, don’t hesitate to reach out!

📬 Contact us at: [email protected]

Self-Adoption Guide

SEAL/Initiative

Protocol

DAO

Whitehat

Authored by:

This guide walks you through the full process of self-adopting the SEAL Safe Harbor Agreement for your protocol. The goal is to provide whitehats with legal clarity and confidence to rescue funds when it matters most.

To do this effectively, protocols should cover all public and legal bases: defining a clear scope, obtaining DAO approval (if applicable), registering on-chain, updating their terms of service, and making a public announcement.

1. Scope Definition

The first step is defining the scope. This information informs whitehats about how and when they can intervene. It includes which assets are covered, where to send rescued funds, how to contact your team, what bounties apply, and any identity requirements.

Refer to the scope walkthrough: Scope Definitions & Tips
DAO Template: DAO Scope Template
Non-DAO Template: Non-DAO Scope Template

2. DAO Proposal (If applicable)

If you are a DAO, this is a critical step. It formalizes permission from the community and provides legitimacy to the adoption.

DAOs do not need a legal entity. Safe Harbor was designed to allow on-chain communities to adopt the agreement natively.
Use the DAO Proposal draft from Step 1 where you defined the scope. Feel free to edit the proposal to reflect your DAO’s tone and format.
Push your proposal through governance, temp check → formal proposal → Snapshot/Tally/etc.
(Optional) Include the on-chain adoption call in the proposal itself for a full end-to-end flow.

3. On-Chain Adoption

Whether you're a DAO or a centralized team, you'll need to publish your adoption on-chain. This ensures your terms are publicly visible and enforceable.

If you are NOT doing on-chain via DAO proposal:

Follow the guide: SEAL Safe Harbor On-Chain Adoption

If you ARE doing this in your DAO proposal:

On-chain adoption involves two parts:
1. Creating the AgreementV2 contract (the "terms" container)
2. Registering it in the Safe Harbor Registry (this is what matters for whitehats)
The DAO proposal should handle step 2, while step 1 can be done beforehand using the SEAL Self-Adoption Tool.

4. Update Terms of Service & Docs

To ensure all users are informed and legally covered, update your Terms of Service and documentation.

Terms of Service (TOS)

Add the following language to your TOS:

User Agreement to be Bound By Agreement, Consent to Attempted Eligible Funds Rescues and Payment of Bounties

The User hereby acknowledges and agrees to, and consents to be bound by the terms and conditions of, that certain Safe Harbor Agreement for Whitehats, adopted by the Protocol Community on [INSERT DATE HERE] (the ”Whitehat Agreement”), available here https://bafybeigvd7z4iemq7vrdcczgyu2afm7egxwrggftiplydc3vdrdmgccwvu.ipfs.w3s.link, as a "User" and member of the "Protocol Community" thereunder. Without limiting the generality of the foregoing:

the User hereby consents to Whitehats attempting Eligible Funds Rescues of any and all Tokens deposited into the Protocol by the User and the deduction of Bounties out of User’s deposited Tokens to compensate Eligible Whitehats for successful Eligible Funds Rescues;

the User acknowledges and agrees that Tokens may be lost, stolen, suffer diminished value, or become disabled or frozen in connection with attempts at Eligible Funds Rescues, and assumes all the risk of the foregoing;

the User acknowledges and agrees that payment of the Bounty as a deduction from User’s Tokens to an Eligible Whitehat may constitute a taxable disposition by the User of the deducted Tokens, and agrees to assume to all risk of such adverse tax treatment; and

the User agrees to hold the other Protocol Community Members harmless from any loss, liability or other damages suffered by the User in connection with attempted Eligible Funds Exploits under the Whitehat Agreement.

This is also found in Exhibit D in the legal agreement

Documentation

Under your documentation's "Security" or "Bug Bounty" section, include:

"This protocol has adopted the SEAL Safe Harbor Agreement for Whitehats, which empowers approved security researchers to intervene during active exploits to rescue funds. Full adoption details, scope, and bounty terms are publicly available [here]."

Replace [here] with your actual registry listing or agreement address.

5. Announcement

Once everything is live, it's time to communicate publicly. This signals to whitehats, users, and the broader ecosystem that your protocol is protected.

Use Twitter, Discord, forums, and governance portals.
Highlight your on-chain registration, bounty terms, and any DAO vote.
Example announcement:

Today, we’re proud to announce that [Protocol Name] has officially adopted the @_seal_org Safe Harbor Agreement - a legal and technical framework that empowers whitehats to rescue funds during active exploits.

This move brings us into alignment with some of the most security-forward protocols in the space - Uniswap, Pendle, Balancer - as we take real steps to defend our community and user funds.
Feel free to coordinate with SEAL - we're happy to co-announce and amplify it.

If your protocol ever needs help with adoption, SEAL is happy to help answer any questions, walk you through adoption, amplify announcements, etc

📬 Contact us at: [email protected]

Safe Harbor Scope Terms

SEAL/Initiative

Protocol

DAO

Whitehat

Authored by:

When adopting Safe Harbor, you’ll define specific parameters that control what’s covered and how whitehat rescues work. Below is an explanation of each term with tips and best practices.

1. Asset Recovery Address

The address where whitehats must return rescued funds after an exploit.

Tips:

Use a highly secure smart contract wallet (e.g., Gnosis Safe or governance-controlled address).
Ensure it can handle large inflows, potentially a significant portion of your TVL.
Please refer to this framework on Wallet Multisig Security

2. Security Contact

The person or team whitehats must notify after completing a rescue.

Tips:

Provide multiple points of contact (email, Signal, Telegram) for redundancy.
Make sure these methods of notification are checked in case of an active exploit. Whitehats should reach out within 6 hours of a rescue

3. Assets Under Scope

The on-chain contracts or accounts that whitehats can legally interact with under Safe Harbor.

Scope Options:

All: Covers the listed address and all child contracts, both existing and future.
ExistingOnly: Covers the address and child contracts deployed before adoption.
FutureOnly: Covers the address and child contracts deployed after adoption.
None: Covers only the listed address.

Examples:

All: Use for factories or deployer addresses that create vaults, pools, or markets. Covers all current and future instances.
None: Use for single vault contracts where funds are concentrated and no child contracts exist.
ExistingOnly / FutureOnly: Very rarely used; typically for protocols with legal or operational constraints on future contracts.

Tips:

If your protocol deploys many contracts, include your deployer address EOA/Multisig/Governance Addresses with All. This avoids the need for updates.
Keep this list current - if you launch new deployments and they aren’t covered, whitehats can’t legally intervene.

4. Bounty Terms

Defines how whitehats are rewarded for successful intervention.

4.1 Bounty Calculation

As a FYI, the formula to determine the bounty payout to the whitehats is:

bounty = min(bountyPercentage × recoveredAmount, bountyCapUSD)

Predefining this ensures no post-hack negotiation and prevents delays.

4.2 Bounty Percentage

The percentage of recovered funds that a whitehat receives.

Recommendation:

10% is standard in the industry.
Set equal to your bug bounty program's critical exploit payout percentage

4.3 Bounty Cap (USD)

The maximum bounty amount for a single whitehat, in USD.

Recommendation:

Match or set equal to your bug bounty program’s max payout to avoid incentives for malicious behavior.

4.4 Aggregate Bounty Cap (USD)

The maximum total bounty payout across all whitehats for a single incident. Bounties will be distributed pro-rata.

Rule:

If you set an Aggregate Bounty Cap, you must set retainable to false so all funds return to the protocol first, then bounties are distributed.

4.5 Retainable

Whether whitehats keep their bounty directly or return everything first.

True: Whitehat deducts bounty before returning funds.
False: Whitehat returns all funds; protocol pays bounty afterward.

Rule:

Cannot set retainable to true if Aggregate Bounty Cap is enabled.

5. Identity Verification

Determines whether whitehats must verify their identity.

Options:

Anonymous: No KYC (most crypto-native option).
Pseudonymous: Requires a pseudonym.
Named: Legal name verification (KYC required).

Tips:

Most protocols choose Named (KYC) for compliance.
Some opt for crypto-native option of protecting the whitehat’s anonymity.

6. Diligence Requirements

Additional compliance checks for whitehats before bounty payout (applies only if identity = Named).

Generic Template:

<PROTOCOL_NAME> requires all eligible whitehats to undergo Know Your Customer (KYC) verification and be screened against global sanctions lists, including US, UK, and EU regulations. This process ensures that all bounty recipients are compliant with legal and regulatory standards before qualifying for payment.

If you ever need help or have any questions, don’t hesitate to reach out!

📬 Contact us at: [email protected]

On-Chain Adoption Guide

SEAL/Initiative

Protocol

DAO

Whitehat

Authored by:

This guide explains how protocols can register their Safe Harbor adoption on-chain. Registering ensures your adoption is public, verifiable, and enforceable.

Why On-Chain Adoption Matters

On-chain registration:

Makes your Safe Harbor adoption public and transparent.
Signals to whitehats that your protocol is officially covered under the agreement.
Publishes your terms (scope, bounty, contacts) on-chain in a way that’s traceable and verifiable, even if updated later.

Three Ways to Adopt On-Chain

Protocols can adopt on-chain using one of three methods:

Direct adoption via SEAL’s self-adoption tool
Through a multisig (e.g., Gnosis Safe)
Foundry script or custom code

Important Note

The address that registers represents your protocol on-chain.
Most protocols use multisigs for this step.

1. SEAL Self-Adoption Website (Fastest Method)

Navigate to the SEAL Self-Adoption Tool (coming soon).
Fill in your scope details (Asset Recovery Address, Assets Under Scope, Bounty Terms, etc.).
Choose one of the following:
- Direct adoption using a connected wallet (creates and registers your agreement immediately).
- Generate an Agreement for later registration (useful for multisig or custom workflows).
- Export JSON for use in Foundry scripts.

2. Multisig Adoption (Gnosis Safe)

If your protocol uses a multisig, you can adopt on-chain securely without writing custom code.

Steps:

Generate your AgreementV2 contract:
- Use the SEAL Self-Adoption Tool to create an agreement contract payload for your scope.
- Deploy the agreement manually via your preferred method (SEAL tool or custom deploy).
Open your Gnosis Safe and go to the Transaction Builder app.
Enter the Safe Harbor Registry address:
- Default for most EVM chains: [0x1eaCD100B0546E433fbf4d773109cAD482c34686](https://etherscan.io/address/0x1eaCD100B0546E433fbf4d773109cAD482c34686)
- Full address list: Registry Addresses.
Select the method: adoptSafeHarbor(address agreementAddress) and input your deployed AgreementV2 contract address.
Add the transaction and simulate it:
- You should see a SafeHarborAdoption event with your multisig as the entity.
Collect signatures and execute.

3. Foundry Script / Custom Code

If you prefer deploying via code or need custom integrations, you can use SEAL’s Foundry script or write your own.

Using SEAL’s Foundry Script

Repository: security-alliance/safe-harbor
Script: registry-contracts/script/v2/AdoptSafeHarborV2.s.sol

Steps:

Generate your scope JSON via the SEAL tool or manually prepare it.
Paste the JSON into: registry-contracts/agreementDetailsV2.json
Run the script:
- Deploys the AgreementV2 contract via the factory.
- Registers your adoption in SafeHarborRegistryV2.
Optional: Modify the script to set a custom owner (e.g., your DAO multisig).

Manual Method

Deploy your agreement directly: AgreementFactoryV2.create(AgreementDetailsV2 memory details, address registry, address owner)
Register it: SafeHarborRegistryV2.adoptSafeHarbor(address agreementAddress)
Use the deployed Registry & Factory Addresses

Key Contracts

Agreement Factory: Deploys AgreementV2
Safe Harbor Registry: Registers adoption
Deployed Addresses: View Registry & Factory Addresses

If you ever need help or have any questions, don’t hesitate to reach out!

📬 Contact us at: [email protected]

Safe Harbor for Whitehats

SEAL/Initiative

Whitehat

Authored by: