Security

Deposits are only worth locking in escrow if the escrow itself is trustworthy. Here is exactly what has and has not been done to verify pi2pi's smart contracts, stated plainly.

Testnet status — read this first

pi2pi runs on Arc Testnet only (chain ID 5042002). It is not deployed to mainnet. Do not treat funds used on Arc Testnet as real-world savings — this is a working prototype for pilot and demo purposes, actively preparing for a formal audit ahead of any mainnet deployment. Infrastructure and the main public surfaces were operating, but full production end-to-end testing of financial and contract workflows has not been performed.

What has been done

• Automated static analysis: the two core contracts (RentalEscrow.sol, PropDepEscrow.sol) have been run through Slither (slither-analyzer). Result: 0 High severity findings; 1 Medium finding reviewed and dispositioned as a false positive (intentional state-enum equality check); 3 Low findings reviewed (2 accepted as low risk, 1 noted for a future fix); 4 Info findings acknowledged.
• Automated test suite: an extensive Foundry test suite covers the agreement lifecycle, deposit accounting, adapter integrations (Aave, Morpho), dispute flows, and multiple regression/security-fix scenarios.
• Internal and AI-assisted code review passes have been performed against the contracts and the off-chain enforcement bot as part of ongoing development.

What has not been done yet

• No formal third-party human security audit has been completed. This is planned before any mainnet deployment.
• No mainnet deployment exists. No production financial guarantees are made or implied.
• No legal opinion has been obtained on the enforceability of on-chain rental agreements in any jurisdiction.

How the deposit escrow is structured

Deposits are held by the RentalEscrow contract (and, for optional property-damage coverage, the linked PropDepEscrow contract) — not by either party directly, and not by pi2pi as a company. The contract implements a fixed on-chain state machine, and an automated enforcement bot is implemented to handle deadline-based transitions (missed rent, unanswered claims, expired dispute-freeze windows) instead of requiring manual staff intervention. This describes what the code implements, not a claim that every path has been exercised end-to-end in production. See Deposit protection for the full mechanics.

Report a security issue

If you find a vulnerability, contact @dim_ul directly rather than disclosing it publicly.