Learn - Basics

How to use DeTrustPay for basic transactions

Off-chain promise, on-chain enforcement. This guide explains the minimum flow and decisions needed to use DeTrustPay safely.

What DeTrustPay is

DeTrust Pay implements transaction logic based on the DeTrust Protocol, designed for transactions where delivery occurs off-chain while settlement is enforced on-chain. By requiring deposits from both parties, the protocol aligns incentives so that successful completion becomes the economically rational outcome.

Non-custodial

You keep wallet control and signing authority.

Deterministic

Final outcomes follow program state rules, not manual judgment.

Verifiable

Settlement artifacts are visible on-chain.

Understand the two roles

Basic success starts with role clarity before funds are locked.

Promising party

Usually the seller or service provider who commits to fulfilling an off-chain promise

  • Define clear, implementable delivery criteria before creating a setup.
  • Lock the required deposits and comply with protocol rules.
  • Over-promising reduces credibility and increases economic risk.
Promised party

Usually the buyer or client who verifies whether the promise has been fulfilled

  • Review setup terms and deposit conditions before accepting.
  • Verify fulfillment objectively against the agreed criteria.
  • Confirm completion or initiate the proposal path in good faith.
Quick mapping: in most commerce flows, promising party = seller, promised party = buyer.

Real-world examples

  • DeTrustPay is useful when off-chain delivery is hard to track in real time and both sides need credible enforcement.
  • DeTrustPay makes promises from both sides credible to the counterparty through consistent economic incentives.

Freelance delivery

Promising party: Freelancer (seller)

Promised party: Client (buyer)

Off-chain deliverables such as design files or code handoffs are difficult to assess objectively.

DeTrust Pay bridges the gap by aligning incentives so that both the freelancer’s delivery and the client’s payment are economically credible.

Physical product transaction

Promising party: Merchant (seller)

Promised party: Customer (buyer)

Shipping and condition verification occur off-chain, making responsibility difficult to determine in the event of a dispute.

DeTrust Pay bridges delivery and payment by making it economically rational for the seller to deliver as promised and for the buyer to confirm receipt.

Milestone-based services

Promising party: Agency (seller)

Promised party: Company (buyer)

Partial completion and timeline delays are difficult to evaluate under binary trust assumptions.

DeTrust Pay bridges milestones by creating symmetric incentives for both the agency and the company to accept partial completion as agreed.

Game-theoretic foundation of DeTrust Protocol

DeTrust Protocol applies mechanism design to off-chain commerce by restructuring incentives before the transaction starts. The goal is not to assume honesty, but to make honest completion the rational strategy.

1. The trust problem as a game
  • Most off-chain commerce starts as a two-player sequential game: seller chooses delivery, buyer chooses confirmation.
  • Traditional systems make betrayal conditionally profitable and punishment probabilistic.
  • Trust and reputation become implicit subsidies for counterparty risk.
2. Why reputation and arbitration underperform
  • Reputation and arbitration adjust payoffs after the game, not before the first move.
  • Enforcement delay and uncertainty discount penalties, especially in one-off and cross-border transactions.
  • Rational actors react by adding friction: higher pricing, more collateral, or refusing to transact.
3. Incentive redesign with DeTrust Protocol(enhanced dual-deposit escrow, eDDE)
  • Both parties pre-commit with symmetric deposits on-chain.
  • Settlement is deterministic and role-constrained under protocol rules.
  • Defection produces guaranteed loss under the defined state machine.
Seller actionBuyer actionProtocol resultStrategic outcome
DeliverConfirmTransaction completes; deposits return per settlement rules.Cooperation path with no forced loss event.
DeliverRefusePenalty path; deposits are impacted by protocol logic.Refusal is economically costly.
FailConfirmProtocol-inconsistent path leads to loss-bearing outcome.Dishonest completion is unprofitable.
FailRefuseNon-completion path incurs loss-bearing outcome.Defection dominates loss, not gain.

Trust-based systems

  • Monitoring and verification costs increase with scale.
  • Enforcement lag widens across jurisdictions.
  • Reputation quality fragments across platforms and identities.

DeTrust Protocol

  • Rules remain constant for every transaction size.
  • Enforcement is automatic and deterministic.
  • Marginal enforcement cost trends toward zero.
Investor-ready summary

DeTrustPay restructures transaction payoffs so that honest completion is the rational strategy, reducing or removing dependency on trust, arbitration, and reputation.

Basic flow in three steps

Step 1

Set terms

Both parties agree on amount, deposits, and measurable off-chain fulfillment criteria.

Do not continue until terms are explicit and measurable.

Step 2

Check fulfillment

Promised party checks whether delivery satisfies the agreed off-chain promise.

Act on evidence, not pressure.

Step 3

Settle on-chain

Program rules settle balances based on verified state transitions.

Review final state and keep transaction references.

Next steps

Use the app when ready. For edge cases, review policy and risk pages before committing larger value.