Customer-backed development
Demand with commitment.
Delivery with consent.
Customers can reserve funds for an upgrade. An approved release makes acceptance possible; each customer controls whether their own contribution is released.
1. Define and fund the improvement
First create the software commission. Then define a conditional development grant here. This grant does not buy export credits or count against future royalty caps.
Refund conditions & delivery trust
Refunds become available if the merchant cancels, the target is not reached by the funding deadline, or the delivery deadline passes without your acceptance. The contract checks the exact published EarnPatch version and artifact. That check is not a quality verdict: your approval is still required. Merchant/developer collusion cannot release your grant without your signature.
Advanced demo scenarios
2. Offer a token-denominated upgrade
This is a separate settlement contract. TestEPUSD has 6 decimals and is an evaluation test token, not genuine USDC or USDT. Token prices, royalties and caps have independent units.
After publication in the delivery workspace, import the release and accept the new token agreement. Paperlane then checks token-specific credits through Bridge and processes real CSV files.
Every asset, accounted for.
Escrow grants and later sales are separate agreements. Native NEAR backing funds storage; it never substitutes for token inventory.
Your Finance actions & shared setup
This is the Finance action history, not a complete cross-app purchase journal. Customer purchases and consumed uses appear in connected Paperlane Export activity in the connected workspace. The settlement totals above include those sales.
Contract identities and live evidence
This workspace uses isolated sample balances, not your wallet. The separate verified NEAR experience identifies the actual accepted contracts, transactions and asset units.
Inspect original Testnet records →