Puffer and Google Cloud collaborate on Ethereum transaction preconfirmations

When a payment app tells you a transfer is complete, you start making decisions. You hand over whatever you've sold, spend the money you've received, or close the app and get on with your day. That little confirmation you get is enough for you to stop thinking about whether the transaction worked.

Crypto companies want to offer that reassurance almost instantly, even when the blockchain underneath still needs time to finish settling the payment. One way to do it is to have an operator promise the result early and put money behind that promise.

Puffer, a company building transaction infrastructure for Ethereum, is working on a system like this. On Sept. 22, it announced that Google Cloud would operate a gateway, receiving transactions and guaranteeing their results before settlement. Puffer's UniFi network would be the first to use it.

Both UniFi and Puffer Preconf, the service issuing these guarantees, were still running in a testing environment as of Sept. 23, CEO Amir Forouzani told CryptoSlate. Their performance with customers putting real money through them still has to be established.

But the idea gets at something familiar to anyone who uses a financial app. When the screen tells you the money is ready, you expect to be able to use it. Making that happen sooner means deciding who can be trusted to give the go-ahead and who takes responsibility if they're wrong.

What do Ethereum preconfirmations actually promise?

The Ethereum network relies on many computers agreeing on a shared record of transactions. Its base layer has 12-second slots for proposing blocks, the batches in which transactions are recorded. Getting into one of those blocks is a step toward completion, while the stronger confirmation known as finality usually takes minutes. Reversing a finalized record would require a severe breakdown of the network's security, with enormous financial penalties.

That gives apps a decision to make about how long to wait. Many run on additional networks called rollups, which process transactions separately and send information to Ethereum for settlement. These networks can give users early confirmations from the operator arranging their transactions, allowing the app to respond while Ethereum's settlement process continues.

Puffer wants to put explicit financial backing behind an early promise about the transaction's result. To see the appeal, imagine selling some crypto because the amount offered is enough to pay a bill. You want to know how much you'll receive and when you can use it, especially if the price is moving while you wait.

Forouzani described the service using a hypothetical exchange of 1 ETH for 2,600 USDC. The gateway would promise the execution result, including the amount received. Promising to include a transaction in the record is a narrower commitment, because inclusion alone doesn't guarantee the exchange result you wanted.

These promises are called preconfirmations. If an application accepts one and understands its conditions, it could act on the expected result before the longer settlement process finishes. That could allow a sale and a subsequent purchase to feel like connected steps, instead of leaving the customer waiting between them.

Forouzani said Puffer's transaction times were configured at 50 milliseconds, or one-twentieth of a second. But that's a setting in the company's system, and it hasn't been independently established as the speed paying customers would experience. Ethereum would still take its own time to reach finality.

The benefit is easy enough to see without caring about the technology underneath it. People could spend less time wondering whether their sale went through or whether they can use the proceeds. The app, meanwhile, would need a good reason to let them move on, because it's accepting a promise about something that hasn't finished settling.

The cost of being wrong

Puffer's answer is to back those promises with collateral, meaning assets committed to the service that can be taken away if an operator breaks the rules. That penalty is called slashing. According to Forouzani, a failed preconfirmation would cost the gateway 1 ETH, giving it a very good reason to deliver the result it promised.

With a penalty like that, keeping a commitment becomes part of the operator's business calculation. Breaking it costs money, so the operator has an incentive to run the service properly and avoid promising more than it can deliver. Customers also need to know whether any of that money would reach them if a transaction went wrong.

Suppose an app accepts an early payment promise and releases $100 in stablecoins. If the payment doesn't come through, the seller needs to know whether they'll receive the missing $100, who will pay it, and how long they'll have to wait. Penalizing the operator could help fund that repayment, but someone still has to establish which losses qualify and get the money to the person who lost it.

Puffer's announcement says slashing protects affected parties. Its answers to CryptoSlate, however, didn't explain who receives the penalized ETH or how compensation would be calculated and paid.

The amount available also needs to make sense for the transactions it supports. If an Ethereum operator backs many promises with the same pool of collateral, several failures could draw on that pool at once. Applications would need to compare the money available with the losses they're taking on by accepting those promises. They'd also have to account for the value of ETH moving against the dollar, since a penalty of 1 ETH doesn't always buy the same amount.

These are still terms of a proposed system. Puffer's July 2025 technical outline put slashing in a later phase, and the latest answers don't establish when the stated penalty would become enforceable. Forouzani said there had been no failures under the current design, but didn't provide a transaction count or observation period. With both products still in testing, there's more to learn about how the arrangement would work when customers depend on it.

Someone decides when you can move on

Google Cloud would be one of the companies making those early promises. According to Forouzani, another gateway would pick up transactions if Google's went offline, giving the service a way to keep operating through an interruption. How that handover performs with real customers is part of what the system still has to demonstrate.

Forouzani also said the first phase would launch without delegation from Ethereum's base-layer validators, the operators that help the underlying network agree on its record. The early assurance would come from the gateways, while Ethereum handles the later settlement. Anyone building an app around the service needs to understand which operator is responsible at each stage.

Most customers will never get that far into the details, and there's little reason they should have to. The app's developers will decide when a balance becomes available and when a purchase can proceed. Customers will see the result of those decisions every time the screen tells them a transaction has succeeded.

This gives developers room to make different choices. Someone selling an inexpensive digital item might accept an early promise, while a service handling a much larger transfer might wait for stronger confirmation. The right amount of waiting depends on what happens next and how much a failure could cost.

But once an app tells people they can spend, it needs terms that explain who absorbs a failure and what customers can expect. Asking every shopper to inspect a gateway's collateral would make an ordinary purchase absurdly complicated. The service presenting the confirmation has to do that work.

Ethereum also has proposals to shorten the wait for its own blocks, which could reduce some of these delays. But applications would still need to choose how much assurance is enough before letting a customer take the next step.

Puffer's experiment could give them another option, with an operator putting money behind its permission to proceed. If that works, the technology could become something customers rarely have to think about.

When an app says the money is available, they should be able to believe it, use it, and close the app without discovering later that “done” meant something different to the company.