What the UI meant

Web3 is full of words that sound more familiar than they are.

Crypto. Coin. Token. Wallet. Swap. The vocabulary suggests that you already know roughly what is going on. Then you look underneath it and find a different model of ownership, exchange and state.

SaucerSwap already existed as a working decentralized exchange on Hedera. The work was on the application around that existing system, not on building the network, protocol or smart contracts underneath it.

I did not need to know how to build a blockchain network. I did not need to know how to implement a decentralized exchange from scratch. I was not writing smart contracts or designing consensus.

I still had a problem. I barely understood what the UI meant.

Making sense of the system

A traditional webshop gives you a lot for free.

A product is a product. A cart is a cart. A price is a price. Even if the implementation is unfamiliar, the underlying concepts usually are not.

SaucerSwap was different.

There were liquidity pools, swaps, staking, tokens that represented other positions, different networks, bridges, wallets and governance. Knowing what each word stood for helped, but it wasn’t enough. I needed to understand how the pieces depended on one another.

So I started from the bottom.

I started thinking about the network as shared state. There is a record of which accounts own which assets and what state the applications running on the network are in. No single application database is the authority over that record. The network maintains it according to a common set of rules.

A transaction is a request to change that state.

Sending an asset to another account changes the balances. Interacting with a protocol may change some other part of the state. The important part was that the application was not maintaining its own version of reality. It was interacting with a system whose state existed underneath it.

The network is the infrastructure, and it has its own native coin. On Hedera, that coin is HBAR.

Tokens are different. They exist on the network, but they are not the network's native currency. They can represent value, utility, ownership or even a position in another mechanism.

It matters once you reach the exchange

A decentralized exchange does not necessarily work like the market model most people first imagine, with a buyer waiting for a matching seller.

An automated market maker can let the user trade against a pool of assets instead. If a pool contains two tokens, users can swap between them. Liquidity providers supply those assets and can earn part of the fees generated by trading activity.

The pool is not just a pair of balances on the screen. It is the liquidity that makes the trade possible.

If I provide assets to a pool, I am not reserving those exact units in a box with my name on it. I own a position in a pool whose composition changes as people trade against it.

The same idea appears elsewhere in DeFi. A token can represent a claim or position rather than simply being an asset that exists on its own.

SaucerSwap's xSAUCE is a good example. SAUCE can be staked, and the resulting xSAUCE represents the user's position in that staking mechanism. I started thinking of xSAUCE as a receipt for the staked position.

At first, xSAUCE was just another balance on the screen. At first, xSAUCE was just another balance on the screen. Knowing what it represented made its role elsewhere in the product much clearer.

As those relationships became clearer, the unfamiliar terms on the screen started fitting into a system. It started looking like a product.

The mighty wallet

Then there was the wallet.

A wallet, despite the name, does not actually hold the money.

The assets are recorded on the network instead. What the wallet holds, or more precisely protects, are the keys that let a user prove control over that account and authorize actions from it.

When a user connects a wallet, the application does not receive the private key and it does not suddenly gain control over the account. The connection gives the application a way to know which account the user wants to interact with and a channel through which it can ask the wallet for authorization.

From there, the wallet becomes a gatekeeper.

The application can prepare a request. The wallet can show the user what is being requested. The user can approve or reject it. If approval requires a signature, the wallet creates that signature without exposing the private key to the application.

But signing still does not automatically mean sending a transaction.

A wallet can sign something without changing network state. That signature may only prove control of an account, or it may become part of a larger network interaction.

A transaction goes one step further. It asks the network to change state. That might mean transferring an asset, staking, swapping or interacting with a smart contract. The wallet can authorize the request, but the network still decides whether it is valid and whether the change is accepted.

Connect Wallet can look like a generic authentication step. In practice, connection, signing and submitting a transaction were separate parts of the flow.

The application prepares the action. The wallet lets the user authorize it. The network decides whether it can happen.

For something that does not actually contain the money, the wallet is doing a remarkable amount of work.

Then came governance

Later, I worked on governance. By then, the knowledge I had built around wallets, tokens and protocol state was finally useful in one place.

The voting UI looked straightforward. Choose an option and press a button.

Underneath that action, several questions have to be answered.

Who is voting? Did that account actually authorize the vote? How much voting power does it have? Which state should be used to calculate that power? And once all the votes are collected, what actually counts as enough participation for a decision to pass?

SaucerSwap governance is token-weighted. Each vote carries a weight based on the account's voting power.

An account with 1,000 voting power has more influence on the result than an account with 100. Voting power can come from SAUCE and from xSAUCE, which represents staked SAUCE, so even the number displayed next to the connected account already has protocol rules behind it.

Voting power also depends on historical account state. Balances can change while voting is open, so SaucerSwap takes account-balance snapshots during the voting period and uses historical SAUCE and xSAUCE data when determining voting power.

So the number shown in the UI was already the result of several protocol rules. It represented token balances, the conversion between xSAUCE and its SAUCE equivalent, and historical account state. The wallet could authorize the vote without being the thing that determined how much that vote was worth.

Even a clear majority does not necessarily make a proposal pass.

Governance can require a quorum. A minimum amount of total voting power must participate before the result is considered valid. A proposal can therefore have a clear YES majority and still fail because too little voting power participated.

The interaction depended on identity, ownership, timing and participation. All of that affected what the UI displayed and what the user could do.

Who decides?

Governance also exposed something else I had not fully understood before working on the project.

“Decentralized” does not mean that every decision in a system is made by the same people, or through the same mechanism.

Hedera has governance over the network itself. SaucerSwap has governance over parts of its own protocol. Other product and interface decisions remain outside that governance scope. The network, protocol and product layers interact, but they do not control the same things.

A company involved in Hedera governance does not automatically get a special vote in SaucerSwap governance. Holding SaucerSwap governance power does not give someone authority over how Hedera itself is run either.

Knowing where to stop

None of this turned me into a blockchain engineer. That was never the goal.

If I had tried to understand every detail of consensus, protocol economics, smart contract architecture and cryptography before touching the frontend, I would probably still be reading.

What I needed was enough context to understand the product I was working on.

That meant knowing what the values on the screen represented, what happened when a user signed something, why a vote carried a certain weight and where the boundaries between the application, protocol and network actually were.

The code I wrote was small. The context was not.