Lock funds in an immutable contract. Release on delivery. No custodian, no arbitrator, no admin keys. Two parties, one contract, atomic settlement.
No custodian holds your funds. The smart contract is the escrow agent. It cannot be bribed, corrupted, or hacked through social engineering. Code is the only arbiter.
Disputes have a 30-day deterministic timeout. Funds can never be locked forever. The seller can always force-claim after 30 days of unresolved dispute. Game theory, not governance.
No team to fire. No server to shut down. No company to bankrupt. This contract runs on Ethereum for as long as the chain produces blocks. It needs nothing from anyone to keep working.
Traditional escrow requires a company, a bank, or a trusted third party. All of those can fail, freeze your funds, or disappear. Onchain Escrow replaces all of them with 486 lines of immutable Solidity. The contract holds the money. The contract enforces the rules. The contract has no opinion, no office, and no off switch.
Click "Load Recent" to browse escrows or look up by ID.
An immutable, ownerless smart contract for peer-to-peer escrow on Ethereum.
Contract: 0x077364eeA6099F8b7dD70b8FBA1a2569f8AD619A
Chain: Ethereum Mainnet · Owner: None
We present a fully decentralized smart contract protocol for trustless two-party escrow settlement on Ethereum. The protocol allows a buyer to deposit ETH or ERC-20 tokens into an immutable contract, with release controlled entirely by deterministic rules rather than human discretion. A 72-hour auto-release mechanism protects sellers from unresponsive buyers, while a 30-day dispute timeout guarantees that funds can never be permanently locked under any circumstance. The contract has no owner, no administrator, no upgrade mechanism, and no pause function. Once deployed, it operates autonomously and cannot be altered, censored, or seized by any party, including its creators.
The growth of cryptocurrency-denominated commerce has exposed a fundamental coordination problem: in any bilateral transaction where delivery and payment cannot occur simultaneously, one party must extend trust to the other. The buyer who pays before receiving delivery risks losing funds if the seller does not perform. The seller who delivers before receiving payment risks providing labor or goods without compensation. This is the classical escrow problem, and it has existed for as long as commerce itself.
Traditional escrow services solve this problem by introducing a trusted third party who holds funds until both sides fulfill their obligations. Banks, legal firms, and centralized platforms have served this role for centuries. However, the introduction of a third party creates three new categories of risk that did not exist in the original bilateral relationship:
Counterparty risk. The escrow agent itself can fail. It may become insolvent, suffer a security breach, act negligently, or behave dishonestly. The parties who sought to eliminate bilateral trust have merely redirected it toward a new counterparty whose reliability they cannot independently verify.
Jurisdiction risk. The escrow agent operates within a legal jurisdiction that may freeze, seize, or redirect funds based on court orders, sanctions, or regulatory actions that are unrelated to the merits of the underlying transaction.
Censorship risk. The escrow agent retains discretionary authority to refuse service, delay settlement, or impose additional conditions not contemplated in the original agreement between the parties.
Multi-signature wallet arrangements partially address these concerns but introduce their own limitations: they require ongoing coordination between key holders, create operational complexity, and still depend on the honesty and availability of the co-signers.
This paper presents an alternative approach. Onchain Escrow replaces the trusted third party with an immutable smart contract that enforces settlement rules through code rather than human judgment. The protocol satisfies five properties simultaneously: (1) the buyer cannot lose funds without receiving delivery, (2) the seller cannot be defrauded after delivering, (3) funds cannot be permanently locked under any circumstance, (4) no third party can censor or modify the escrow, and (5) the protocol operates indefinitely without human intervention.
The protocol implements a factory pattern in which a single contract deployment creates an unlimited number of independent escrows, each identified by a sequential integer ID. Each escrow is a self-contained state machine with four possible states: Active, Released, Cancelled, and Disputed. State transitions are governed by deterministic rules that depend only on the caller identity and the current block timestamp. No external input, oracle, or administrative action is required for any state transition.
A buyer creates an escrow by calling one of two creation functions: createEscrowETH() for native ETH deposits, or createEscrow() for ERC-20 token deposits. The buyer specifies four parameters: the seller address, the deadline timestamp, the deposit amount, and a terms hash (the keccak256 digest of the off-chain agreement between the parties).
For ERC-20 deposits, the contract measures the actual amount received using a balance-before and balance-after pattern. This accommodates tokens that implement transfer taxes or fees, where the amount received by the contract differs from the amount specified in the transfer call. The measured amount becomes the canonical deposit amount stored in the escrow record.
The buyer may call release() at any time to transfer the deposited funds to the seller. This is the expected flow for successful transactions: the buyer deposits, the seller delivers the agreed-upon goods or services, and the buyer releases payment. The release is atomic and final. A protocol fee is deducted from the released amount and credited to the immutable fee recipient address.
If the buyer does not release after the deadline, the seller may initiate the auto-release process by calling requestRelease(). This function records the current timestamp as the release request time and begins a 72-hour grace period.
The 72-hour duration was chosen to provide adequate time for the buyer to respond across time zones and over weekends, while not imposing an unreasonable delay on the seller. During this window, the buyer has three options: release the funds voluntarily, dispute the release request, or do nothing.
If the buyer does not dispute within 72 hours, the seller calls claimRelease() to receive the funds. This mechanism converts buyer inaction into implicit approval, protecting sellers from buyers who abandon transactions without formally releasing.
If the buyer calls dispute() within the 72-hour grace window, the escrow transitions to the Disputed state. In this state, the auto-release is blocked and both parties must resolve the dispute through one of three paths:
Voluntary release. The buyer may call release() at any time during or after a dispute, sending the full deposit to the seller.
Mutual cancellation. Both parties call mutualCancel(). When both have called, the buyer receives a full refund with no protocol fee.
Deterministic timeout. If neither party acts for 30 days after the dispute was filed, the seller may call forceResolveDispute() to claim the funds. This is the critical safety mechanism that prevents permanent fund lock.
The 30-day timeout creates a dominant strategy for honest buyers: if the seller legitimately delivered, the buyer should release promptly rather than incur a 30-day delay that ends with the same outcome. If the seller did not deliver, the buyer should propose mutual cancellation. In neither case does the buyer benefit from indefinite inaction.
Either party may propose cancellation at any time during the Active or Disputed states. The function records the proposal. When both parties have proposed, the escrow transitions to Cancelled and the full deposit is returned to the buyer with no protocol fee. Cancellation requires bilateral consent.
The contract inherits OpenZeppelin's ReentrancyGuard, applying non-reentrant modifiers to all state-changing external functions. All ERC-20 transfers use OpenZeppelin's SafeERC20 library. All ETH transfers follow the Checks-Effects-Interactions pattern. Existence guards validate that the escrow ID refers to a created escrow before any operation. The contract contains no selfdestruct instruction, no delegatecall, no external contract dependencies, and no oracle requirements.
A widely held assumption in smart contract development is that upgrade mechanisms are necessary for fixing bugs and responding to unforeseen circumstances. We argue that for settlement infrastructure, immutability is not merely acceptable but actively preferable to upgradeability.
An upgradeable contract has a strictly larger attack surface than an immutable one. Every upgrade mechanism requires at least one privileged address with the authority to modify the contract's behavior. This address becomes a permanent vulnerability: it can be compromised through private key theft, social engineering, legal coercion, or insider malfeasance.
Governance mechanisms do not eliminate this risk; they distribute it. A governance token creates a market for control, where the cost of capturing a protocol equals the cost of acquiring sufficient voting power.
An immutable contract eliminates the entire category of administrative risk. There is no key to steal, no governance to capture, no upgrade to exploit, and no emergency function to abuse. Users do not need to trust the deployer, the development team, or any governance process. They need only trust the code and the Ethereum Virtual Machine.
The strongest test of a protocol's decentralization is whether it would continue to function if its creators ceased to exist. Every Onchain Escrow deployment passes this test.
Onchain Escrow demonstrates that trustless bilateral settlement can be achieved without intermediaries, arbitrators, or governance mechanisms. The protocol replaces human judgment with deterministic timeouts and game-theoretic incentives, creating a system where honest behavior is the dominant strategy for all participants under all circumstances.
The auto-release mechanism, bounded dispute window, and 30-day timeout together guarantee a critical invariant: no escrow can lock funds permanently, regardless of participant behavior. This invariant holds without any administrative intervention, external oracle, or governance process.
The contract is permanent settlement infrastructure. It requires no team to operate, no server to maintain, and no governance to manage. It will process escrow transactions for as long as the Ethereum network produces blocks.
— Otoshi
Permanent infrastructure on Ethereum. No keys to lose, no admin to corrupt, no governance to capture.