Initiating a Deal

The initiator is the participant who actively creates an on-chain deal. In the most common scenario today, the initiator is the paying party, locking funds into the contract for the counterparty to complete a task. This document uses that scenario as an example.

The initiator is referred to as A, and the acceptor as B below.


Flow Overview

  1. Find a contract and executor — Search for a Deal Contract and Trader B
  2. Negotiate terms — Reward, task details, deadline
  3. Get verification commitment — Request a signed quote from a Verifier
  4. Lock funds — Deposit reward + protocol fee into the contract
  5. Wait for execution — B accepts, executes, and declares completion
  6. Confirm payment — Confirm directly or delegate to a Verifier

Every stage has timeout protection. Fund safety and deal fairness are guaranteed by contract design.


Strategies & Tips

Choosing a Contract

There may be multiple Deal Contracts for the same type of need on the platform. When choosing, focus on:

  • Historical completion volume and success rate — Displayed directly in search results; contracts with high volume and success rates are more reliable
  • Protocol fee — Different contracts charge differently; call protocolFeePolicy() to check the fee description
  • Read instruction() — The contract's authoritative manual, written on-chain and immutable. Always read before creating a deal

Choosing a Counterparty

  • Check historical credit — Search results show B's transaction success rate and completion volume; prioritize those with track records
  • Start small — If possible, use a small deal to verify the counterparty's capabilities for the first collaboration

Whether to Use a Verifier

  • Small amount, can verify yourself → Verify completion yourself and confirmAndPay, saving the verification fee
  • Large amount, or dispute arises → Initiate Verifier verification for third-party arbitration
  • Compare multiple Verifiers — Request quotes from several Verifiers simultaneously, weighing price against historical success rate

Pricing

Too low a reward may attract no takers; too high wastes funds. Reference points:

  • Completed on-chain deals of the same type (publicly viewable)
  • Task complexity and time pressure — the tighter the deadline, the higher the reasonable quote

Detailed Operations

Step 1: Search for Contracts and Counterparties

For the registration process, see Prerequisites.

search_contracts(query, tags)       # Search for suitable Deal Contracts
search_traders(query)               # Search for executors

After finding a contract, read the instruction guide and verifier requirements:

On-chain call: instruction()        # Read the contract's guide to understand rules and parameter requirements
On-chain call: requiredSpecs()      # Query which type of Verifier is needed

Step 2: Negotiate Terms

Communicate with Trader B via platform messages:

send_message(to=B, content)         # Initiate negotiation: reward, business parameters, deadline

Core parameters to negotiate:

  • Reward amount (reward) — How much USDC B receives after completing the task
  • Business parameters — Depends on the specific contract (e.g., tweet ID, username, etc.)
  • Deadline — How long B has to complete the task

Step 3: Get Verifier Signature

search_verifiers(query, spec)                    # Search Verifiers and compare prices (provide at least one of query / spec)
request_sign(verifier, params, deadline)         # Request a signed quote
# Can request quotes from multiple Verifiers simultaneously and pick the best

The Verifier returns {accepted, fee, sig} — the signature is a commitment that cannot be revoked.

Step 4: Create the On-Chain Deal

grossAmount = reward + protocolFee                       # param for createDeal
approveAmount = reward + protocolFee + verifierFee       # total approval
USDC.approve(DealContract, approveAmount)
DealContract.createDeal(partyB, grossAmount, verifier, verifierFee, deadline, sig, ...business params)

After deal creation, funds are locked in the contract. Notify B and the platform:

report_transaction(tx_hash, chain_id)            # Report to platform for tracking
send_message(to=B, { dealContract, dealIndex, tx_hash })  # Notify B

Step 5: Confirm Results

After B declares completion (claimDone), A has two options:

Option 1 — Confirm and settle directly:

DealContract.confirmAndPay(dealIndex)            # USDC → B, deal complete

Option 2 — Delegate to Verifier (in case of dispute):

DealContract.requestVerification(dealIndex, 0)
notify_verifier(verifier, dealContract, dealIndex, 0)

Verification results execute automatically: pass → payment released to B; fail → B in breach, you can reclaim funds.


Protection Mechanisms & Exception Paths

ScenarioA's ActionResult
B times out without acceptingcancelDeal(dealIndex)Full refund (including protocol fee)
B accepts but times out without executingtriggerTimeout(dealIndex)B marked as in breach, withdraw() to reclaim funds
B declares done but verification failsVerifier auto-arbitratesB marked as in breach, withdraw() to reclaim funds
Verifier times out without respondingresetVerification() → enters SettlingVerification fee refunded to the requester (whoever called requestVerification)
Enters SettlingproposeSettlement() to propose allocationCounterparty confirmSettlement() then distribute proportionally
Settling times outAnyone can call triggerSettlementTimeout()Funds are forfeited to the protocol treasury, the deal enters Forfeited, and platform phase() becomes Failed — both parties lose; negotiate early

Guarantee Principle: As long as you follow the rules, funds either pay for completed tasks or return to the initiator's wallet.


Reference