@Matteo the refund answer is the part I found most interesting, because it runs into the same wall I hit with Signal Vault: a template can prove what was recorded on-chain, not what happened off it.
Two things I would look at in the dispute path:
- The stake caps the recourse. Once the merchant has withdrawn the revenue,
resolve_disputecan only pay the buyer out of the stake, and over-slashing is rejected. So if a single order is larger than the merchant’s bond, a buyer who wins the dispute still cannot be made whole. Capping order value per tier at the stake size, or keeping revenue in the vault until a refund window has passed, would close that gap. - The arbiter is the one trusted piece left.
resolve_disputeanddismiss_disputeare owner-only, so the non-custodial model stops exactly where it matters most. You state it plainly in the README, which I respect. A response deadline written into the contract (the merchant has N epochs to approve or deny, otherwise the refund goes through) would take the arbiter out of the simple cases and keep it for real disagreements.
For Signal Vault I left delivery out on purpose and said so (the idea is here: 50,000 XTM GIVEAWAY ! ... Best idea WINSS). Seeing a second template reach the same trust boundary from the payments side is useful ![]()
Good luck with the contest.