A newly published technical comparison from UTXO Engineer places a BSV-based machine-payment implementation alongside Circle’s newly launched Arc network, showing how a similar HTTP 402 payment pattern can sit on top of substantially different settlement architectures.

Circle launched the Arc mainnet on September 16, positioning the Layer 1 network for financial markets, payments and agentic economic activity. Its Agent Stack uses smart-contract accounts and USDC-based payments as part of that environment. (Circle)

In Two Rails, One Protocol, UTXO Engineer compares that approach with a payment flow already being used in Intellegio’s data pipeline. Both follow the familiar sequence of requesting a resource, receiving an HTTP 402 response with a price, making the payment and retrying the request.

The author is careful about terminology. Intellegio’s implementation follows the same pattern associated with x402, but settles over BSV rather than the EVM-based environments with which x402 is commonly associated. The article therefore stops short of claiming that the implementation is formally x402 itself. (UTXO Engineer)

Similar interaction, different settlement

On the BSV side, the implementation uses BRC-100 wallets and UTXO-based transactions. A payer signs the transaction, while transaction evidence can be supplied through BEEF — the Background Evaluation Extended Format defined in BRC-62 for exchanging the information needed for Simplified Payment Verification. (GitHub)

Circle’s Agent Stack instead uses ERC-4337 smart-contract accounts. Payment authorization passes through programmable contract logic, with Circle Gateway acting as a facilitator that verifies the authorization and submits the transfer.

The result is that two applications can expose a very similar payment experience at the HTTP layer while relying on quite different mechanisms underneath.

UTXO Engineer highlights several of those differences, including authorization, wallet design, settlement, transaction ordering, fees and privacy.

The BSV implementation uses signatures against specific transaction outputs and BRC-derived keys, while Circle’s architecture places programmable smart-contract logic in the authorization path. The article also contrasts per-counterparty derived keys on BSV with persistent smart-account addresses on the Arc side. (UTXO Engineer)

The security distinction

The comparison becomes more concrete through an unrelated Ethereum incident from September 15.

Approximately 2,900 rsETH, worth about $7.8 million at the time, was removed from a Gnosis Safe after a flaw in an enabled strategy-executor module allowed an authorization check to be bypassed. A separate MEV bot then front-ran the original exploit transaction and captured most of the funds. Independent reconstructions indicate that the vulnerability was in the custom module and authorization path rather than Safe’s core multisignature contracts. (SigIntZero)

The incident did not involve Circle Arc.

UTXO Engineer instead uses it to illustrate a broader architectural point. Both the affected Safe configuration and Circle Agent Wallets belong to the wider category of programmable smart-contract accounts, although they use different implementations and standards.

The author’s argument is that the particular failure demonstrated by the Safe incident — programmable authorization logic giving an unintended caller authority over wallet assets — does not have a direct equivalent in a basic BSV UTXO payment path because there is no externally callable executor or module system between the signature and the spend. (UTXO Engineer)

That is a narrower claim than saying one network is immune from security failures.

BSV wallets and applications can still suffer from compromised keys, faulty wallet software, application mistakes or infrastructure failures. The distinction being made is that the shape of the attack surface changes with the settlement architecture.

Why the comparison matters

The interesting point is therefore not simply that both systems can support machine-to-machine payments.

It is that a payment protocol visible to an application can conceal very different assumptions underneath it.

The same request–402–payment–retry interaction can be implemented through a relatively direct UTXO transaction model or through programmable smart-account infrastructure. Those choices affect how authorization works, where additional logic sits, what intermediating services participate, how privacy is approached and what kinds of software failures become possible.

For BSV, the comparison is particularly relevant as HTTP 402 payments, autonomous agents and machine-paid services become a larger development area.

The payment pattern may increasingly become common across networks. The infrastructure underneath it does not necessarily become common with it.

Source Link

UTXO Engineer, Two Rails, One Protocol, first published September 16, 2026. (UTXO Engineer)

September 18, 2026