What people built with shared programs.

A dollar-like token still needs backing.

Suppose Maya wants to send a token that stays close to one U.S. dollar. A token designed to follow a target value is called a stablecoin. The target is an aim, not a promise that every holder can always sell or redeem it for a dollar.

In one design, an issuer holds reserves such as cash and short-term government debt. Redeeming means returning tokens to the issuer in exchange for the promised money. Maya needs to know both what the issuer holds and whether its terms let her redeem.

The blockchain can show that Maya holds tokens. That record does not prove the issuer has enough reserves or will return money to her. Some issuers can also freeze tokens through controls in the contract.

Other designs pledge crypto assets to support the tokens issued. The pledged assets are collateral. They often need to be worth more than the stablecoins created, leaving some room for a price fall.

If that collateral loses too much value, the system may sell or seize it under its rules. The token’s stability then depends on prices, collateral, and whether those rules work. Some stablecoins mix more than one approach.

An algorithmic design tries to hold its target by changing supply or giving traders incentives. It may depend on another token whose price can move sharply. If confidence and backing fall together, the mechanism can fail. A formula alone is not a reserve of dollars.

These tokens can make transfers and keeping accounts on a blockchain easier. They still involve network fees, possible limits on redemption, public transaction records, and sanctions controls. An issuer that holds bank reserves also depends on its banking connections.

Pledge an asset to borrow another.

Maya holds an asset but wants a different token for a short-term payment. She could sell part of what she owns. A lending app offers another route: pledge the asset and borrow the token she wants.

Apps such as Aave and Compound connect supplied assets with borrowers who pay interest. A common design requires the borrower to pledge collateral worth more than the loan.

Borrowing lets Maya keep exposure to the pledged asset’s price instead of selling it immediately. But the asset is tied to the loan. It is not also a pile of savings she can freely spend.

She must repay the debt and pay interest. If the collateral falls too far in value, the rules can sell or seize some of it to repay debt. This is called liquidation. Wanting to keep the asset does not stop those rules.

The app needs a current price to check the collateral. It gets this from a price feed. Some systems give a payment or discount to the person who carries out a permitted liquidation.

The collateral and borrowed token are different assets. To compare them, measure both in the same unit of value, just as you could state the value of two different goods in dollars. The example below uses made-up value units, not a count of either token.

Use a fictional loan to see the boundary. Maya owes 100 units. This model compares the debt with 80 percent of the collateral’s value. It does not include interest or penalties.

First, let the collateral be worth 150 units. Multiply 150 by 0.80 to get 120. Debt of 100 is below that amount, so the position has room under this rule.

Now let the collateral fall to 120 units. Multiply 120 by 0.80 to get 96. The debt is still 100, which is above 96. The position can now be liquidated in the model even though Maya did not borrow more.

The exact boundary is 125 units of collateral: 125 × 0.80 = 100. At that point, a further price fall or debt increase would cross the model’s boundary.

We can also divide the boundary amount by the debt. With collateral worth 150, that calculation is 120 ÷ 100 = 1.2. The boundary amount is 1.2 times the debt. The model calls this number the Health ratio.

With collateral worth 120, the same calculation is 96 ÷ 100 = 0.96. A ratio below 1 means the boundary amount is smaller than the debt, so liquidation can be triggered.

At collateral value 125, the calculation is 100 ÷ 100 = 1. That is this model’s exact boundary. The ratio has no currency unit: it compares two amounts measured in the same unit of value.

A real app has its own thresholds, interest, penalties, and safeguards. Its limit for opening a loan may be stricter than its later liquidation threshold. This example explains only the liquidation test; it is not a product’s borrowing rule or a reason Maya should borrow.

Unlike an unsecured bank loan, this arrangement does not rely on a person offering another month to pay. The code may act automatically while its price feed and the people who can change it still introduce risks. Maya needs a repayment plan before spending the borrowed token.

Who pays the advertised income?

An app may advertise income as yield. Before comparing the rate, ask where the payment comes from. A borrower may pay interest. A trader may pay a fee. A project may issue new reward tokens.

Those sources are different. A fee comes from someone using a service. A new reward token may lose value, and issuing more tokens may reduce each existing holder’s share of the supply.

Also count what the recipient gives up or risks. Trading fees can be smaller than losses from a changing mix of assets. Operating costs or a failed contract can also exceed the income. Calling a rate “real yield” does not make the final result safe.

An automated market maker lets traders exchange against assets already held in a shared pool. People who supply those assets may earn fees. But when traders take one token and put in another, the suppliers’ holdings change.

The next three lessons explain that pool and its risks. Keep asking: who pays, what service do they receive, and what costs or losses could be larger than the payments?

Two apps can share the same weak point.

Other apps use distinct token records called NFTs. An NFT might support a ticket, a name, or a credential. The linked file, legal rights, and acceptance in the real world still need separate arrangements. A token alone cannot prove that a physical item is authentic.

A DAO helps people coordinate using proposals, voting, and rules for shared funds. To understand who controls it, look at voting weight, participation, delegated votes, and administrator keys. The name alone does not give every DAO the same legal status.

Apps may need outside information, such as a market price. A system that supplies it is called an oracle. Maya’s loan relies on one when it checks the price of her collateral.

An app may also use a bridge to connect assets or messages across networks. Its safety depends on how it checks those messages and who controls any held assets.

One contract can use another contract’s token or service. This is useful because developers can build with pieces that already exist. But the connection also passes on risk.

Suppose two lending apps use the same price feed. If that feed fails, both may lose reliable prices. Separate websites do not make the shared feed independent. The same issue can arise with shared collateral, a bridge, or an administrator.

Maya’s loan depended on a collateral price. Opening a second lending app would not remove that risk if it used the same feed. Follow the connections behind each screen before treating two apps as two independent systems.