Files

defiQUG e8ae376e90 Enhance API services with validation and error handling improvements

- Integrated Zod validation schemas across various API routes to ensure input integrity and improve error handling.
- Updated `mapping-service`, `orchestrator`, `packet-service`, and `webhook-service` to utilize validation middleware for request parameters and bodies.
- Improved error handling in webhook management, packet generation, and compliance routes to provide clearer feedback on request failures.
- Added new validation schemas for various endpoints, enhancing overall API robustness and maintainability.
- Updated dependencies in `package.json` to include the new validation library.

2025-12-12 20:23:45 -08:00

1.9 KiB

Raw Blame History

ADR-002: Custom Errors for Gas Efficiency

Status: Accepted Date: 2024-12-12 Deciders: Development Team

Context

Solidity 0.8.4+ introduced custom errors as a gas-efficient alternative to require() statements with string messages. Custom errors save gas because they don't store string data in bytecode.

Decision

We will use custom errors throughout the codebase instead of require() statements with string messages:

Error Organization: Group errors by contract/module:
- TokenErrors.sol - eMoneyToken errors
- BridgeErrors.sol - BridgeVault138 errors
- RegistryErrors.sol - Registry contract errors
- FactoryErrors.sol - TokenFactory138 errors
Naming Convention: Use descriptive, prefixed names:
- BridgeZeroToken() instead of ZeroToken()
- DebtLienNotActive() instead of LienNotActive()
- Prevents naming conflicts across modules

Rationale

Gas Savings: Custom errors are ~200-300 gas cheaper than string errors
Better UX: Errors can include parameters (addresses, amounts) for better debugging
Type Safety: Compile-time checking of error signatures
Code Clarity: Errors are defined alongside contracts

Consequences

Positive

Significant gas savings on revert paths
Better error messages with parameters
Type-safe error handling
Cleaner code organization

Negative

Requires updating all test files to use new error selectors
Slightly more verbose error definitions

Alternatives Considered

Keep require() strings: Traditional approach
- Rejected: Higher gas costs, less informative errors
Mixed approach: Custom errors for common paths, strings for rare cases
- Rejected: Inconsistent, harder to maintain

Implementation

All require() statements replaced with custom errors
Error files organized by contract module
Tests updated to use error selectors
Documentation updated

1.9 KiB Raw Blame History