PayNode Docs
Fair escrow for both sides

Trust the rules, not the other person.

PayNode protects the client when work is not delivered and protects the builder when delivered work is ignored.

Clients lock the agreed payment in a smart contract. Builders submit their work through the platform. Clear deadlines, review periods, refunds, revisions, and settlement rules keep either side from holding complete control.

See How Escrow WorksLaunch App
Step 01Create Project
→
Step 02Lock Payment
→
Step 03Deliver Work
→
Step 047-Day Review
→
Step 05Approve or Claim

What PayNode solves

Online work creates risk for both sides.

A builder may finish the work and never get paid. A client may fund a project and receive nothing. PayNode replaces open-ended trust with clear rules that both sides can understand before the project begins.

For Clients

No delivery means a refund path.

If the project deadline passes and the builder has not submitted any work, the client becomes eligible to recover the locked payment.

For Builders

Delivered work cannot be ignored forever.

After delivery, the client has 7 days to respond. If no action is taken, the builder becomes eligible to claim the escrowed payment.

Balanced by design

PayNode does not give complete control to either side.

The builder cannot receive payment without delivering the work, and the client cannot keep a completed delivery unpaid forever.

Before delivery

The project deadline protects the client.

The builder must submit work before the agreed project deadline.

After delivery

The 7-day review period protects the builder.

The client must approve, request a revision, or raise a dispute within 7 days.

During revision

The payment stays locked.

Revised work starts a fresh 7-day review period.

The core of PayNode

How the escrow handles real project scenarios

These four rules are the foundation of the contract and explain how PayNode protects both participants.

Scenario 01Protects the Client

The project deadline passes with no delivery

If the builder does not submit any work before the project deadline, the client becomes eligible to refund the locked payment from the smart contract.

Result: the client can recover the escrowed funds.

Scenario 02Protects the Builder

The client does not respond after delivery

When the builder submits the work, a separate 7-day review period begins. During those 7 days, the client can approve, request a revision, or raise a dispute.

Result: if the client takes no action before the review period ends, the builder becomes eligible to claim the escrowed USDC directly from the smart contract.

Scenario 03Protects Quality

The client requests a revision

A revision request closes the current review period. The payment remains securely locked while the builder works on the requested changes.

Result: no payment is released while the project is in revision.

Scenario 04Protects Both Sides

The builder submits revised work

After the builder submits the updated delivery, a new 7-day review period begins for the revised work.

Result: the client receives a fresh review window, while the builder is protected from an endless unpaid review cycle.

Two different clocks

Project deadline and review period are not the same.

The project deadline applies before delivery. The 7-day review period applies only after the builder submits work.

Project deadline

Before the first delivery

This is the agreed amount of time the builder has to submit the project. It can be 5 days, 10 days, or another duration selected for that project.

No delivery by this deadline → the client can refund.

7-day review period

After each delivery

Once work is submitted, the client receives exactly 7 days to approve it, request a revision, or raise a dispute.

No response within 7 days → the builder can claim.

One link for builders

A PayNode profile is more than a portfolio.

It brings skills, completed projects, client ratings, social links, and wallet-based payments together in one shareable professional identity.

✓

Share one profile on X, Discord, Telegram, LinkedIn, GitHub, or a personal website.

✓

Receive project invitations through the same public link.

✓

Accept USDC tips from people who want to support your work.

✓

Build visible reputation through completed projects and ratings.

PayNode builder profile
A shareable PayNode profile combining skills, social links, project history, ratings, project requests, and USDC tips.

Product walkthrough

A simple project flow

The user-facing process stays simple, while the contract applies the rules in the background.

1

Create the agreement

The client defines the project, budget, project deadline, delivery expectations, and revision limit. The payment is priced in USDC.

Creating a PayNode project
The client defines the project terms, budget, deadline, and revision rules.
2

Lock the payment in escrow

The client funds the smart contract before work begins. The builder can see that the agreed payment is secured.

Funding a PayNode escrow project
The agreed payment is locked before the builder starts working.
3

Submit the work

The builder submits delivery notes and links to the final work. This action begins the 7-day review period.

Submitting work through PayNode
Submitting a delivery starts the client's 7-day review period.
4

Approve, revise, dispute, or wait

The client can approve the work, request a revision, or raise a dispute. If the client does nothing for 7 days, the builder becomes eligible to claim the payment.

PayNode project review and payment
Approval releases payment. No response for 7 days enables the builder's claim path.

Builder reputation

