Web3

Procurement Controls for On-Chain Freelance Spending

Map purchase orders, approvals, and three-way match onto funded USDC milestones, see the evidence internal audit needs, and request a compliance brief.

SEP 11, 2026

Share Post Share

TL;DR

A funded USDC milestone is a purchase-order equivalent for encumbrance and for the matchable reference, but it carries no scope.
A multisig threshold is one integer, so a value-banded delegation matrix does not map onto it one to one.
The chain evidences authorisation and settlement, not receipt, so the third leg of the match becomes the buyer's own control.
Vendor assurance shrinks with the assertion surface: less to rely on, more to test yourself.

Most of a procure-to-pay control set survives a move to on-chain contractor spend. Encumbrance, approval authority, the payment record and the audit trail all have on-chain analogues, and two get stronger. Segregation of duties weakens. Receipt of deliverable disappears unless the buyer rebuilds it off-chain.

The stakes are not the payment rail. They are control ownership. When no authorised intermediary sits between buyer and contractor, line items a bank once carried move onto the buyer's register.

What does a purchase order become when the PO is a funded escrow milestone?

A funded milestone does 2 of the 3 jobs a purchase order does. It encumbers budget natively, because the USDC is locked before work starts, and the transaction hash is the matchable reference. Scope is the job it does not do. Work on authority separation notes that a chain records portable settlement evidence while service delivery stays off-chain.

The commitment moves from a promise to a locked balance

A purchase order encumbers budget by convention: finance treats the commitment as spent. A funded milestone encumbers by mechanism, since the balance leaves the treasury wallet and cannot reach another vendor without a recorded state change. The commitment control improves. The commitment authority does not.

Policy exceptions when work starts before the milestone is funded

The common exception is work starting while funding waits on an approver. On a paper rail that yields a retroactive purchase order. Here it yields a contractor working with no locked balance, the same exposure without the paperwork that flagged it. Write the exception down: value ceiling, approver, funding deadline, and the forum that sees the count.

Who approves what when the payer is a multisig rather than an AP clerk?

Nobody approves in the way an AP clerk does. 15 U.S. Code 78m requires registered issuers to keep internal accounting controls giving reasonable assurance that transactions are executed in accordance with management's general or specific authorisation, and private buyers adopt the same standard by policy. A multisig threshold is a single integer, so the delegation matrix has to be mapped onto the signer set rather than replaced by it.

Mapping approval bands onto a signing threshold

A Safe-style contract manages an owner set and a threshold that authorises transactions, refuses a threshold below 1, and refuses to remove an owner if the remaining count would fall under it. The same threshold governs a 500 USDC milestone and a 50,000 USDC one.

Externally owned accounts sign with private keys and contracts cannot, so a multisig approval is a contract-validated signature, not a named individual's. Close both gaps with one wallet per band, or an off-chain approval record referenced in the milestone.

SLA clarity: what the approval chain can actually commit to

Three intervals deserve commitments and they have different owners. Approval, from requisition to signed transaction, is yours and belongs in business days. Funding, from final signature to a confirmed balance, belongs in confirmations. Only the dispute clock arrives with a number already fixed, so do not point an SLA at the rail for all three.

How does segregation of duties survive when one wallet can requisition and pay?

It survives only with compensating controls, because approval and payment fuse into a single signed transaction. 2 CFR 200.318 binds recipients of Federal awards to written standards of conduct covering conflicts of interest and governing employees engaged in the selection, award and administration of contracts. Buyers outside that scope borrow the pattern, and either way those standards now reach whoever holds a signing key.

The three duties that must not collapse into one key

The classic split runs requisition, approval, payment, receipt. Here approval and payment become one act, leaving three duties rather than four. Record that as a control weakening, not an efficiency. Key custody separation keeps any individual below the threshold. Independent receipt confirmation keeps whoever confirms delivery off the paying wallet.

Conflict-of-interest standards that still apply to the signers

Signers select nothing on paper, so they often sit outside the conflict-of-interest attestation population. That is a mapping error: a signer administers the contract, because payment does not happen without them. Add signers to the declarations and related-party checks covering contract managers, and log a signer who is also the requester as an exception.

What replaces the three-way match when there is no invoice-shaped artefact?

Two legs survive and one does not. EIP-20 requires a Transfer event on every token transfer, including zero value transfers, so the payment leg is machine-generated and standardised. The funded milestone replaces the purchase order, and the acceptance record, meaning the buyer's assertion that payment is now due, replaces the invoice. Receipt, meaning evidence the deliverable was reviewed on its merits, has no on-chain artefact whatsoever.

