blog.alankrit.net

Tag: smart contracts

  • Day 25 — How Can a Crypto Treasury Avoid One Dangerous Key?

    Watercolor illustration of several trusted signers jointly unlocking a multisignature crypto treasury

    A normal crypto wallet may be controlled by one private key. That is wonderfully simple until the key is lost, stolen, or held by one person who should not have unlimited power. A multisignature wallet replaces that single point of failure with a shared approval rule.

    A multisig can be configured as two-of-three, three-of-five, or another threshold. In a two-of-three wallet, any two authorised signers must approve a transaction before it executes. One lost key does not freeze the funds, and one compromised signer cannot move them alone.

    This structure is useful for company treasuries, DAOs, investment groups, and even families. Different people or hardware wallets can hold the signer keys. A payment can be proposed, reviewed by others, and executed only after enough independent approvals are recorded.

    Multisig does not remove trust; it distributes it. If enough signers collude, they can still take the funds. If too many keys are lost, the required threshold cannot be reached. Signers may also approve a malicious transaction without understanding it, so clear operating procedures matter as much as the contract.

    Good setups separate keys across devices and locations, document how signers verify destinations, test recovery with small amounts, and plan how signers can be replaced. The threshold should balance security with the practical ability to act during an emergency. Five approvals may sound safer until two people are unreachable.

    Over these first twenty-five days, we moved from the basic problem of digital trust to blocks, mining, consensus, Ethereum, smart contracts, wallets, tokens, DeFi, and community governance. Multisig ties many of those ideas together: cryptographic signatures, programmable rules, transparent execution, and human coordination.

    The larger lesson is that blockchain does not make trust disappear. It lets us define who must agree, what rules they must follow, and which evidence everyone can verify. That is a strong foundation for the next stage of learning, where we can examine upgrades, scaling, bridges, privacy, and the harder trade-offs behind real systems.

  • Day 24 — Can an Online Community Run an Organisation?

    Watercolor illustration of a DAO community voting on proposals around a shared treasury

    A decentralised autonomous organisation, or DAO, is an attempt to coordinate people and shared resources using blockchain-based rules. Instead of every decision being made by a traditional management hierarchy, members can create proposals, vote, and direct a treasury through smart contracts.

    Many DAOs use governance tokens. A holder may vote on protocol fees, upgrades, grants, or which assets a treasury should hold. Proposals often move through discussion, a formal vote, and then execution. Some systems execute successful votes automatically; others rely on a committee or multisignature wallet.

    The word autonomous can be overstated. Writing proposals, evaluating trade-offs, maintaining software, and negotiating partnerships remain human work. Smart contracts can enforce a voting process and treasury rule, but they cannot decide what a community should value.

    Token voting also does not guarantee equal power. Wealthy holders, founders, investors, or exchanges may control a large share of votes. Participation is often low, so a small organised group can outweigh thousands of passive members. Delegation helps people assign their votes to informed representatives, while creating its own centres of influence.

    Governance has technical risks as well. Attackers may borrow voting power, exploit poorly written execution code, or rush harmful proposals through inattentive communities. Sensible systems use proposal thresholds, voting delays, timelocks, transparent delegates, and emergency procedures, though every safeguard adds friction or trust.

    A strong DAO is therefore more than a token and a chat group. It needs clear scope, reliable information, accountable contributors, conflict resolution, and a treasury process people can audit. The blockchain records decisions; community culture determines whether those decisions are thoughtful.

    Large treasuries rarely let one person hold the only key. Tomorrow, on Day 25, we will close this first arc with the multisignature wallet—a simple tool for turning shared responsibility into an enforceable rule.

  • Day 22 — What Happens When a DeFi Loan Becomes Unsafe?

    Watercolor illustration of a DeFi loan health meter triggering collateral liquidation

    A DeFi loan begins with more collateral value than debt, but crypto prices can move quickly. If the collateral falls far enough, the protocol cannot wait for a human conversation or a monthly payment. Its smart contracts enforce a liquidation rule.

    Each market defines a threshold that determines how much borrowing a particular asset can support. Interfaces may summarise the buffer as a health factor. A comfortable value means the collateral can absorb some decline; a value near the limit means even a small price move may make the position eligible for liquidation.

    When the threshold is crossed, an independent liquidator can repay part of the borrower’s debt and receive some collateral, usually with a bonus. That reward motivates bots to act quickly. The protocol reduces risky debt, lenders remain better protected, and the borrower loses collateral plus a penalty.

    Consider ether collateral worth $1,500 against an $800 loan. If ether falls and the permitted borrowing limit drops below the debt, liquidation can begin. Adding collateral or repaying part of the loan before that point restores the safety margin. Watching only the original deposit price is not enough because the relevant values update continuously.

    Liquidation depends heavily on price oracles. A delayed or manipulated price can liquidate healthy users or leave the protocol with bad debt. Network congestion also matters: when many positions fail together, gas costs rise and liquidators may struggle to process them quickly.

    Borrowers can reduce risk by using less leverage, choosing strong collateral, maintaining a wide buffer, monitoring alerts, and understanding the exact threshold and penalty. There is no universal safe ratio because volatility, oracle design, and protocol rules differ.

    Liquidations show that attractive borrowing and lending rates come from a system of incentives and risk controls. Tomorrow we will ask the broader question behind every advertised return: where does crypto yield actually come from?

  • Day 21 — How Can DeFi Lend Money Without a Credit Score?

    Watercolor illustration of borrowers and lenders connected through an overcollateralized DeFi lending pool

    A bank can evaluate salary, identity, and repayment history before making a loan. A public blockchain usually does not know those facts. DeFi lending therefore relies on a different protection: borrowers commonly lock collateral worth more than the amount they borrow.

    Lenders deposit assets into a smart-contract pool. Borrowers draw from that shared pool after supplying acceptable collateral. The protocol records deposits, debts, interest, and collateral ratios on-chain, while its rules apply equally to any wallet that can submit a valid transaction.

    Imagine depositing ether worth $1,500 and borrowing $800 in stablecoins. You still benefit if ether rises, and you gain spendable stablecoins without selling it. But if ether falls, the safety margin shrinks. Borrowing the maximum allowed amount leaves very little room for market movement.

    Interest rates are often driven by utilisation. When most of a pool is available, borrowing can be cheap. As more assets are borrowed and liquidity becomes scarce, rates rise to encourage repayment and attract new deposits. The exact curve is code defined by each protocol.

    This system makes loans fast and transparent, but it is not unsecured credit. Overcollateralisation protects lenders precisely because the protocol cannot chase an anonymous borrower later. It also means borrowers already need valuable assets, so DeFi lending does not solve every financial access problem.

    Depositors face risks too: smart-contract bugs, bad collateral, oracle failures, governance changes, and periods when withdrawals are constrained because too much of the pool is borrowed. A displayed supply rate can change rapidly and is not the same as a guaranteed bank deposit.

    If collateral can fall below the safe level, the protocol needs a way to act before the loan becomes undercollateralised. Tomorrow we will examine liquidation—the automatic process that protects the pool but can be painful for borrowers.

  • Day 19 — How Can You Trade Without an Order Book?

    Watercolor illustration of an automated market maker balancing two token reserves in a liquidity pool

    A traditional exchange keeps an order book: buyers state the price they will pay, sellers state the price they will accept, and the exchange matches them. Many decentralised exchanges use a different machine called an automated market maker, or AMM.

    An AMM stores two assets in a smart contract called a liquidity pool. Imagine a pool containing ether and a stablecoin. A trader who wants ether adds stablecoins to the pool and removes some ether. The contract calculates the amount using a mathematical rule instead of waiting for a specific seller.

    A common simplified rule is x multiplied by y equals k. Here x and y are the quantities of the two assets, while k should remain roughly constant after a trade, before fees. When ether becomes scarcer in the pool, the formula makes each additional unit more expensive. The pool’s ratio therefore moves as people trade.

    The displayed price is not an opinion formed by the contract. It emerges from the current reserves. If the AMM price differs from larger markets, arbitrage traders buy from the cheaper place and sell to the expensive one. Their transactions push the pool back toward the wider market price.

    Large trades move the reserve ratio more than small trades. The difference between the expected price and the executed price is called slippage. Deep pools usually produce lower slippage, while a thin pool can move dramatically from a modest transaction. Slippage limits protect users from accepting a much worse result than expected.

    AMMs make always-available on-chain trading possible, but their contracts, tokens, and pools still carry risk. A fake token can use a familiar symbol, a pool can be too shallow to exit safely, and a poorly chosen slippage setting can invite manipulation or failed transactions.

    The pool clearly needs assets before anyone can trade. Tomorrow we will meet the liquidity providers who deposit those assets, collect fees, and take on a less obvious risk called impermanent loss.

  • Day 18 — What Is DeFi If There Is No Bank Behind It?

    Watercolor illustration of open financial services connected through decentralized smart contracts

    Traditional finance organises payments, exchanges, loans, and savings through institutions. Decentralised finance, or DeFi, rebuilds some of those functions with smart contracts on public blockchains. The contracts hold assets and apply rules that users can inspect and invoke with a wallet.

    A DeFi application might let you swap one token for another, lend assets to a shared pool, borrow against collateral, or earn fees by supplying liquidity. There may still be teams, websites, governance groups, and service providers, but the settlement logic and balances are recorded on-chain.

    Its defining feature is open access to the contracts. A compatible wallet can interact without opening a conventional account, and another developer can connect one protocol to another. This composability is often compared to building with money legos: a lending position can become collateral elsewhere, while a trading pool supplies a price or yield source.

    Composability creates efficiency, but also dependency. If one protocol has a bug, a bad price feed, or a failing asset, the effects can travel through every application built on top of it. Transparent code lets anyone inspect the rules, yet it also lets attackers study those rules and search for weaknesses.

    DeFi does not remove intermediaries so much as replace some human discretion with software, incentives, and governance. Users take responsibility for private keys, transaction approvals, network fees, and contract risk. Returns are not protected merely because a dashboard uses the word earn.

    Before depositing, it helps to ask where the return comes from, who can change the contracts, what assets back the position, how withdrawals work, and what happens during a market shock. Audits, long operating history, and diversified risk are useful signals, not guarantees.

    The simplest DeFi action is often a token swap. But without a traditional exchange matching buyers and sellers, who provides the other side of that trade? Tomorrow we will unpack the automated market maker.

  • Day 16 — How Can a Blockchain Know What Happened Outside It?

    Watercolor illustration of an oracle bridge carrying real-world data onto a blockchain

    Blockchains are good at agreeing about information already inside their own system. Every node can verify a signature, a balance, or the result of contract code. But a smart contract cannot simply open a news website and ask for today’s gold price.

    That restriction is deliberate. If thousands of nodes fetched a web page independently, they might receive different answers because of timing, location, or a changed server response. The network would no longer have one deterministic result. Smart contracts therefore need data to be delivered to them in a form the blockchain can agree on.

    An oracle is the bridge that supplies this outside information. It can publish asset prices, weather measurements, sports results, proof of reserves, or other facts. A DeFi lending market, for example, may use an oracle price to decide how much a borrower’s collateral is worth.

    A single data source creates a dangerous point of failure. If it is wrong, delayed, hacked, or manipulated, the contract may execute perfectly using bad information. Decentralised oracle networks try to reduce this risk by collecting reports from multiple providers and combining them according to transparent rules.

    Even then, the oracle problem does not disappear. Someone must decide which sources count, how often updates occur, what happens during extreme markets, and how disputes are handled. The security of an application is only as strong as the data and assumptions on which its contracts depend.

    Oracle failures can be expensive because blockchain actions are difficult to reverse. Attackers have manipulated thin-market prices, borrowed against inflated collateral, and drained protocols before prices returned to normal. Sensible designs use several sources, time-weighted prices, update limits, and emergency controls.

    Oracles make real-world financial products possible on-chain. One widely used product is a token designed to follow a familiar price, usually one US dollar. Tomorrow we will ask what actually keeps a stablecoin stable.

  • Day 15 — What Actually Makes an App a dApp?

    Watercolor illustration of a user interface connecting a wallet to decentralized smart contracts

    A decentralised application, or dApp, can look just like any other website. It may have buttons, forms, charts, and a familiar login screen. The difference is not mainly visual; it lies in where the important rules and records live.

    A typical dApp has three layers. The frontend is the website or mobile interface. A wallet connects the user’s account and signs instructions. Smart contracts on a blockchain hold the shared state and enforce the core rules. The interface might say Swap, but the contract determines what assets move and under which conditions.

    Reading from a dApp can be almost invisible. The website asks a node for contract data and displays balances or prices. Writing is different: changing blockchain state requires a transaction. Your wallet shows what is being requested, you sign it, the network executes it, and gas is paid even if the transaction later fails.

    Decentralisation is not an all-or-nothing label. A contract may be immutable while its website is hosted by one company. Its data may depend on a centralised server, or an administrator may retain an upgrade key. A useful evaluation asks which parts can be censored, changed, or switched off—and by whom.

    Wallet-based access removes the need to create a new username and password for every service, but it changes the security model. A signature can authorise a harmless login, a token approval, or a valuable transfer. Users must understand the request because there may be no support desk capable of reversing a mistaken signature.

    Good dApps make these boundaries clear: they show contract addresses, transaction details, risks, and the source of external data. Open contracts can be inspected and reused, but open code does not mean bug-free code. Audits help; they never turn software into a guarantee.

    One puzzle remains. A smart contract can read blockchain data, but how can a lending app learn the rupee price of ether or whether it rained in Delhi? Tomorrow we meet the bridge called an oracle.

  • Day 14 — What Makes an NFT Different From an Ordinary Token?

    Watercolor illustration of unique numbered digital certificates represented by NFTs

    An ordinary token is designed so that one unit can replace another. An NFT does the opposite: it gives each item a distinct identity. NFT stands for non-fungible token, and its most important feature is usually a unique token ID recorded by a smart contract.

    Think of cinema tickets. Two tickets may have the same price, but seat A1 is not the same as seat F12. An NFT contract can record that wallet 0xABC owns token number 42, while another wallet owns token number 43. Transferring the NFT updates that ownership record on the blockchain.

    The artwork, video, or document associated with an NFT is often not stored directly on Ethereum because large files are expensive to keep on-chain. The token usually points to metadata, and that metadata may point to a file on IPFS or a conventional server. This distinction matters: the blockchain can preserve the ownership record while the linked media may still depend on outside storage.

    Owning an NFT also does not automatically mean owning the copyright. A token can prove that a wallet controls a particular on-chain item, but intellectual-property rights depend on the licence or agreement provided by the creator. Buying a digital collectible is not necessarily permission to reproduce its artwork commercially.

    NFTs can represent more than profile pictures. They can act as event tickets, game items, membership passes, certificates, or records tied to physical goods. Whether blockchain adds value depends on whether public transferability and shared verification are actually useful for that case.

    The risks are familiar but easy to overlook: copied artwork, misleading collections, malicious approvals, changing metadata, and thin markets. A visible image is not proof of authenticity. Users should verify the contract address, collection history, storage method, and permissions they are signing.

    A token can therefore become a portable piece of state that many applications recognise. Tomorrow, let us examine those applications themselves: what makes a dApp decentralised when its website can still look completely ordinary?

  • Day 13 — Is Every Crypto Token Its Own Blockchain?

    Watercolor illustration of many tokens recorded inside one Ethereum smart contract

    Open a crypto wallet and you may see ether, stablecoins, governance tokens, and dozens of other assets. It is natural to assume that every token runs on its own blockchain. In reality, many of them are programs living on an existing network such as Ethereum.

    A token is usually a smart contract that maintains a ledger. The contract records how many units each address owns and contains rules for transferring those units. When Priya sends ten tokens to Arjun, no separate coin travels through the internet. Ethereum executes the token contract, subtracts ten from Priya’s recorded balance, and adds ten to Arjun’s.

    Most fungible Ethereum tokens follow a common interface called ERC-20. It specifies familiar actions such as checking a balance, transferring tokens, and allowing another contract to spend a limited amount. Because wallets and exchanges understand the same interface, a newly created token can be displayed and handled without every application learning an entirely new language.

    Fungible means one unit is intended to be interchangeable with another, like one ₹10 coin for another ₹10 coin. Such tokens can represent voting power, access to a service, a claim on collateral, or simply a speculative asset. The code defines the mechanics, but it does not guarantee that the story or value behind the token is genuine.

    Creating a token is easy; trusting one is not. Two tokens may share the same name and symbol, so the contract address is the reliable identifier. Before interacting, it is worth checking who can mint more supply, pause transfers, blacklist addresses, or upgrade the contract. Those permissions can matter more than the logo.

    Token transfers also use the underlying network. On Ethereum, users still need ether to pay gas even when they are sending a different token. The token depends on Ethereum for ordering, security, and execution; it is not an independent blockchain.

    But what if every unit should not be identical? Tomorrow we will look at NFTs, where ownership is tracked by a unique token ID rather than only by a quantity.