| Version | Supported |
|---|---|
| Testnet | ✅ |
| Mainnet | Not yet deployed |
We take security seriously. If you discover a security vulnerability, please report it responsibly.
DO NOT create public GitHub issues for security vulnerabilities.
Instead, please:
- Email: Send details to security@ebtprogram.xyz
- GitHub Security Advisory: Use GitHub's private security advisory feature
- Encrypted Communication: PGP key available upon request
Please provide:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
- Your contact information
| Stage | Timeline |
|---|---|
| Initial Response | 48-72 hours |
| Triage & Assessment | 1 week |
| Fix Development | Depends on severity |
| Public Disclosure | After fix is deployed |
We kindly ask that you:
- Allow reasonable time for us to fix the issue
- Avoid exploiting the vulnerability
- Do not disclose publicly until we've addressed it
- Act in good faith
We appreciate security researchers and may:
- Credit you in our security advisories
- Include you in our Hall of Fame
- Offer bug bounty rewards (program TBD)
All contracts implement role-based access control:
// Example roles
modifier onlyOwner() // Contract owner
modifier onlyProtocol() // Protocol caller for claims
modifier onlyEBTProgram() // Cross-contract calls
modifier onlyNFTContract() // TBA locking controlAll state-modifying functions use OpenZeppelin's ReentrancyGuard:
import {ReentrancyGuard} from "@openzeppelin/contracts/security/ReentrancyGuard.sol";
function mint(string calldata userID) external payable nonReentrant {
// Implementation
}| Contract | Emergency Functions |
|---|---|
| FoodStamps | pause(), unpause() |
| EBTProgram | setBlacklistStatus() |
| LiquidityVault | emergencyWithdrawTokens(), emergencyWithdrawETH() |
Token Bound Accounts implement automatic locking when NFTs are approved for transfer:
Approve NFT → TBA Locked → Cannot withdraw assets
Transfer NFT → TBA Unlocked → New owner has access
Cancel Approval → Request Unlock → Assets accessible again
This prevents:
- Seller draining TBA between listing and sale
- Front-running attacks on marketplace transactions
- Asset theft via approval manipulation
| Severity | Count | Status |
|---|---|---|
| Critical | 6 | All Fixed |
| High | 8 | In Progress |
| Medium | 9 | Planned |
| Low | 8 | Best Practices |
See SECURITY_AUDIT.md for the full audit report.
-
Block-Based Rate Limiting
- Current: 3 blocks between mints
- Risk: Can be gamed with multiple wallets
- Plan: Time-based limiting for mainnet
-
Protocol Caller Trust
- Claims executed by protocol address
- Trust assumption: Protocol caller is honest
- Mitigation: Multisig for mainnet
-
Merkle Proof Security
- Current: Basic merkle verification
- Missing: Chain ID and deadline
- Plan: Add for mainnet deployment
-
Verify Contract Addresses
- Always verify you're interacting with official contracts
- Check addresses on Etherscan
-
Use Hardware Wallets
- Store valuable NFTs on hardware wallets
- Never share private keys
-
Check Approvals
- Review token approvals before confirming
- Revoke unused approvals periodically
-
Verify Transactions
- Read transaction details before signing
- Be cautious of phishing sites
-
Follow Security Checklist
- Use
nonReentranton external functions - Validate all inputs
- Use SafeMath/Solidity 0.8+ checks
- Follow checks-effects-interactions pattern
- Emit events for state changes
- Use
onlyOwnerfor admin functions
- Use
-
Testing Requirements
- Unit tests for all functions
- Fuzz tests for edge cases
- Integration tests for flows
- Security-specific tests
-
Code Review
- All PRs require review
- Security-sensitive changes need extra review
- Use static analysis tools
| Tool | Purpose |
|---|---|
| Slither | Static analysis |
| Mythril | Security analysis |
| Foundry Fuzz | Fuzz testing |
| Echidna | Property-based testing |
# Static analysis with Slither
pip install slither-analyzer
slither smart-contracts/contracts/
# Foundry fuzz tests
cd smart-contracts
forge test --fuzz-runs 10000
# Check for common issues
forge test --match-contract Security| Level | Description | Response Time |
|---|---|---|
| Critical | Funds at risk, active exploit | Immediate |
| High | Significant vulnerability | 24 hours |
| Medium | Limited impact vulnerability | 1 week |
| Low | Best practice improvement | Next release |
- Assess - Determine severity and impact
- Contain - Pause affected contracts if needed
- Fix - Develop and test patch
- Deploy - Deploy fix to affected networks
- Communicate - Notify users and community
- Review - Post-mortem and improvements
- Security Email: security@ebtprogram.xyz
- GitHub Security: Use private vulnerability reporting
- Discord: #security channel (for general questions only)
We thank the following for their contributions to our security:
- Internal Security Review Team
- Community Security Researchers
Last Updated: November 2024