Blockchain conditional payment system development

Development of Conditional Payment System (Conditional Payment) on Blockchain

Conditional payment is escrow on steroids. Money locked in contract and released only on predetermined condition fulfillment. Sounds simple, but devil is in details: who verifies condition completion, what happens on dispute, how contract knows about off-chain events.

The last question makes this task non-trivial. Blockchain contract isolated — can't verify itself that "task completed", "goods delivered" or "KPI achieved". Needs oracle.

Architecture: Who Confirms Condition

Choice of confirmation mechanism determines entire system architecture.

Arbiter (Trusted Third Party)

Classic escrow: buyer, seller, arbiter. Arbitrator — address with right to call release() or refund(). Simplest implementation, suitable for most B2B cases.

Problem: arbiter centralized. If single person's address — single point of failure and trust. Solution: arbiter is multisig or DAO.

Oracle (Chainlink or Custom)

For conditions obtainable on-chain: asset price, event result, on-chain data from other protocol. Chainlink AnyAPI allows requesting any HTTP data and delivering it to contract.

// Request data via Chainlink Functions
function requestVerification(bytes32 jobId, string calldata apiUrl) external {
    Chainlink.Request memory req = buildChainlinkRequest(
        jobId, address(this), this.fulfill.selector
    );
    req.add("get", apiUrl);
    req.add("path", "result.completed");
    sendChainlinkRequest(req, fee);
}

function fulfill(bytes32 requestId, bool completed) external recordChainlinkFulfillment(requestId) {
    if (completed) {
        _releaseFunds();
    }
}

For simple numeric conditions (price threshold) — Chainlink Price Feeds without additional integration.

Recipient Signature (Cryptographic Proof)

Condition confirmed via digital signature of trusted party. For example, payment system signs transaction confirmation, contract verifies signature via ecrecover. Works without on-chain oracle — signature contains all necessary information.

function releaseWithSignature(
    uint256 paymentId,
    bytes memory signature
) external {
    bytes32 hash = keccak256(abi.encodePacked(paymentId, address(this)));
    bytes32 ethHash = hash.toEthSignedMessageHash();
    address signer = ethHash.recover(signature);
    require(signer == trustedVerifier, "Invalid signature");
    _release(paymentId);
}

Multi-Party Verification

Combination: 2-of-3 between buyer, seller and arbiter. Any two of three can release funds. Reduces collusion risk of one party with arbiter.

Basic Contract Structure

struct Payment {
    address payer;
    address payee;
    uint256 amount;
    address token;          // address(0) for ETH
    uint256 deadline;       // expiration timestamp
    PaymentState state;     // Pending, Released, Refunded, Disputed
    bytes32 conditionHash;  // hash of condition (off-chain document)
}

enum PaymentState { Pending, Released, Refunded, Disputed }

Deadline critical. If condition not fulfilled by deadline, payer must be able to return funds. Without deadline, funds can hang forever.

Typical Use Cases and Specifics

Freelance payment. Condition: contractor confirmation. Arbiter: DAO or multisig. Term: 14-30 days. Feature: need dispute mechanism with evidence storage (IPFS hashes in contract).

DeFi option. Condition: price level reached. Oracle: Chainlink Price Feed. Term: option expiry. Feature: oracle manipulation risk — flash loan can temporarily change price. Solution: TWAP (time-weighted average price) instead of spot price.

Vendor payment with KPI. Condition: on-chain data (TVL, transaction volume). Oracle: The Graph + custom oracle. Term: quarterly. Feature: Graph data not push, pull — contract requests via Chainlink.

Game achievements. Condition: on-chain event in game contract. Verification: direct call from game contract (simplest case — everything on-chain).

Security: What Can Go Wrong

Reentrancy on release. _release() transfers ETH or tokens. If recipient is contract, can call _release() again. Protection: ReentrancyGuard from OpenZeppelin + checks-effects-interactions pattern (change state first, then transfer).

Oracle manipulation. Flash loan attacker for one block manipulates price on DEX → oracle reads changed price → condition fulfilled → funds released. For price conditions — only Chainlink with TWAP, not DEX spot price.

Front-running on fulfill. MEV bot sees fulfillment transaction in mempool and inserts transaction before it. For escrow usually not critical (recipient predetermined), but auction schemes need commit-reveal.

Deadline expiry with valid condition. Condition fulfilled, but transaction confirmation stuck, deadline passed. Need reasonable grace period or off-chain monitoring with alerts.

Timeline

Basic escrow contract with ETH/ERC-20, arbiter and deadline — 2 days with tests. With Chainlink Price Feed integration — +1 day. With Chainlink Functions for arbitrary API — +2 days. Multi-party dispute mechanism with IPFS for evidence — +2 days. Full system with frontend — 3-5 working days overhead.