escrow

Halot ships matching escrow contracts for 0G EVM and Stellar Soroban. Both contracts lock token deposits, verify assigned verifier signatures during settlement, and distribute provider, verifier, requester, and treasury payouts atomically. This page focuses on what happens after a prepared job exists and before final settlement can be accepted.

Contract Structure

The Soroban contract stores three core data structures keyed by the job hash. The 0G escrow mirrors the same logical shape even though the implementation is Solidity:

enum DataKey {
    Treasury,              // Global treasury address
    Job(BytesN<32>),       // Job state keyed by job_hash
    Assigned(BytesN<32>),  // Assigned verifiers keyed by job_hash
}

Creating a Job

Both contracts require the requester to fund the full amount provider_amount + verifier_pool + platform_fee. On 0G the Solidity contract transfers an ERC-20 token into escrow; on Stellar the Soroban contract transfers the requested token contract balance into escrow. The create step enforces:

• The job hash must not already exist (JobExists)
• Verifier public keys and payout addresses must be equal length (LengthMismatch)
• Threshold must be ≤ number of verifiers and > 0 (BadThreshold)
• Provider and requester must be different addresses (BadProvider)
• All verifier public keys must be unique (DuplicateVerifier)

On-Chain Settlement

Settlement consumes batched attestation data: votes, TEE digests, and signatures. Each contract verifies that every vote came from an assigned verifier and then checks whether approvals or rejections reached the configured threshold.

Payout Distribution

Only verifiers whose vote matches the final decision receive a payout. The treasury receives the full platform fee plus any remainder left over after evenly splitting the verifier pool. The off-chain rules that determine which side actually won are covered on the consensus page.