-
Notifications
You must be signed in to change notification settings - Fork 1
Configuration Security
This document outlines the key configuration settings for the Nexus project and details our CI/CD workflow, versioning, and security practices to ensure robust and secure development. We maintain high standards in security, gas optimization, and code style, adhering to strict processes.
-
Solidity Compiler Version: The project uses Solidity version
0.8.26
. This specific version is chosen for its stability, latest features, and compatibility with the project's smart contracts.
Note
Solidity 0.8.26 introduces custom error types with the require
statement, which enhances error handling and debugging. As per the recommendations from the Solidity team, using the latest version ensures the best security, features, and optimization.
-
EVM Version: The Ethereum Virtual Machine (EVM) version is set to
paris
. This EVM version includes features and optimizations compatible with the Solidity compiler version in use. -
Intermediate Representation (IR): The
via-ir
option is enabled. This setting uses the Intermediate Representation (IR) pipeline, which provides advanced optimizations and improved debugging capabilities.
Tip
Advantages of via-ir
:
- Optimized bytecode, leading to more efficient contracts.
- Enhanced debugging capabilities for easier identification of issues.
- Better security through improved analysis during compilation.
- Future-proofing with easier integration of future compiler features.
-
Optimizer Enabled: The optimizer is enabled (
true
) to reduce gas costs and improve contract efficiency. -
Optimizer Runs: The number of optimizer runs is set to
1,000,000
, balancing between code efficiency and deployment cost.
Important
Enabling the optimizer and setting it to a high number of runs ensures that the smart contracts are gas-efficient, which is crucial for cost-effective deployment and operation.
The EntryPoint contract is deployed at the same address (0x0000000071727De22E5E9d8BAf0edAc6f37da032) across all EVM chains for consistency. On new chains, the EntryPoint can be deployed using Nick's keyless method to achieve predictable addresses, facilitating easier integration and interoperability.
Important
Using the same EntryPoint address across all EVM chains ensures consistent and predictable behavior, simplifying integration for developers.
We use Semantic Versioning (SemVer) to manage the versions of our smart contracts and related software components. The versioning format is MAJOR.MINOR.PATCH, where:
- MAJOR: Indicates breaking changes that require a migration or upgrade.
- MINOR: Updates that affect the contract's bytecode, possibly changing the contract address.
- PATCH: Backward-compatible bug fixes and updates that do not affect the contract's bytecode or address.
Note
All code that is not merged to the dev
branch is not production-ready. Be cautious when using such code in a production environment.
Our development workflow follows the Gitflow model, which organizes branches and workflows for effective collaboration and release management. The main branches are:
- main: Contains production-ready code.
- dev: Integration branch for features and fixes.
Feature branches are created from dev
, and release branches are created from dev
before merging into main
.
Tip
Gitflow ensures a structured and organized workflow, allowing for parallel development and streamlined release processes.
We employ a robust CI pipeline using GitHub Actions to automate testing, linting, and code analysis. Below are the primary CI workflows:
-
PR Automation Workflow: Ensures changes to
package.json
andCHANGELOG.md
are included in PRs. - Branch Check: Verifies branch naming conventions and merge rules.
- Unified CI Workflow: Runs tests, lints code, checks coverage, and performs security analysis.
Important
These workflows ensure that every pull request is thoroughly tested and adheres to our coding standards, maintaining high quality and security.
Security is paramount in our development process. We employ multiple strategies to ensure our codebase remains secure:
- Static Analysis: Tools like Slither and OpenZeppelin Code Inspector are integrated into our CI pipeline to identify potential security vulnerabilities.
- Continuous Monitoring: Regular audits and real-time monitoring of code changes ensure that any security issues are promptly identified and addressed.
- Automated Testing: Comprehensive unit tests, integration tests, and coverage reports ensure that new changes do not introduce vulnerabilities.
Tip
We adhere to strict coding standards and practices as outlined in the Solidity Style Guide.
Our code has undergone extensive security audits by leading security firms, including:
- OpenZeppelin: Known for their extensive expertise in blockchain security.
- Spearbit: Renowned for their thorough and detailed audit processes.
- Cyfrin: Experts in smart contract security and blockchain solutions.
You can find all the audit reports in our GitHub repository.
Warning
Always ensure you are using the latest audited version of the smart contracts to avoid any known vulnerabilities.
We have also undergone a round of gas audits with Gaslite to ensure the efficiency of our smart contracts. This helps in identifying and optimizing gas usage for better performance.
Note
Regularly run gas audits to monitor and optimize gas usage for cost-effective operations.
Nexus supports various advanced security features, including the use of Web2 solutions such as OAuth and Passkey, and the ability to define custom security mechanisms like multisig wallets. These features enhance the security and usability of the Nexus platform.
Caution
Although modular smart accounts are secure by design, the security of your account heavily depends on the modules you use. Always verify the security of any external modules before integrating them into your Nexus smart account.
By adhering to these practices and utilizing our robust CI/CD pipeline, we ensure that the Nexus project remains secure, efficient, and reliable for all users.
- Home
- Nexus Architecture
- Access Control
- Execution Framework
- Modules
- Factories
- Migration Guide
- Testing Documentation
- Configuration and Security
- Libraries
- FAQ
- Biconomy Solidity Style Guide
- Security Considerations
- Team
-
Contracts
- Nexus
- Base
- Common
- Factory
- AbstractNexusFactory
- BiconomyMetaFactory
- K1ValidatorFactory
- ModuleWhitelistFactory
- NexusAccountFactory
- Modules
- Utils