Dispute Policy.
How Realife handles protected order disagreements: escrow state, seller proof, buyer evidence, service completion, physical delivery, deadlines, refunds, and exceptional manual review.
Why Realife has a dispute policy
Realife is designed for protected stablecoin commerce. Escrow can hold funds, but real-world commerce still needs order evidence, delivery proof, service completion, deadlines, buyer confirmation, seller reputation, and human review for exceptional cases.
This Dispute Policy is an MVP platform policy template. It should be reviewed by qualified counsel and updated before mainnet, paid commerce, high-value orders, or regulated categories.
The smart contract is not the judge
A smart contract can hold funds and execute release or refund paths. It cannot fully judge whether a design was good enough, a physical item was damaged by a carrier, a seller packed correctly, a buyer is acting in bad faith, or a service matched the agreed scope.
Realife uses a structured trust system: order terms, escrow state, seller proof, buyer response, deadlines, messages, account history, policy rules, and manual review when needed.
Clear terms must be locked before an order
The best dispute is the one prevented before payment. Sellers and buyers should make the order terms clear before funds enter escrow.
- For services: scope, deliverables, timeline, revision count, acceptance rules, refund conditions, and proof requirements.
- For physical goods: item description, condition, quantity, location, delivery method, shipping timeline, packaging expectations, tracking, and inspection rules.
- For local/offline services: city/area, appointment time, cancellation rules, proof of completion, safety rules, and supported service boundaries.
How protected order resolution works
Most orders should not need manual review. A normal protected order should move from payment to seller fulfillment, then buyer confirmation, then release of funds.
- Buyer pays and funds enter escrow.
- Seller delivers the product, performs the service, or submits proof of completion.
- Buyer confirms, requests revision, reports a problem, or opens a dispute within the applicable window.
- If there is no valid dispute and the order terms are satisfied, funds may be released according to the order logic.
When a buyer may dispute an order
A buyer may open a dispute when there is a real issue with the order. The buyer must provide clear evidence and explain the problem inside the order flow where possible.
- Product not delivered or tracking does not support delivery.
- Wrong item, missing item, materially different condition, or damaged delivery.
- Service not delivered, incomplete work, missed deadline, or output materially different from agreed scope.
- Seller refuses agreed revisions, disappears, submits fake proof, or violates listing terms.
What sellers should submit
Sellers should submit evidence that matches the type of order. Strong evidence reduces manual review, protects honest sellers, and helps buyers understand what happened.
- Services: files, links, screenshots, work logs, delivered assets, meeting proof, messages, milestone notes, and revision responses.
- Physical goods: product photos, packaging photos, shipping receipt, tracking number, carrier updates, delivery confirmation, and condition proof.
- Local/offline services: appointment proof, completion notes, buyer communication, photos/videos where appropriate and lawful, and agreed outcome evidence.
What buyers should submit
Buyers should submit evidence quickly and clearly. A dispute should explain what was promised, what was received, what is missing, and what outcome the buyer requests.
- Photos or videos of damaged, missing, or incorrect goods immediately after delivery or pickup.
- Screenshots, files, messages, or notes showing that service work does not match the agreed scope.
- Clear requested outcome: revision, replacement, reshipment, partial refund, full refund, or other reasonable resolution.
Online service disputes
Service disputes are often subjective, so Realife focuses on scope versus delivery. If the seller delivered what was clearly agreed, funds may be released even if the buyer simply changed their mind. If the seller did not deliver the agreed scope, a revision, partial release, refund, or other action may be appropriate.
- Quality complaints should be tied to written scope, acceptance rules, examples, milestones, or revision terms.
- A buyer should give the seller a fair chance to submit agreed revisions if revisions were part of the order.
- A seller should not expand scope after payment unless both sides agree to new terms.
Delivery and damaged item disputes
Physical commerce can fail for different reasons: seller fraud, poor packaging, carrier damage, buyer abuse, stolen packages, incorrect address, customs, or local delivery problems. Realife reviews the evidence path, not only one message from either side.
- If seller proof shows correct packaging and carrier damage appears likely, the resolution may involve carrier claim documentation or insurance.
- If seller proof is missing, weak, or inconsistent, a refund, partial refund, reshipment, seller reputation action, or seller bond action may apply.
- If buyer evidence is late, unclear, or inconsistent with tracking/proof, the order may still release to the seller.
Response windows and inactivity
Realife may use deadlines to prevent funds from being locked forever. Buyers and sellers should respond within the order window, upload requested evidence, and keep important communication inside Realife when possible.
- Buyer inactivity after delivery or service submission may lead to release if no valid issue is raised.
- Seller inactivity after a dispute may lead to refund, partial refund, account action, or loss of seller protection.
- Deadlines may differ by category, value, delivery method, seller level, risk score, and mainnet policy.
Possible dispute outcomes
Realife may support different outcomes depending on evidence, policy, order type, and final marketplace terms.
- Release funds to seller.
- Full refund to buyer.
- Partial refund or partial release.
- Revision request, resubmission, replacement, reshipment, or extended deadline.
- Carrier claim escalation, insurance path, seller bond/deposit action, account warning, listing removal, suspension, or ban.
False disputes, fake proof, and fraud
Realife may take action against users who abuse escrow or dispute systems. Trust protection must protect honest buyers and honest sellers, not create a weapon for fraud.
- Buyers must not claim non-delivery when an item arrived or demand refunds after receiving valid work.
- Sellers must not submit fake tracking, fake work, fake proof, misleading photos, or duplicate/counterfeit goods.
- Coordinated fraud, self-dealing, fake accounts, same-IP abuse, wallet cycling, review manipulation, or chargeback-style abuse can lead to account action.
Manual review and trust operations
Realife may use admin review, trusted moderators, AI-assisted summaries, account history, IP/device signals, wallet activity, order timelines, and evidence checklists to prepare or decide dispute outcomes. Human review should be the exception, not the default for every order.
Early mainnet pilots may use founder-led or moderator-assisted review while Realife learns from real order patterns. Over time, repeatable evidence standards, automation, seller reputation, and policy templates should reduce manual load.
Unsupported categories and high-risk orders
Some categories may be prohibited, restricted, require seller verification, require deposits/bonds, require insurance, or be blocked until Realife has the right legal and operational process. High-value or fragile items, regulated goods, local services, and cross-border delivery may require extra rules.
Realife may refuse to mediate disputes for prohibited items, illegal services, off-platform transactions, or orders intentionally moved outside Realife to avoid rules.
Current MVP/testnet limitations
During testnet, dispute features may be simulated, partially manual, or still under development. Testnet transactions, test tokens, demo orders, test NFTs, and test escrow flows are for product testing and do not guarantee mainnet policy, money value, future eligibility, or final dispute behavior.
Before mainnet commerce, Realife should finalize legal terms, jurisdiction rules, supported categories, custody/payment structure, external audits, seller verification, dispute operations, and prohibited-item policy.