Module 6 · Ethereum & Shared Applications / 6.7
What the shared machine made possible.
Payments, loans, markets, and the dependencies underneath them.
Maya wants to send a dollar-like token, borrow against an asset, and exchange one token for another. Three different applications offer to help.
They may look like separate businesses. Underneath, they can be using the same tokens, price feeds, and shared contracts. That connection explains both their usefulness and their risk.
A token can target a familiar price.
A stablecoin is designed to track a reference value, often one U.S. dollar. The name describes a target. It does not guarantee that you can always sell or redeem one token for one dollar.
Some issuers hold reserves such as cash and short-term government debt. Users rely on the reserves, the issuer’s terms, and access to redemption. Some contracts also give the issuer freezing powers.
Other designs use crypto collateral, often requiring more collateral value than the stablecoins issued. They depend on prices, liquidation mechanisms, and the assets that back them. Some designs overlap these categories.
Algorithmic designs try to maintain a target through incentives and supply adjustments, sometimes relying on another volatile token. If confidence and collateral value collapse together, that mechanism can fail. A clever formula is not a reserve.
This depicts a reserve-backed design. Redemption still depends on the issuer’s terms, access, and assets.
These tokens can make transfers and on-chain accounting easier. That does not remove redemption restrictions, network fees, sanctions controls, privacy exposure, or the banking connections of a reserve-backed issuer.
A loan can watch its collateral.
In lending applications such as Aave or Compound, suppliers provide assets and borrowers pay interest. A common design requires borrowers to post collateral worth more than the loan.
The contract checks the collateral using a price feed. If the collateral becomes insufficient under its rules, a liquidation can repay some debt by selling or seizing collateral, often with an incentive for whoever performs it.
For a fictional loan, suppose debt is 100 units and the liquidation boundary is 80% of collateral value. Collateral worth 150 gives room: 80% is 120. If its value falls to 120, the boundary amount is only 96. The debt is now beyond the threshold.
This is not an unsecured bank loan with a human deciding whether to offer another month. Exact thresholds, penalties, interest, and failure handling vary by market. The code can be automatic while its price feed and governance still introduce dependencies.
A protocol may set a stricter limit for opening a new loan than its liquidation threshold. Our example isolates the liquidation boundary; it does not model an actual product’s borrowing rules.
Collateral currently covers the modeled boundary. Its price can still change.
Fictional fixed debt and 80% liquidation threshold, with no interest or penalties modeled. A borrowing limit and liquidation threshold can differ in real markets.
Where does the payment come from?
A displayed yield needs an explanation. Borrowers may pay interest. Traders may pay exchange fees. A project may distribute newly issued tokens as an incentive.
These sources have different economics. A token reward can fall in price or dilute holders. Fees can be smaller than inventory losses, operating costs, or a contract failure. Calling something “real yield” does not make its net return safe.
An automated market maker lets traders exchange against a pool of assets. People supplying that pool can earn fees, but their inventory changes as others trade. The next three lessons explain that mechanism and its variations.
The question to carry forward is simple: who pays, for what service, and what could consume more than those payments?
Useful pieces can share a weak link.
An NFT records a distinct token. It can support a ticket, a name, or a credential, but the file, legal rights, and real-world acceptance need their own arrangements. A token alone cannot prove that a physical object is authentic.
A DAO uses some combination of proposals, voting, and shared treasury rules to coordinate people. Voting weight, participation, delegated power, and administrator keys determine who actually controls it. The label does not give it a universal legal status.
An oracle supplies outside information, such as a price. A bridge connects activity or assets across networks under particular verification and custody assumptions. Both can become critical dependencies.
Applications can compose: one contract uses another’s token or service. This is powerful because developers can reuse existing pieces. It is fragile when many applications rely on the same failing price feed, collateral asset, bridge, or administrator. Trace those connections before treating a polished interface as an independent system.
Different interfaces can share one oracle. The same idea applies to collateral, bridges, and administrators.
The idea to keep
An application’s usefulness comes from a service it provides. Its safety depends on the whole chain of code, collateral, information, and control behind that service.