Agent-First Pay v0.4.2: Solana Payments Became Order-Bound

A payment amount is often not enough to identify what was paid for.

Two customers can pay the same amount. One customer can retry. A service can watch many inbound payments at once. Agents need a way to bind a payment to the order, task, or invoice it was meant to satisfy.

Agent-First Pay v0.4.2 added that binding for Solana.

The problem: matching by amount and memo is not always enough

On-chain receive flows commonly match by amount, sender, memo, or time window. Those signals help, but they are not always durable enough for automated order matching.

Solana has a useful convention: include a reference public key as a read-only non-signer account on the transfer instruction. The key does not move funds. It acts as an on-chain correlation handle.

The change: send can attach a reference key

The v0.4.2 send path added a --reference CLI flag for Solana transfers. afpay adds the reference public key to the transfer instruction as a read-only non-signer account.

That lets an agent create a payment tied to a specific order or protocol intent without inventing a proprietary memo wrapper.

The receive change: wait can match by reference

The receive watcher also learned to extract reference keys from transaction account lists. sol receive --wait can now use --reference as a match condition alongside memo and amount.

That gives services a cleaner verification path: wait until a transaction with this reference appears, then return the structured payment event.

Where this fits: payment metadata should be protocol-native

v0.4.2 is a small release with a clear agent benefit. It makes payment matching less ambiguous without moving correlation into fragile text parsing.

For agents, the best payment reference is one the network itself can carry.