Dispute Policy

This Dispute Policy explains how Gigston handles disagreements after escrow is funded. Disputes exist so locked funds can be released, refunded, or split (50/50) when parties cannot agree — according to the escrow smart contract and this Policy.

Opening a dispute does not guarantee that any party will receive funds. It locks the escrow into a disputed state and starts a resolution process under this Policy.

Gigston stores deal metadata that may be used when a dispute is handled, including:

• Deal title and description (scope text) entered in Gigston.
• Budget, timeline, participants, and status history.
• On-chain escrow funding and dispute-related transactions.

Gigston does not currently provide in-deal file uploads, milestones, or a dedicated in-deal message inbox. Parties often coordinate in Telegram (including chats opened from the Mini App). Those external chats are not automatically stored as a Gigston deal record.

Write a clear description before funding. If requirements change, update the deal description in Gigston or open a new deal rather than relying only on off-platform messages.

Either party on a funded deal may open a dispute when the deal is in a supported status (typically while work is in progress or after work has been marked submitted). Opening a dispute requires a wallet signature from that party; Gigston’s backend relays the signed open-dispute message to the smart contract. Gigston may reject an open-dispute attempt that does not meet platform status or signature rules. When a valid dispute is opened on-chain, escrow enters a disputed state so funds are not released through the normal release flow until resolution.

After a dispute is opened, Gigston support (or a designated arbiter wallet under the smart-contract rules) contacts the parties and reviews available deal records on Gigston. Possible on-chain outcomes are:

• Release funds to the freelancer.
• Refund funds to the client.
• Split escrow 50/50 between the parties.

Decisions are based on a reasonable assessment of the written deal description, deal status history, on-chain activity, and information the parties provide during the support process. Gigston is not a court of law and does not guarantee a particular commercial outcome.

• Write a clear deal description before funding.
• Keep acceptance criteria in the deal description, not only in Telegram DMs.
• Wait for escrow funding before starting work; mark work submitted in Gigston when ready for review.
• If requirements change materially, update the deal description or open a new deal before relying on them in a dispute.

Gigston provides the Mini App, deal records, and escrow tooling. Escrow balances remain in the smart contract. Gigston’s backend only relays user-signed escrow messages where applicable; it does not take custody of funds. Local consumer or labor rights may still apply independently of this Policy.

Gigston and any arbiter acting under the contract are not representatives, agents, or attorneys for either party and do not provide legal advice or legal services.

Restrictions may apply for false statements, abuse of the dispute system, attempts to manipulate resolution, coercion to release funds outside the agreed deal, or repeatedly opening unsupported disputes. Abuse can affect access to Jobs, deals, or dispute features.

Unless Gigston’s internal rules provide otherwise, once an arbiter resolve transaction is confirmed on-chain, that distribution of escrow funds is final within Gigston. That finality does not limit either party’s right to seek remedies before competent public authorities where applicable law allows.

This Policy works together with the Terms of Service and Privacy Policy. If there is a conflict about how disputes are handled on Gigston, this Dispute Policy controls for that topic.