Milestone, acceptance, and Transfer event as the three legs

Leg one is the funded milestone: amount, payee address, scope reference, locking transaction. Leg two is the acceptance record: who approved, against which criteria, at what timestamp. Leg three is the Transfer event. Legs one and three beat their paper equivalents because neither is typed by a human.

Why the receipt leg is the only one the chain cannot produce

The chain enforces the operational representation of granted authority and records settlement evidence, while service delivery remains an off-chain obligation. Nothing on-chain observes whether a deliverable was produced or reviewed on its merits.

So the goods-received note does not migrate. Rebuild it separately from the approval click: a named reviewer, acceptance criteria from the statement of work, a dated review record, and a link to the milestone identifier. Skip that and you have a two-way match, which the control description should say.

Why does supplier master data need a wallet address alongside the legal entity record?

Because the payee is an address, not a bank account. Circle publishes the Ethereum Sepolia USDC contract at 0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238 and states that testnet USDC has no financial value and is not backed by real US dollars. The vendor record needs the token contract and chain id beside the legal entity, or a payment settles on the wrong network.

Fields the vendor record gains, and the ones it still needs

Five fields join the record: payee wallet address, token contract address, chain id, the decentralised identifier anchoring portable reputation, and the date each was last verified. Legal entity name, tax identifiers, and the onboarding screening outcome stay mandatory.

A changed payee wallet is the highest-value fraud target here, since no correspondent bank can recall a payment. Require an out-of-band callback, dual approval, and a hold before the first payment to a new address. Screening sits in the enterprise sourcing compliance playbook.

IP ownership as a vendor-file artefact, not a clause to redraft

Procurement's job here is custody of the instrument, not drafting it. The signed assignment belongs in the vendor file with an execution date, a signatory, and a verification owner, checked before the first milestone funds. Record which repository holds the work product, that the contractor's credentials stay theirs, and who confirmed the assignment covers the funded scope. Drafting language sits in the MSA and escrow clause map.

What does an internal audit evidence pack for on-chain contractor spend contain?

Seven artefacts and a retention clock. 2 CFR 200.334 sets a floor of three years from the date of submission of the final financial report for Federal award records, which is the reference point a private retention schedule can defend. Three artefacts come from the chain and four from the buyer, and an auditor who cannot tell which is which weights all of it as management-prepared.

The seven artefacts, and which of them are machine-generated

Three come from the chain: the milestone funding transaction, the signer set and threshold in force that day, and the Transfer event with its hash. Four come from the buyer: the statement of work with acceptance criteria, the approval record naming the human approver, the acceptance record, and a vendor master data snapshot of the payee address. Label each artefact with its origin, because an auditor tests a machine-generated record differently.

Solidity documents that event logs are associated with the emitting contract address, stay in the blockchain, and are not accessible from within contracts. The escrow cannot compile its own history, so the indexer that does is itself in scope.

Retention and the three-year floor

2 CFR 200.318 separately requires Federal award recipients to keep records detailing the history of each procurement transaction, a completeness test rather than a duration test. Only the three chain-generated artefacts are durable by default, so a schedule expiring buyer records at two years destroys the four the buyer holds. Downstream accounting sits in the treasury and tax playbook.

How does a non-custodial rail compare with a custodial platform on vendor assurance?

A non-custodial rail has a smaller assertion surface, which is good for risk and awkward for the file. FinCEN Guidance FIN-2019-G001 treats intermediary status as a question of who owns the value, where it is stored, whether the owner interacts directly with the payment system, and who controls it.

Who the service organisation is when funds never touch a platform balance sheet

A service organisation is defined by what it controls, not by what it is called. A platform holding client balances can assert about the controls over that value. A rail where funds move from buyer wallet to contract to contractor never holds a client balance, so its possible assertions are fewer. That cuts both ways: less concentration risk, and a thinner report.

What a buyer has to test itself when there is no report to rely on

Four things move onto the buyer: the contract code and its audit history, the key custody arrangement, the indexer that assembles the evidence pack, and the acceptance process behind the receipt leg. Complementary user entity controls and subservice organisations are the right vocabulary here, though both stay concepts you apply rather than facts anyone certifies. A yearly questionnaire goes stale the day after signing, and continuous vendor evidence is the alternative.