Successful work becomes public credibility.

Every completed project and client rating can strengthen the builder's profile and help future clients make a more confident hiring decision.

A strong profile creates long-term value.

High ratings and successful project history act as visible proof of reliability. Builders can keep sharing the same link as their reputation grows.

More trust before a new project
A visible history of completed work
One link for projects and tips
Reputation that grows over time
PayNode builder rating
Client ratings and completed projects strengthen the builder's public reputation.

Dispute resolution

A dispute pauses the clock. It never freezes the funds.

Raising a dispute moves the project to Disputed and suspends the review period. From there, funds leave escrow through one of three resolution paths, or, if nobody acts for 30 days, through a permissionless circuit breaker. The contract has no reachable state that holds funds indefinitely.

Client

Can dispute only after a delivery.

The client may call raiseDispute only while the project is Delivered. A stale dispute over undelivered work refunds the client in full, so allowing earlier disputes would let a client freeze a builder on day one and reclaim the escrow while work was still in progress.

Builder

Can dispute at any funded stage.

From Funded, InRevision, or Delivered. This lets a builder put an unresponsive client in front of an adjudicator and be awarded partial payment for work performed. It cannot be abused, because every pre-delivery stale outcome favours the client.

ResolutionContract functionDisputeResolved.resolutionPath
Path C · Named arbitratorresolveDispute0
Path A · AI resolverresolveDisputeWithAttestation1
Path B · Mutual settlementacceptSettlement2
Stale-dispute breakerforceResolveStaleDispute3

Every path settles through the same internal function. The builder's share is paid net of the protocol fee snapshotted when the project was funded, the remainder is refunded to the client with no fee, and any pending settlement offer is cleared. A project that settles reaches a terminal status and can never be disputed or resolved again.

Three ways out

The three dispute resolution paths

Which paths are open is a property of the project, fixed before any dispute exists. Path A and Path C are mutually exclusive: every project has exactly one adjudicator. Path B is open on every project.

ADefault

Path A: Autonomous AI Resolver

Contract path 2 · resolveDisputeWithAttestation

Gemini reads the brief, every deliverable on record, the verified on-chain timeline, and both parties' statements, then divides the escrow anywhere from 0% to 100% to the builder. The ruling is signed as an EIP-712 attestation and executed on-chain.

Applies when
No arbitrator was named at creation, and the resolver epoch snapshotted at funding has a non-zero signing key.
Who starts it
Either party, once both have filed a statement or the 72-hour evidence window has passed.
How binding
One ruling per project, final, with no appeal. Anyone can relay the signed ruling to the contract.
BAlways available

Path B: Mutual Direct Settlement

Contract path 3 · proposeSettlement / acceptSettlement

One party proposes a percentage split on-chain and the other accepts it. No arbitrator, no AI, no waiting period. The escrow pays out in the same transaction as the acceptance.

Applies when
Any funded stage (Funded, InRevision, Delivered, or Disputed), on every project.
Who starts it
Either party, at any time until the escrow settles by any path, including while a ruling is being prepared.
How binding
Needs both parties. An offer binds nobody until it is accepted and can be withdrawn until then.
COptional

Path C: Named Arbitrator

Contract path 1 · resolveDispute

A third-party wallet, designated by the client when the project is created, reads the case and rules: release to the builder, refund the client, or any split between the two.

Applies when
An arbitrator address was passed to createProject. It cannot be added, changed, or removed later.
Who starts it
Only the arbitrator. Neither party can trigger or hurry a ruling.
How binding
Pays out as soon as the arbitrator submits it. Cannot be revised or appealed.

Mutual settlement mechanics

  • proposeSettlement(projectId, builderBps) records an offer. A new proposal overwrites the previous one.
  • withdrawSettlement(projectId) retracts it. Only the proposer can withdraw.
  • acceptSettlement(projectId, builderBps) must be called by the counterparty and must restate the exact split. If the proposer changed the terms in the meantime, the acceptance reverts with SettlementMismatch instead of binding the accepter to terms they never saw.

Choosing an adjudicator

  • Path A is the default: the project creation form passes the zero address as the arbitrator.
  • A named arbitrator cannot be the client or the builder, and is permanent for the life of the project.
  • The client chooses the arbitrator on their own. A builder who does not accept that choice can call builderCancel at any funded stage to return 100% to the client, so builders should check the arbitrator before starting work.

Path A · Gemini engine

Autonomous AI dispute resolution

