OpenZeppelin completed a security audit of the Argent Labs yearly-approval-contract, focusing on the yearly_allowance.cairo Starknet module. The audit examined allowance lifecycle management, spend execution, and administrative controls for recurring ERC-20 spending limits over 365-day periods. A total of 6 issues were identified: 0 critical, 0 high, 0 medium, and 2 low severity findings. One low issue was resolved, while the other was acknowledged but not fixed. Additionally, 4 notes were raised, none addressed. The low-severity findings include a missing validation of the token address in the constructor. If an invalid token address is provided during deployment, the contract becomes permanently misconfigured, requiring redeployment. The team accepted this risk, citing integration tests and QA checks in place. The other low issue flagged an allowance race condition where an operator could front-run a user's allowance update to spend both old and new allowances. This was resolved through documentation updates in pull request #3, warning users to set allowance to zero before changing to a new value. For wallet and key holders using this contract, the audit highlights several important considerations. Users must keep their token balances sufficient to cover operator spends within configured limits. They should also be aware that revoking ERC-20 approval without disabling the contract leaves the configuration active, leading to failed transfers rather than blocked attempts. The contract operates on a 365-day year ignoring leap years, which may cause minor timing discrepancies. Owners and operators are trusted roles, but their compromise could redirect future collections. Users should understand that reconfiguring allowance resets spent_amount to zero, and initial payments outside the contract are not subject to yearly limits.

关键事实

• 2 low-severity findings: missing token address validation and allowance race condition
• Token address validation issue acknowledged but not resolved; race condition fixed via documentation
• Contract enforces yearly spending caps but relies on operator and owner trust assumptions
• Users should set allowance to zero before updating to avoid front-running by operators
• Revoking ERC-20 approval without disabling contract leads to failed transfers