Follow the whole application.

Give permission, then request the trade.

Maya first checks the network, token addresses, and contracts shown by the website. A familiar screen is not enough; she needs the request to point to the intended system.

In this example, a named swap contract needs permission to move her B tokens. Maya approves an allowance of 25 B for that spender. The token contract records the permission. No swap has happened yet.

Next, she signs a swap request. It includes the minimum amount she is willing to receive. A block proposer places the request in order with other requests.

When it runs, the contract moves 25 B into the pool. It applies the pool’s rule and sends the resulting amount of A to Maya. Full nodes check the block and the changed records.

This pool calculates from its own reserves. It does not need an outside price feed or a bridge for this made-up swap. Other apps may use those parts, but we should trace the dependencies actually present.

After inclusion, Maya reads the receipt and checks the balances. Success means the request ran under the code’s rules. Later finality means stronger agreement about the history containing it.

Neither success nor finality proves that the tokens are valuable or that the website made honest promises. Code execution, settlement, and value are different questions.

Think back to the shared-rulebook comparison. Validity rules say which actions are permitted. History selection helps maintain a record under those rules. People use governance to consider and adopt rule changes. Computer rules do not settle law, intent, or what every person must accept.

Close the website in the model. The public record can remain even when that doorway disappears. Another compatible interface may still read Maya’s balances, but the actual contract’s controls and ability to run remain separate questions.

The same is true of a game token. Its record and key-based control may survive the game, while artwork hosting, legal rights, the game itself, or support in another app may be missing.

Calculate the result, then change one fact.

Start by multiplying the original reserves: 100 A × 100 B = 10,000. This is the product our fee-free pool must keep.

Maya adds 25 B, so the new B reserve is 125 B. Divide the product by this new reserve: 10,000 ÷ 125 = 80 A. That is how much A must remain.

The pool had 100 A and keeps 80 A. Maya gets the difference: 100 − 80 = 20 A. Adding 25 B did not buy 25 A at the starting quote, because the trade changed the reserves.

The network work has its own bill in ETH. It is separate from this fee-free A/B calculation. If Maya uses one approval transaction and then one swap transaction, each included execution can use paid work.

Her financial result also depends on what A and B are worth afterward. Receiving the calculated amount is not itself proof of a profit.

Now change one fact: another trade runs before hers. That trade changes the reserves. Maya’s request now starts from a different pool, so the old calculation of 20 A no longer necessarily applies.

Her signature still gives permission. It does not freeze the pool at the earlier quote. If the new output is below her minimum, the request can fail. A failed included request can still use gas and cost a fee.

Try 25 on the pool slider to check the 20-A result. Then change the trade size. Say which starting assumption changed before calculating again.

Network rules can change too, through proposals and adoption. Ethereum’s move to proof of stake kept its execution history. It did not let large validators accept transfers without valid permission.

Use four questions to explain the whole swap. Mechanism: what permissions and calculations made it work? Evidence: what do the request, receipt, and record show?

Then ask assumptions: which tokens, contracts, reserves, and transaction order did the example require? Finally, ask exposure: what could permissions, fees, changing prices, or failed dependencies cost Maya?