Anyone who has read a few escrow pitches knows the pattern: a diagram with three arrows, the word "trustless" in bold, and no mention of what happens when one of the parties behaves badly. This post is the opposite. It walks through the objections a careful client, contractor, or engineer raises within five minutes of hearing about Pyris Pact, and answers each one with what PyrisPact.sol actually enforces. Where the answer is "it does not solve that", we say so.
"The client can just never release the money." Correct, and the contract is built so that this hurts the client as much as the contractor. Once a contractor has submitted work before the deadline, the Pact is in SUBMITTED and the client's refund path is closed: refund by the client is only allowed while the Pact is still FUNDED and the deadline has passed. A client who refuses to release does not get their money back; the funds stay locked until they either release, agree a split, or an arbiter rules. A client who wants to hurt a contractor by withholding payment has to burn their own capital indefinitely to do it. Nothing in the contract lets the client claw back a submitted milestone unilaterally.
"Then the contractor can submit garbage one minute before the deadline to block the refund." Also correct, and this is why the dispute path exists. Submission blocks the deadline refund by design, because a client should not be able to refund out from under a real delivery. If the submission is not what was agreed, the client calls dispute, which moves the Pact to DISPUTED and freezes both the release and the refund. From there the only exits are a split both parties propose with the same number, or a ruling by an arbiter if one was named. A contractor who submits junk does not get paid; they get a dispute, and the funds do not move to either side without agreement.
"What if both sides dig in during a dispute?" Then the funds stay locked, and that is the honest limit of a two-party contract. Pyris Pact offers one mitigation: an optional arbiter address, set by the client at creation, which cannot be the client or the contractor. If an arbiter is named, that address alone can settle a DISPUTED Pact by assigning a share to each side, in basis points from zero to ten thousand. If no arbiter is named, the only resolution is mutual: one party proposes a split, the other accepts by proposing the identical split, and the contract pays out immediately. Our recommendation is plain. For any amount you could not afford to have frozen, name an arbiter you both trust before funding.
"So Pyris is the arbiter." No. The Pyris team holds no role in the contract. There is no owner, no admin key, no pause function, no upgrade proxy, and no fee recipient. The arbiter, when there is one, is whoever the client chose for that specific Pact, and it is visible in the Pact struct onchain. If you want a law firm, a mutual friend, or a DAO multisig as arbiter, that is your call. If you leave it empty, nobody, including us, can touch the funds.
"Can the developers drain the contract?" There is no function that moves value except the five state transitions plus withdraw, and every one of them checks the caller against the client, vendor, or arbiter recorded in that Pact. The contract has no receive function, so stray transfers cannot land in it and become unaccounted balance. The bytecode is immutable; the only way to change behaviour is to deploy a new contract at a new address, which the frontend would have to be repointed to, publicly. Verify this yourself on the Arc explorer rather than trusting this paragraph.
"Is it audited?" Not by a third party yet. The contract ships with a Foundry test suite covering every state transition and access check, a reentrancy guard on every value-moving function, bounded string inputs, and the late-submission and failed-payout hardening described below. That is not the same as an independent audit. Treat Pyris Pact as beta software, size your first Pacts accordingly, and do not put an amount into it that a bug would make catastrophic. We will publish an audit when one exists, not before.
"Zero fees is not a business model." It is not, and we are not pretending otherwise. The deployed contract has no fee parameter of any kind, which means a fee cannot be added by flipping a switch; it would require a new deployment that you would see. The intent is to prove that trustless settlement works for real B2B work first. If a commercial layer comes, it will sit beside the contract, in services people opt into, not inside the escrow itself.
"Arc is a young chain." True. Arc is Circle's Layer 1 for stablecoin settlement, USDC is the native gas asset, and the chain is new. Chain risk is real and it is your counterparty as much as we are. What Pyris Pact does not add on top of that is any bridge, oracle, price feed, or external dependency. The contract reads nothing but its own storage and the block timestamp. If Arc produces blocks, Pyris Pact works.
"Why not just use Escrow.com or Upwork?" Because they sell things Pyris Pact deliberately does not: identity verification, chargeback handling, human mediation as a service, and a legal entity you can sue. If you need those, use them and pay for them. Pyris Pact is for two parties who already know who they are dealing with and have agreed on scope, but neither of whom wants to prepay or deliver first. It replaces the "who holds the money" problem, not the "who do I trust" problem.
"What if I type the wrong contractor address?" The funds are locked to that address. Only the recorded vendor can cancel and return them, and only the client can release. If the address is a stranger's, you are relying on that stranger to call refund. This is the same finality every onchain transfer has. Confirm the address with the contractor over a channel you trust before funding, and start with a small Pact if it is a new relationship.
"What if the contractor's wallet is a smart contract that rejects payment?" Payouts that fail are credited to a pending balance the recipient can withdraw later, instead of reverting. No counterparty can block a release or a refund by refusing to receive it.
"Everything is public." Yes. The title, description, submission note, amounts, addresses, and timestamps of every Pact are readable by anyone. Put a scope summary and a link to the deliverable in the Pact, and keep confidential material in your actual agreement and your actual repository.
"Is this a legally binding contract?" No. It is a settlement mechanism. Have a normal written agreement that references the Pact ID and says what the deliverable is. The onchain record then becomes evidence of funding, submission, and payment, which is more than a bank transfer gives you, but it is not a substitute for terms.
"Can I change the amount or split a job into phases?" The amount is fixed at creation. A client can extend a deadline while the Pact is FUNDED, but never shorten it. For phased work, create one Pact per milestone; that is what the word means.
If a question of yours is not here, it is either in the docs, or it is a hole we have not thought of, in which case we want to hear it at support@pyris.tech. The value of an escrow is exactly equal to the honesty of its edge cases.