Disputes on the default path are adjudicated by Google Gemini (gemini-3.5-flash) against a frozen, versioned rubric, with a JSON-Schema-constrained response. The resolver never moves funds itself: it produces a signed ruling that the contract verifies and executes.

  1. 1

    Request

    A party calls POST /api/dispute/request-resolution with their SIWE session. The route admits only the project's client or builder, and enforces the evidence window. Operators and cron jobs use POST /api/dispute/resolve, authenticated with a server-side secret that never reaches a browser.

  2. 2

    Chain preflight

    Before any model call, the resolver reads the contract: the project must exist, be Disputed, have no designated arbitrator, and have a non-zero key for its resolver epoch that matches the key this service signs with. Eligibility is never decided from the database.

  3. 3

    Claim the ruling slot

    A pending row is inserted into the ruling ledger, keyed uniquely on the on-chain project id. Of two concurrent requests, exactly one wins the insert. The loser, and every later request, is served the winner's result.

  4. 4

    Assemble the case file

    Verified on-chain facts, the agreed scope, the builder's submissions, and each party's statements are rendered in a fixed order inside fenced sections. The client's section always comes first, regardless of who raised the dispute.

  5. 5

    Adjudicate

    Gemini evaluates the case under a frozen rubric supplied as the system instruction, and returns a schema-constrained JSON ruling.

  6. 6

    Validate and sign

    builderBps is re-checked to be an integer in 0–10,000. Out-of-range values are rejected, never clamped. The ruling is signed as an EIP-712 attestation and checked against the contract's own digest before it is stored.

  7. 7

    Store, notify, relay

    The ruling, reasoning, full evidence analysis, signature, model version, and token usage are written to the ledger. Both parties are notified, and either of them (or anyone else) submits the attestation on-chain.

Adjudication standard

The resolver rules on the balance of probabilities, against the agreed scope, weighing in order:

  1. Delivery against scope
  2. The verified on-chain timeline, which overrides any conflicting statement
  3. Burden of proof: the builder evidences delivery, the client evidences deficiency
  4. Scope discipline: requirements first raised in the dispute are not part of the agreement
  5. Good faith

Splits are rounded to the nearest 250 bps (2.5%) unless the evidence justifies a specific figure. A party who files no statement does not automatically lose.

Generation settings

model
gemini-3.5-flash (pinned version, never an alias)
systemInstruction
frozen rubric, no interpolated values
temperature
0
seed
fixed
thinkingLevel
high
responseMimeType
application/json
responseJsonSchema
strict ruling schema
maxOutputTokens
16,000
Ruling schema (abridged) · additionalProperties: false, all fields required
{
  "evidenceAnalysis": [
    {
      "source": "agreed_scope" | "verified_facts" | "builder_submissions"
              | "client_statement" | "builder_statement",
      "finding": string,
      "weighsToward": "client" | "builder" | "neither",
      "weight": "decisive" | "strong" | "moderate" | "slight"
    }
  ],
  "reasoning": string,             // 4–8 sentences, shown to both parties
  "manipulationDetected": boolean,
  "confidence": "low" | "medium" | "high",
  "builderBps": integer            // 0–10000, emitted last
}

On determinism

The output shape is fully deterministic: the schema constrains every field. The verdict itself is pinned as far as the provider allows (temperature 0, fixed seed, fixed evidence order), but identical inputs can still diverge occasionally across a serving fleet. The guarantee PayNode relies on is structural instead: one ruling per project, ever. Run-to-run variance cannot be exploited when no party can request a second run. The builderBps field is emitted last so the split is a conclusion drawn from the analysis above it, not a number the reasoning is written to justify.

OutcomeMeaning
signedAttestation issued and stored. Every later request replays this exact signature.
pendingAnother request is mid-arbitration. The caller receives HTTP 202 and polls.
failedThe model refused to rule (safety block or refusal finish reason). Terminal for Path A. Path B and the 30-day breaker remain open.
ineligibleA preflight gate refused: not disputed, arbitrator assigned, resolver disabled, or epoch mismatch. Not persisted, so the project's ruling slot is not consumed.
transient errorRPC failure, rate limit, or a ruling truncated at the output budget. The claim is released and the request can be retried.

Cryptographic flow

From AI evaluation to on-chain execution

A ruling becomes enforceable only as an EIP-712 structured signature from the resolver key that governs the project's epoch. The contract verifies that signature itself. It does not trust the API, the database, or the party who submits it.

