Auditoría de smart contracts

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.

Prosper Contract is an on-chain launch protocol designed to integrate external R25 Vaults with dedicated pToken campaigns. For each integrated Vault, the protocol creates and manages an independent campaign that begins with an internal launch and continues through liquidity migration to an external market. After the migration, the protocol supports reward claims and uses collected channel fees to conduct pToken buybacks. This structure provides each R25 Vault with an isolated campaign lifecycle while using a shared framework for token launches, liquidity migration, reward distribution, and fee-funded buybacks. Compared to Version 1 (68c547), Version 2 (b8ef7f) introduces asynchronous R25 deposit requests with user cancellation, canonical pair protection, and time-locked LP positions instead of permanent LP burning. It also extends failed-campaign handling by burning reserved tokens and converting accrued fees into R25 Vault Shares that users can reclaim through a Merkle-based mechanism without an expiration period or administrative sweep.

Dex Topup provides deterministic, permissionless deposit addresses for bridging ERC20 tokens through the official TokenBridge. Each user’s proxy address can be precomputed before deployment, allowing tokens to be sent there in advance. Once funded, anyone can call the factory contract to deploy the proxy and forward the tokens to the TokenBridge, with the receiver fixed to the original user. The module acts only as a lightweight forwarding layer and does not maintain balances or custody funds long term.

The reviewed update extends the protocol’s oracle infrastructure by integrating Atlas and Outlayer as dedicated price-data sources. The changes introduce source-specific payload decoding and validation, signature verification, authorized-signer configuration, price normalization, price-reporting interfaces, and token-to-feed mappings. The contract’s storage layout and migration procedures have also been updated to accommodate the new signerrelated state while maintaining compatibility with previously stored oracle data.

The multisig-timelock-contracts is a token vault deployed on BSC and Sui. It implements a weighted multisig scheme based on off-chain signatures, combined with a conditional timelock. Each owner holds a weight, and an operation is authorized once the combined weight of the signers reaches a fixed threshold. The timelock delay applies only when at least one participating signer is flagged as timelocked. Both chains share identical high-level logic, differing solely in the signature primitive: EIP712 with ECDSA on BSC and Ed25519 on Sui. The configured owners are A (weight 2, timelocked), B (weight 1, and C (weight 1, with a threshold of 2. Accordingly, A alone requires the delay, B and C together may execute immediately, and B or C alone is rejected. The only governed operation is transferring whitelisted tokens out of the vault, and all configuration is fixed at deployment and immutable.

This project implements a Fusion-style resolver for settling 1inch Limit Order Protocol orders. During settlement, the resolver receives the maker asset, swaps it through an external aggregator into the taker asset, and allows the Limit Order Protocol to complete payment to the maker or receiver. The contract also includes executor access control, pause controls, token sweeping to configured vaults, and native ETH handling for WETH unwrap flows. Its safety model depends on trusted executors, trusted protocol dependencies, and off-chain validation of swap routes and profitability.