Working on stablecoin and payment infrastructure in Latin America has taught me that the most important question is rarely whether a transaction was submitted successfully.

The more useful question is:

When is it safe for someone to act on it?

A user wants to know when the money arrived. A merchant needs to know when to release a product. A wallet must decide when to update the available balance. An exchange needs to determine when to credit a deposit. A bridge must decide when it can safely fulfil a transfer on another chain. A financial system may need to distinguish between recognizing an incoming payment, making the balance spendable, reconciling it and moving the underlying funds.

Today, most applications compress all these decisions into a single green checkmark:

Pending → Confirmed

That abstraction is easy to understand, but it hides the most important part of settlement: different blockchain states provide different guarantees, and those guarantees do not authorize the same actions.

Ethlabs’ newly published view on Hegotá identifies four protocol priorities: stronger censorship resistance, a faster Ethereum, native account abstraction and continued L1 scaling. Ethlabs also describes its role as sitting between real-world Ethereum usage and protocol development, with the belief that protocol engineering should enable better products and that products should help inform the protocol’s direction.

I believe those are the right foundations for global payment infrastructure.

But from the application side, one layer is still missing.

Once Ethereum exposes faster blocks, stronger inclusion guarantees, more capable accounts and more predictable capacity, wallets, bridges, exchanges and payment processors still need to translate those properties into operational decisions.

I call that missing layer an Application Settlement Policy:

An application-facing layer that translates protocol signals into explicit, observable and risk-aware decisions about money.

This is not a proposal to redefine Ethereum finality, nor is it currently a proposal for a new EIP. In this article, “settlement policy” refers to the rules an application uses to decide when it can safely act on a transaction—not to a new consensus mechanism.

The protocol provides guarantees.

The application must understand what those guarantees mean.

The green checkmark arrives too early

Consider a 100 USDC payment for a subscription. The merchant can revoke access if something goes wrong, but would rather not have to. The user, meanwhile, only wants to stop looking at a screen that says “pending.”

The transaction does not jump from one state to another all at once. It moves like this:

observed → included → safe → finalized

At observed, the application has seen the transaction. It may be in the mempool or may have arrived through an RPC provider, but it can still disappear, be replaced or never enter a block.

At included, it is part of the canonical chain. That is a much stronger signal, although the block can still be reorganized.

At safe, the node says that its safe head covers the block. The application can now consider acting before finality, as long as it understands what produced that signal and checks that it is still fresh.

At finalized, Ethereum provides its strongest normal guarantee. For a high-value operation or something that cannot be reversed, this remains the reference point.

Not every application needs to make the same decision. A subscription that can be cancelled does not carry the same risk as a withdrawal, a treasury movement or the delivery of an asset that cannot be recovered.

What every application should be able to do is explain the decision.

The problem with the green checkmark is not that it is simple. Simplicity is useful. The problem is that it ends up meaning too many things.

When safe stops moving

The Fast Confirmation Rule, or FCR, makes this distinction visible.

FCR is designed to confirm a block in roughly one slot instead of waiting approximately 13 minutes for finality. It runs locally in consensus clients and can expose its result through the existing safe tag. It does not require a hard fork.

For a bridge, deposit or payment, thirteen seconds can change the experience considerably. It can also reduce how long an application keeps capital locked.

But FCR is not finality with a faster clock.

It depends on network synchrony and on adversarial stake remaining below 25%. It also does not provide the same slashing-backed economic security. If those conditions stop holding, fast confirmation can stop advancing and the system eventually falls back to finality.

That is the detail I find most interesting.

The RPC can respond successfully. The returned block exists. No exception appears. The safe head, however, may not have moved for several slots.

The call worked
≠
The guarantee is still progressing

An application that only checks whether the RPC responded can treat an old signal as if it had just arrived.

Before moving money or releasing something, it needs to know which mechanism produced safe, how far it sits behind latest, whether it is still advancing and whether it actually covers the payment block. For higher-risk operations, it may also compare more than one source.