AI evaluationGemini returns builderBps
→
EIP-712 attestationResolver key signs the ruling
→
On-chain executionresolveDisputeWithAttestation
EIP-712 typed data
domain: {
  name: "PayNodeEscrow",
  version: "2",
  chainId,              // Arc network chain id
  verifyingContract     // PayNodeEscrowV2 address
}

Resolution(
  uint256 projectId,    // on-chain project id
  uint16  builderBps,   // 0–10000
  uint256 deadline      // unix seconds; signing time + 7 days
)
Execution · callable by any address
function resolveDisputeWithAttestation(
  uint256 projectId,
  uint16  builderBps,
  uint256 deadline,
  bytes   calldata signature
) external;

// Helper views
resolutionDigest(projectId, builderBps, deadline) → bytes32
resolverFor(projectId) → address  // key for the project's epoch

Before the signature is issued

  1. builderBps is re-validated as an integer in 0–10,000. Out-of-range values are rejected, never clamped.
  2. The signature is recovered locally and must match the resolver address.
  3. The locally computed digest must equal the contract's resolutionDigest. This catches a wrong chain id or contract address before a party is handed an attestation that would revert.

What the contract checks

  • No designated arbitrator → ArbitratorAssigned
  • block.timestamp is not past the deadline → AttestationExpired
  • builderBps is at most 10,000 → BpsTooHigh
  • Project is Disputed → BadState
  • The project's epoch has a key → ResolverDisabled
  • Signature recovers to resolverAt[p.resolverEpoch] → BadAttestation

Replay-proof by construction

Settlement moves the project to a terminal status that can never return to Disputed, so a project can be resolved at most once. No nonce is needed.

Gasless for the parties

The attestation can be relayed by any address, so neither party needs the resolver to hold gas. The resolver key never transacts and holds no balance.

Bounded lifetime

The signed deadline gives a ruling 7 days to be submitted. An expired ruling is not re-issued. The dispute continues through Path B or the 30-day breaker.

Security model

Built for adversarial evidence.

Both parties write text that the model reads, and both have a financial incentive to influence the ruling. The resolver assumes every statement may contain an attack and is designed so that none can change who wins.

Prompt injection defense

  • The adjudication rubric is sent as Gemini's system instruction, a separate channel from the party-written case file. It is never concatenated with evidence.
  • Every party-supplied string is placed inside a named section (agreed_scope, builder_submissions, client_statement, builder_statement). The rubric declares those sections to be evidence with no authority over the ruling.
  • Text that tries to instruct the resolver, claim to come from PayNode, or dictate an outcome is treated as a manipulation attempt. It is flagged (manipulationDetected) and weighed against that party under the good-faith criterion.

Evidence sanitization

  • < and > in party text are escaped before rendering, so a statement cannot close its section early and forge a new one.
  • Links must be http(s), with at most 10 per submission and 2,048 characters each. The resolver never opens links. A URL is treated as a claim that something exists at that address, not as proof of delivery.
  • Facts about money, deadlines, revisions, and status come from the contract, not the database. When a statement contradicts them, the chain wins.

Token budgeting

  • Each free-text field is capped at 20,000 characters, both in the submission form and when the case file is rendered, so one party cannot bury the other's argument or overflow the context window.
  • Output is budgeted at 16,000 tokens, covering high-level thinking, the evidence analysis, and the reasoning. A ruling truncated at that limit is rejected rather than signed.
  • Input, output, and thinking tokens are recorded with every ruling for provenance and cost auditing.

Verdict manipulation resistance

  • One ruling per project, ever. The ledger's unique key is claimed before the model is called, so re-requesting returns the original signature byte for byte. A ruling cannot be re-rolled.
  • Parties cannot write to the ruling ledger, and a pending ruling is hidden from them by row-level security, so it gives no signal to tamper with evidence mid-arbitration.
  • The 72-hour evidence window prevents the first party to file from having the case decided before the other side has answered.
  • Temperature 0, a fixed seed, and a fixed evidence order minimize run-to-run variance. Because a ruling cannot be re-rolled, any variance that remains cannot be exploited.

Signing key hygiene

  • The resolver key only signs. It never sends transactions and holds no balance, so a relayer, not the resolver, pays gas.
  • Deployments pin the expected signer address and refuse to start on a mismatched key.
  • Every signature is checked against the contract's resolutionDigest view before it is issued, which catches chain-id or contract-address drift before a party receives an attestation that would revert.

