Cheaper Onchain Costs Won’t Fix Confusing Wallet UX

Solana is making it cheaper to create and maintain onchain accounts.

Its Reduced Rent upgrade changes the constant used to calculate the refundable balance an account must hold for onchain storage. The first reduction activated on mainnet on September 3, while the full rollout targets a 90% reduction over multiple phases.

That is meaningful infrastructure progress.

For products creating large numbers of token accounts, PDAs or other account state, lower deposits can reduce the capital required for onboarding.

But cheaper infrastructure does not solve a different problem:

The user still has to understand what they are approving.

Cost is only one layer of friction

Crypto products often treat friction as a performance problem:

Lower fees.
Faster confirmations.
Fewer signatures.
Cheaper accounts.

All of those improvements matter.

But a user can move through a technically efficient transaction and still be unsure about the most basic questions:

Which network am I using?

What asset pays the fee?

What is the expected total cost?

What will the recipient actually receive?

What happens after I press Confirm?

What should I do if the expected result does not appear?

Removing infrastructure cost does not automatically answer any of them.

And that becomes particularly important in cross-chain journeys, where one user action can hide approvals, swaps, bridging and destination execution.

Cheaper infrastructure should reduce complexity — not hide the decision

Solana’s reduced-rent change is useful because infrastructure such as account creation can become less expensive and easier for products to absorb.

A user should not need to understand account-storage economics simply to receive an asset.

But abstraction has a boundary.

Hide infrastructure the user does not need to manage.

Keep visible the information the user needs to make a decision.

Before signing, a wallet should make at least four things clear:

1. Network

Where is the action happening — and where should the asset end up?

2. Expected cost

What costs matter to the user's final outcome?

3. Expected result

What asset should arrive, approximately how much, and on which network?

4. Uncertainty

Which parts are known now, which are estimates, and what can still change?

Simulation can help predict an outcome.

It cannot turn future execution into certainty.

That distinction matters.

The experience does not end at the signature

Once the transaction is submitted, wallet UX should move from explaining the expected outcome to explaining the observed outcome.

A useful status model looks more like:

Submitted → In progress → Completed / Partial / Refunded / Failed

Instead of simply:

Done.

And every state should answer two questions:

Where are the assets now?

What can the user do next?

Block explorers are useful evidence.

But the user should not have to become a blockchain investigator every time something takes longer than expected.

Where Biti.pro fits

Biti.pro is still pre-launch.

We are building around a narrower problem:

How can self-custody users understand a route from EVM networks toward Solana without having to interpret every underlying infrastructure detail themselves?

Cheaper infrastructure helps.

Faster networks help.

Better routing helps.

But none of them remove the need for understandable decisions.

Our product principle remains simple:

Hide unnecessary complexity. Keep the decision legible.

Users should not have to know how lamports_per_byte works.

They should understand:

What am I doing?

What will it cost?

What should happen next?

That is where better infrastructure becomes better UX.

Explore Biti.pro → https://biti.pro