background
logo

Security Audit Report for Puffer's Puffer-Protocol v2

DESCRIPTION

The target of this audit is the private code repository of Puffer-Protocol v2 of Puffer. Puffer-Protocol v2 is a cross-chain restaking and attestation integration that connects Puffer validator operations with Automata-verified TEE sessions. The audit scope covers two main layers of code. The first is the Puffer contract layer, which handles validator registration and provisioning, Guardian enclave key rotation, withdrawal batch processing, Validator Ticket accounting, reward distribution, and L1/L2 reward bridging . The second layer is the Automata TEE workload measurement layer, which verifies TDX/SNP reports, TPM quotes, AK and session-key delegation, base image and workload policies, PCR constraints, and session lifecycle operations consumed by Puffer’s Guardian trust path. Specifically, for code in puffer-contracts-updates-private, the audit focuses on the codes located in the following directories/files: l2-contracts/src mainnet-contracts/src For code in automata-tee-workload-measurement, the audit focuses on the codes located in the following directories/files: src/SessionRegistry.sol src/BaseImageRegistry.sol src/WorkloadRegistry.sol src/TeeVerifier.sol src/SignatureVerifier.sol src/KeyResolver.sol Other files are not within the scope of the audit. Additionally, all dependencies of the Target are considered reliable in terms of both functionality and security, and are therefore not included in the audit scope.

Please refer to the report for the detailed audit scope.

Our audit methodology employs automated vulnerability scans, manual verification, and business logic analysis to uncover potential security issues coupled with gas and code quality optimization recommendations.

In summary, we did not find any critical issues within the audited codebase. However, we have identified some non-critical issues that should be addressed. Additionally, we have put forth recommendations and notes that should be taken into consideration. It is important to note that the scope of our audit was strictly limited to the specific code versions mentioned in the report. Any updates made subsequent to our review would require a re-evaluation.

KEY FINDINGS

In total, we find 9 potential issues in the smart contract. We also have 8 recommendations and 14 notes, as follows:

High Risk: 0
Medium Risk: 4
Low Risk: 5
Recommendation: 8
Note: 14
ID Severity Description Status
1 Medium Incorrect accounting when reverting partially claimed intervals Fixed
2 Medium Incorrect reversal due to insufficient L1 interval state Fixed
3 Medium Replay of stale Guardian rotation proofs Fixed
4 Medium Lack of workload status check Fixed
5 Low Lack of check on duplicate enclave addresses Fixed
6 Low Circumvention of static PCR policy Fixed
7 Low Lack of freshness validation for DCAP ZK proofs Fixed
8 Low Lack of check on debug requirements Fixed
9 Low Front-running of base image and workload registration Fixed
10 - Align the documentation with the current implementation Fixed
11 - Add a maximum Workload Session TTL Fixed
12 - Prevent key reuse during session rotation Fixed
13 - Bind successor keys to owner authorization Confirmed
14 - Add RSA exponent validation Fixed
15 - Flush removed Guardian reward tokens Fixed
16 - Add zero-address checks for immutable dependencies Confirmed
17 - Add explicit Guardian action domains Confirmed
18 - Verify the workload before allowlist operations -
19 - Atomic upgrade for PufferDepositorV2 initialization -
20 - Session lifecycle does not preserve workload continuity -
21 - DCAP verifier integration assumes a zero-fee backend -
22 - Workload base-image lists are identifier policies -
23 - Guardian enclave key is reused for encryption and signing -
24 - Potential centralization risks -
25 - Trust assumptions of enclave keys -
26 - Session and enclave keys must not be exportable -
27 - Monitor VT balances to prevent blocked withdrawals -
28 - Check the base image status separately -
29 - Migration requirements in the upgrade script -
30 - Assumption of vTPM Migration -
31 - Trust assumption of GCP TEE-to-vTPM binding -

More details are provided in the audit report.

Take the first step towards a secure future

Reach out now for BlockSec's expert code audit services, elevate the security of your protocol before it goes live!

Security Audit Report for Puffer's Puffer-Protocol v2 - BlockSec