Safety filters without dead ends

  • Disputes often quote hostile language as evidence, so Gemini's safety thresholds are set to BLOCK_ONLY_HIGH rather than the default. That is one notch looser than the default, and never off.
  • A genuine refusal is recorded as a terminal failed ruling instead of being retried. The dispute then proceeds through mutual settlement or the 30-day breaker.

Timelocks, lifecycles & fallback breakers

Every clock that governs a dispute

Several of these are 7 days long but control different things. Durations marked on-chain are bytecode constants that no owner can change.

Review period

7 days

On-chain · REVIEW_PERIOD

Starts at each delivery. If the client does not approve, request a revision, or dispute before it ends, the builder can claim the escrow.

Revision grace

7 days

On-chain · REVISION_GRACE

Each revision request extends the delivery deadline to at least 7 days from now, so asking for more work always grants time to do it.

Evidence window

72 hours

Off-chain · resolver API

Minimum time after a dispute is raised before an AI ruling can be requested, unless both parties have already filed a statement.

Attestation validity

7 days

Signed deadline field

A signed ruling must be submitted before its deadline or the contract rejects it with AttestationExpired.

Resolver timelock

7 days

On-chain · RESOLVER_TIMELOCK

Mandatory public notice between announcing and applying a resolver signing-key rotation.

Dispute timeout

30 days

On-chain · DISPUTE_TIMEOUT

After this, anyone can settle the dispute with forceResolveStaleDispute on the contract's fixed terms.

Resolver key rotation and epoch snapshots

The AI resolver's signing key is versioned by resolverEpoch. Rotating it is a two-step, publicly announced process, and a rotation never reaches back into escrow that is already locked.

Rotation · owner only
initiateResolverUpdate(newSigner)
  → emits ResolverUpdateInitiated(newSigner, eta)   // eta = now + 7 days
  → calling again replaces the pending key and restarts the clock
  → cancelResolverUpdate() abandons it

applyResolverUpdate()                                // reverts ResolverTimelockActive before eta
  → resolverEpoch += 1
  → resolverAt[resolverEpoch] = newSigner
  → emits ResolverUpdated(newEpoch, oldSigner, newSigner)

fundProject(projectId)
  → p.resolverEpoch = resolverEpoch                  // snapshotted at funding

Why snapshot, not just timelock

A client whose project is mid-dispute cannot unilaterally exit during a 7-day notice window, so the notice alone would not protect them. Pinning each project to the key that was live when the client funded it means already-locked escrow is always settled by the key the client agreed to.

Disabling Path A

Rotating to the zero address retires the AI resolver for projects funded afterwards. A project whose epoch has no key simply has Path A closed; Path B and the 30-day breaker are unaffected. Check a specific project with resolverFor(projectId).

30-day stale dispute circuit breaker

forceResolveStaleDispute(projectId) needs no arbitrator, no resolver key, no owner, and no cooperation from either party. Once 30 days have passed since the dispute was raised, any address, including a keeper bot, can call it. Read the unlock time with staleResolvableAt(projectId).

Work was delivered

50 / 50 split