The blockchain provides the state.

The decision is still missing.

The missing layer

An Application Settlement Policy sits precisely in that space: between what the node knows and what the product decides to do.

It does not need to begin as a large system. A useful response could be as small as this:

{
  "status": "safe",
  "mechanism": "ethereum_fcr",
  "safeHeadLagSlots": 2,
  "stalled": false,
  "policy": "merchant_subscriptions_v1",
  "decision": "activate_subscription"
}

The important field is not only status. It is decision.

To reach that decision, the policy combines the protocol signal with the context of the payment. It needs to know whether the delivered value can be recovered, how much value is at risk, whether the application is advancing liquidity, whether it depends on a single provider and what happens if the network stops progressing as expected.

A rule such as “below USD 100, use safe; above USD 100, wait for finalized” can be a useful beginning. It does not cover every case. Two payments for the same amount can produce very different losses.

The policy also needs a name and a version. Months later, someone should be able to inspect the payment and understand why the application activated the subscription:

The safe head was fresh, lag was two slots and policy version 1 permitted delivery of a reversible service.

That is much more useful than discovering that the frontend displayed a green checkmark.

Back to the 100 USDC

First, the application detects the transaction and shows it to the user. It does not activate the subscription yet.

Then the transaction enters a block. The merchant can prepare the account but waits for a stronger guarantee.

When safe covers the block, the policy checks the freshness of the signal. If everything is operating normally and its rules accept the risk, it activates the subscription. If safe has stopped advancing, it does not guess what happened: it waits.

Finally, Ethereum finalizes the block and the application closes its accounting record.

The risk did not disappear. Neither did the complexity.

What changed is that the decision is no longer hidden.

What Ethereum can improve

Protocol improvements make this path faster and more reliable, but they do not replace the application’s decision.

EIP-8198, Quick Slots, proposes making slot duration parametric and reducing it as testing permits. That can shorten the time before a transaction enters a block.

FOCIL, Scheduled for Inclusion in Hegotá, aims to strengthen inclusion. This matters because a transaction that never enters a block cannot settle.

EIP-8141, Frame Transactions, is Considered for Inclusion in Hegotá. It can bring programmable validation, batching and alternative gas-payment arrangements closer to the protocol. That improves how a user authorizes a payment.

Quick Slots helps the transaction arrive sooner. FOCIL helps it get in. Frame Transactions can make it easier to submit. FCR can provide a useful guarantee before finality.

None of them knows whether the merchant should activate the subscription.

That last step still belongs to the application.

What I would build first

I would not begin by writing another standard.

I would begin with something less exciting and easier to break: a small library that observes latest, safe and finalized, applies a versioned policy and returns a decision.

Then I would try to make it fail:

  • stop safe from advancing;
  • connect two providers that report different heads;
  • test a reorganization;
  • disable FCR;
  • change the policy while payments remain pending.

I would also keep a simple record of every decision. Not to fill a dashboard with charts, but to answer one question when something goes wrong:

Why did the system act at that moment?

If the model survives a real checkout, deposit or bridge, then shared schemas, webhooks or broader standardization will be worth discussing.

Ethereum should not decide when a merchant releases a product.

Applications should not invent opaque meanings for “confirmed” either.

Settling without surrendering control

Using a managed RPC, relayer or monitoring service does not by itself eliminate self-custody. The problem begins when that provider becomes a black box that nobody can inspect or replace.

A settlement policy should record where each signal came from and allow the infrastructure to change without changing the meaning of the money.

That is what I am trying to express with the title.

Settlement without surrender does not mean waiting for finality in every situation. It does not mean acting quickly and trusting that nothing will go wrong either.

It means knowing which guarantee exists, checking that it remains fresh and acting only when the policy permits that risk.

The checkmark can remain green.

But behind it there must be a decision that someone can explain.