Agora_Escrow_Manager

Mantle Mainnet · scan depth quick · generated 6/21/2026, 3:57:49 PM

Risk Score

Archon completed a read-only Mantle Mainnet audit of Agora_Escrow_Manager and found 3 deterministic findings. The highest-priority issue is Timestamp-sensitive settlement lacks explicit tolerance window, with risk score 24/100 based on severity-weighted findings. The deadline check uses exact `block.timestamp` comparison, which can cause transactions to revert even if they are submitted very close to the deadline due to slight block timing variations. Without a tolerance window (e.g., a few seconds), legitimate user actions near the expiry may reliably fail. Review the recommended fixes and run regression tests before deployment. External imports could not be resolved (openzeppelin/4/contracts/access/Ownable2Step.sol, openzeppelin/4/contracts/token/ERC20/IERC20.sol, openzeppelin/4/contracts/token/ERC20/utils/SafeERC20.sol, openzeppelin/4/contracts/utils/Pausable.sol, openzeppelin/4/contracts/utils/ReentrancyGuard.sol, @openzeppelin/contracts/access/Ownable2Step.sol, @openzeppelin/contracts/token/ERC20/IERC20.sol, @openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol, @openzeppelin/contracts/utils/Pausable.sol, @openzeppelin/contracts/utils/ReentrancyGuard.sol); static analysis ran in reduced mode, so Slither/import-dependent checks were skipped while Archon's deterministic rules still ran.

Models used: Tencent Cloud TokenHub (deepseek-v4-pro) — AI reasoning served on Tencent Cloud TokenHub.

Findings

low: 0high: 0info: 2medium: 1critical: 0

Severity	Finding	Location	Confidence
medium	Timestamp-sensitive settlement lacks explicit tolerance window The deadline check uses exact `block.timestamp` comparison, which can cause transactions to revert even if they are submitted very close to the deadline due to slight block timing variations. Without a tolerance window (e.g., a few seconds), legitimate user actions near the expiry may reliably fail.	EscrowManager.sol:62	70%
info	Mark never-changing value constant or immutable The expression `agentRegistry.ownerOf(escrow.agentId)` is computed inside a function but the result is invariant for a given `agentId` as long as the registry is immutable. Marking the registry reference as `immutable` reduces repeated storage lookups for the registry address, though the call itself is still external. If the registry address never changes, making it immutable saves gas.	EscrowManager.sol:140	85%
info	Cache repeated storage read The function reads `escrowId` from storage once, but the subsequent `_escrows[escrowId]` assignment performs an SLOAD + SSTORE for the mapping. Although the code snippet shows only one explicit `_nextEscrowId++` sload, the typical issue is that `escrowId` is used multiple times in the same function, causing repeated sloads. However, the given snippet only uses it once. If downstream logic in the same function accesses `_escrows[escrowId]` or `escrowId` again, those accesses would re-read from storage. Caching the value in memory would save gas.	EscrowManager.sol:69	80%

Severity

Finding

Location

Confidence

medium

Timestamp-sensitive settlement lacks explicit tolerance window

The deadline check uses exact `block.timestamp` comparison, which can cause transactions to revert even if they are submitted very close to the deadline due to slight block timing variations. Without a tolerance window (e.g., a few seconds), legitimate user actions near the expiry may reliably fail.

EscrowManager.sol:62

70%

info

Mark never-changing value constant or immutable

The expression `agentRegistry.ownerOf(escrow.agentId)` is computed inside a function but the result is invariant for a given `agentId` as long as the registry is immutable. Marking the registry reference as `immutable` reduces repeated storage lookups for the registry address, though the call itself is still external. If the registry address never changes, making it immutable saves gas.

EscrowManager.sol:140

85%

info

Cache repeated storage read

The function reads `escrowId` from storage once, but the subsequent `_escrows[escrowId]` assignment performs an SLOAD + SSTORE for the mapping. Although the code snippet shows only one explicit `_nextEscrowId++` sload, the typical issue is that `escrowId` is used multiple times in the same function, causing repeated sloads. However, the given snippet only uses it once. If downstream logic in the same function accesses `_escrows[escrowId]` or `escrowId` again, those accesses would re-read from storage. Caching the value in memory would save gas.

EscrowManager.sol:69

80%

Public validation

Challenge ledger

Anyone can challenge this artifact. Archon records the challenge in the database with a deterministic hash and references any existing report proof tx/hash. No new validation contract is implied.

No challenges recorded yet.

Proof Verification

Stored report hash

0x32f83e59327e4f682b8743db5d25ed6b384da213ecf5a7f4e053b7b7bd57485f

Re-derived hash

0x32f83e59327e4f682b8743db5d25ed6b384da213ecf5a7f4e053b7b7bd57485f

Metadata URI

ipfs://QmdY3Ycb1fB9QFmPmQT2jLqhUap6dBjpgi4exWeAb9HJuN

Result

Hash match + ERC-8004 on-chain attestation present

Mantlescan

ERC-8004 Reference

{
  "author": "0xBd88eAE165F8A00B1B33357Fb0880CD4fE5C5E70",
  "agentId": "97",
  "contract": "0xe7043e2ec95eF357FbBa3359BA2f1edb10cEAD2a",
  "loggedBy": "0xBd88eAE165F8A00B1B33357Fb0880CD4fE5C5E70",
  "mechanism": "archon-proof-registry",
  "reputation": {
    "tag2": "risk:24",
    "txHash": "0x7d830502dfb4a7e59cf98e5257e15d3e046d6c97f66007b4e8e44c69b3000acb",
    "agentId": "97",
    "feedbackIndex": "22",
    "feedbackClient": "0x8cd94bc5Ce29ECDA7feDbc14D264873835284D79",
    "reputationRegistry": "0x8004BAa17C55a88189AE136b182e5fdA19dE9b63"
  }
}

Careful scope

Archon reports are risk intelligence with confidence scores and recommended fixes. They are not guarantees, certifications, or claims that a contract is safe.