How We Approach Smart Contract Security
Smart contract security is not a checkbox. A protocol that handles real capital has to treat it as a continuous discipline. This post covers how SukukFi approaches security, what the audit process looked at, and where the reports live.
What the Audit Covered
SukukFi runs two contract layers with distinct security requirements.
The settlement layer handles batch transfers between parties and manages liquidity reserves. The critical invariants are:
- Batch transfers must be zero-sum. No value is created or destroyed between the start and end of a settlement batch.
- Reserved settlement funds cannot be invested. Funds earmarked for settlement stay segregated.
- The permit system blocks unauthorised exits.
- All transfers in a batch succeed together or all revert. Partial settlement failure is not a valid outcome.
Attack vectors that auditors focused on here: manipulating batch netting calculations to extract value, withdrawing mid-settlement to force a batch failure, double-spending settlement obligations, and injecting false balance adjustments to fabricate profits.
The investment layer handles the vault itself, share accounting for duPRT, and the async deposit and redemption flow.
The critical invariants are:
- Pending and claimable funds stay off-limits for investment. Reserved assets cannot be redeployed until they are formally processed.
- duPRT share accounting must be backed by vault assets and settlement positions at all times. Shares cannot be issued without corresponding assets.
- Pending-to-claimable conversions must be exact. Rounding errors or miscalculations here would silently mis-allocate capital.
- The contract cannot invest beyond the available balance.
Attack vectors that auditors focused on here: inflating the reserved-asset calculation to justify over-investment, exploiting the async flow to claim assets twice, front-running fulfillment transactions, and corrupting storage slots during contract upgrades.
Why These Specific Invariants Matter
ERC-7540 introduces async redemption requests, which means the vault holds redemption claims in a pending state before fulfilling them. This creates a window where the accounting between pending claims, claimable funds, and deployed capital has to be correct at every state transition.
An error in how the contract tracks pending claims could mean that a depositor's redemption request is double-counted, or that their claimable balance is inflated. Neither scenario fails loudly. Both scenarios require careful testing with adversarial state manipulation.
ERC-4626, the base vault standard, specifies share-to-asset conversion in a way that is vulnerable to inflation attacks when the vault is near-empty. Auditors confirmed the protocol's handling of this edge case, specifically at vault initialisation and after large redemptions that leave a near-zero share supply.
Where to Find the Reports
SukukFi publishes smart contract audit reports in its public security repository:
github.com/sukukfi/security-audits
Each report includes findings by severity, the remediation steps taken for each finding, and the final status. Findings labelled Critical or High were resolved before deployment. Medium and Informational findings are documented with the rationale for acceptance or remediation.
Reviewers needing architectural context should read the Security Considerations and Integration Notes for Auditors sections in the technical documentation before reading the audit reports.
What Audits Do Not Cover
An audit assesses a specific version of a contract against a specific scope. It does not cover:
- Operational risk: the key management procedures, the off-chain systems that trigger on-chain transactions, or the human processes around settlement.
- Oracle and price feed risk: the protocol does not use price oracles for its core accounting, but integration points with external systems carry their own risks that audits scope separately.
- Upgrade risk: upgradeable contracts introduce a trust assumption around the upgrade mechanism itself. The protocol's upgrade process and governance controls are documented separately.
- Economic attacks: formal security audits focus on code correctness. Economic attacks (griefing, sandwich attacks, liquidity manipulation) require separate adversarial economic modelling.
Ongoing Security Posture
The audit is the starting point. After deployment, the security posture is maintained through:
- Monitoring for anomalous transactions against the invariants described above
- A staged upgrade process with time-locks for any contract changes
- Bug bounty coverage for production contracts
- Version control and diff review for any changes to deployed bytecode
Security for a live financial protocol is a continuous commitment. The audit reports document what was reviewed. The invariants above document what the protocol is built to guarantee.
To review the full technical architecture, start with the multi-tier system overview. For ERC-4626 and ERC-7540, read our vault standards explainer.