Budget encumbrance · Traditional AP rail: PO raised against a cost centre · Custodial marketplace escrow: Funds held on platform balance · Non-custodial USDC milestone escrow: Funds locked in contract before work starts · Who owns the control: Buyer
Approval authority · Traditional AP rail: Value-banded DoA matrix · Custodial marketplace escrow: Platform role permissions · Non-custodial USDC milestone escrow: Multisig signer set and threshold · Who owns the control: Buyer
Segregation of duties · Traditional AP rail: Four separate roles · Custodial marketplace escrow: Three roles, platform holds payment · Non-custodial USDC milestone escrow: Approval and payment fuse in one signature · Who owns the control: Buyer, with compensating controls
Payment evidence · Traditional AP rail: Bank remittance advice · Custodial marketplace escrow: Platform statement · Non-custodial USDC milestone escrow: Transfer event and transaction hash · Who owns the control: Rail, machine-generated
Receipt of deliverable · Traditional AP rail: Goods-received note · Custodial marketplace escrow: Platform acceptance click · Non-custodial USDC milestone escrow: No on-chain artefact exists · Who owns the control: Buyer, entirely
Vendor identifier · Traditional AP rail: Legal entity plus bank details · Custodial marketplace escrow: Platform account id · Non-custodial USDC milestone escrow: Wallet address, chain id, and DID · Who owns the control: Buyer
Vendor assurance report · Traditional AP rail: Bank attestations · Custodial marketplace escrow: Service organisation report · Non-custodial USDC milestone escrow: Smaller assertion surface, buyer tests directly · Who owns the control: Buyer
Dispute forum · Traditional AP rail: Litigation or arbitration · Custodial marketplace escrow: Platform support decision · Non-custodial USDC milestone escrow: Juror panel, fixed voting window · Who owns the control: Rail

Platform Signal. Across the Sepolia beta, 1,200+ freelancer profiles and $2.4M+ in on-chain payments moved through milestone escrow, with a 10% flat fee charged only on approved contracts and 0% on job posting. When a milestone is contested, an Aragon-OSx panel of 3, 5, or 7 jurors votes inside a 72-hour window, both sides having staked 5% of the disputed amount in USDC, redistributed 30% to jurors and 70% to the winner.

Which controls must the buyer own because no regulated intermediary owns them?

Every control an authorised intermediary would otherwise have carried. Article 59 of Regulation (EU) 2023/1114 requires authorisation as a crypto-asset service provider before a person provides crypto-asset services in the Union, with separate treatment for certain listed financial entities. Where no such provider stands in the payment path, the control set moves onto the buyer's register, usually unrecorded.

Where authorisation status changes the answer in the European Union

Take the classification as settled and read the consequence. Article 75 of the same regulation attaches duties to a provider holding crypto-assets on behalf of clients, including concluding an agreement with those clients that specifies custody and administration duties. A rail that never holds client crypto-assets produces no such agreement. Five line items land on the buyer instead: safekeeping of release keys, the record of who authorised each release, the payee address register, evidence retention, and a complaints path.

The control test that decides the answer in the United States

The four-criteria test runs the same way. Money transmission analysis for convertible virtual currency turns on control over the value, not on how a party describes itself, so the fourth criterion is where a non-custodial design is tested. Have counsel document the position once, date it, and reference it from the control descriptions. Scope artefacts feeding the requisition sit in the buyer's checklist for sourcing an auditor.

Compliance corner. Under Article 59 of Regulation (EU) 2023/1114, European Union, a person shall not provide crypto-asset services in the Union unless authorised as a crypto-asset service provider or covered by the separate route the regulation gives certain listed financial entities, which decides whether any CASP stands in the payment path. Under Article 75 of the same regulation, European Union, a provider offering custody and administration of crypto-assets on behalf of clients must conclude an agreement with those clients specifying duties and responsibilities. In the United States, FinCEN Guidance FIN-2019-G001 sets the four-criteria control test behind money services business status and money transmission for convertible virtual currency. General information, not legal advice.

Where to go next on FiduWork

Onboarding controls this post treats as complete sit in the enterprise sourcing compliance playbook. Everything downstream of the Transfer event sits in the treasury and reconciliation playbook. The contract layer is mapped in the MSA and escrow comparison, with mechanics in the protocol documentation.

Request a Compliance Brief. See how funded USDC milestones and on-chain settlement records line up against a procure-to-pay control set. Open the app.

Sources

Update Log

2026-09-11: Published.