If the project was Deliveredwhen the dispute was raised, the builder receives 5,000 bps (net of the project's fee) and the client is refunded the rest.

No work on record

100% refund to client

If the dispute was raised from Funded or InRevision, the whole escrow returns to the client.

“Delivered” means the on-chain status captured by raiseDispute (preDispute), which is set only by markDelivered. Deliverable records in the database do not affect this outcome. Pausing the contract does not block the breaker: a pause affects only new projects and new funding.

Claim Center

Evidence and the deliverable lifecycle

Deliverables and dispute statements are evidence, not state. Only contract calls move a project. The evidence record is append-only, so what the resolver reads is exactly what each party put on the record, when they put it there.

  1. 1

    Record the deliverable

    The builder submits a title, a description, and up to 10 artifact links. The row is written before the on-chain transaction, so the chain can never say Delivered with nothing behind it.

  2. 2

    Mark delivered on-chain

    The builder calls markDelivered, which starts the 7-day review period. It reverts once the delivery deadline has passed. Retrying after a rejected wallet prompt reuses the recorded row instead of creating a duplicate.

  3. 3

    Revise

    A client revision request increments revisionsUsed on-chain. The builder's next submission is recorded with revision_index equal to that on-chain counter, so the database cannot disagree with the contract's timeline.

  4. 4

    Evidence in a dispute

    Every submission, in every revision round, appears in the resolver's case file in chronological order. Earlier rounds are never replaced.

The 72-hour evidence window

After a dispute is raised, both parties file statements in the Claim Center, each up to 20,000 characters with up to 10 supporting links. An AI ruling can be requested once both parties have filed or 72 hours have passed since the dispute was raised, whichever comes first. Until then, a request returns too_early with the remaining time.

The window is measured against block time, the same clock the contract uses, and is enforced by the server rather than the browser. It is a minimum wait, not a cutoff: parties can keep filing until a ruling is issued.

Immutability of the record

  • Row-level security grants parties insert access only. There is no update or delete policy, so filed statements and deliverables cannot be edited or withdrawn.
  • Timestamps are set by the database. Parties cannot write created_at, so nothing can be backdated.
  • Only the builder can record deliverables, and each statement's role must match the author's side. A client cannot file as the builder.
  • Evidence is visible to the client, the builder, and any designated arbitrator. It is visible to the other party as soon as it is filed.

Security rules

Simple rules users can understand before they connect a wallet.

The most important protections are visible and predictable. Users do not need to understand contract code to understand their rights.

✓

The builder cannot receive the project payment before submitting work.

✓

The client cannot keep a completed delivery unpaid forever.

✓

The client can refund after the project deadline if no delivery exists.

✓

The payment remains locked while a revision is active.

✓

Every revised delivery starts a new 7-day review period.

✓

Project payments, refunds, settlements, and tips use USDC only.

✓

Every dispute ends: after 30 days, anyone can trigger the contract's fixed settlement.

✓

The platform owner cannot resolve disputes, move escrowed funds, or change a funded project's resolver.

PayNode will never ask for a seed phrase or private key.

Review every wallet request before signing and use only the official PayNode application.

Built on Arc Network

Programmable rules make the escrow predictable.

PayNode uses Arc Network to turn deadlines, review periods, revisions, refunds, and settlement into transparent smart contract rules instead of private platform decisions.

View Contract & Architecture on GitHubLaunch PayNode

Questions

Frequently asked questions

The essential rules to understand before starting a project.

What is the difference between the project deadline and the 7-day review period?+

The project deadline is the time the builder has to submit the initial delivery. The 7-day review period starts only after a delivery is submitted and gives the client time to approve, request a revision, or raise a dispute.

What happens if the builder misses the project deadline?+

If no delivery has been submitted before the project deadline, the client becomes eligible to refund the locked payment from the smart contract.

What happens if the client ignores a submitted delivery?+

The client has 7 days to respond. After that review period expires, the builder becomes eligible to claim the escrowed USDC directly from the smart contract.

What happens when a revision is requested?+

The current review period closes and the payment remains locked. When the builder submits the revised work, a new 7-day review period begins.

Can the builder receive payment without delivering work?+

No. The escrow rules require a delivery before the normal approval or review-expiry settlement path can be used.

Can the client keep the payment locked forever after delivery?+

No. The 7-day review period prevents an inactive client from holding the builder's payment indefinitely.

Who decides a dispute on my project?+

It is fixed before the dispute exists. If the client named an arbitrator when creating the project, that wallet decides. Otherwise the autonomous AI resolver decides, provided a resolver key was active when the project was funded. In every case, both parties can settle directly by mutual agreement at any time.

Can I appeal or re-request an AI ruling?+

No. Each project receives exactly one ruling. Requesting again returns the same signed ruling, and the contract accepts it only once. If you both prefer a different outcome, you can still agree a split through mutual settlement before the ruling is executed on-chain.

What if the AI resolver declines to rule, or nobody submits the ruling?+

A refusal is final for the AI path, and an unsubmitted ruling expires 7 days after it is signed. Either way, the dispute stays open to mutual settlement, and after 30 days anyone can trigger the contract's fixed outcome: 50/50 if the work had been delivered, or a full refund to the client if it had not.

Can PayNode change the outcome of a dispute?+

No. The platform owner has no dispute or fund-moving powers in the contract. The owner can rotate the AI resolver's signing key only after a public 7-day timelock, and a rotation applies only to projects funded after it takes effect.

Which payment asset does PayNode support?+

PayNode uses USDC for project escrow, settlement, refunds, and tips. Native network tokens and other ERC-20 tokens are not supported for these payments.

Where can developers find the technical implementation?+

The public GitHub repository contains the contract code, application architecture, implementation details, and development history.

One link. Fair rules. Secure payment.

Build your reputation, receive tips, start protected projects, and get paid through a balanced escrow workflow.

Launch AppTechnical Details