DAOs, Governance, Oracles and Audit Limits

Governance, data and code review shape what an application can do after you begin using it. A vote may be advisory, an oracle may be stale and an audit may cover an old version. This lesson examines those boundaries together and asks what remains unknown even after a reassuring review report.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

Follow a DAO proposal through execution

The DeFi dependency lesson in Level 6 covered governance tokens, voting concentration and treasury basics; this section adds the machinery and the law.

Think of a sailing club in İzmir. A motion is debated, passes only if enough members vote, and the treasurer waits a notice period before paying, with two signatures on every cheque.

A typical DAO copies those steps in code. An idea is debated on a public forum, often tested with an off-chain poll, then submitted as an on-chain proposal holding the exact transactions to run. Holders or delegates vote within a fixed window, and it passes only with a quorum, a minimum number of votes. A timelock (the DeFi dependency lesson in Level 6) then delays it so dissenters can leave. Finally a contract executes it, or a multisig of named members carries out an off-chain vote. Whoever executes controls the treasury.

The club analogy stops at the law: a registered club has a legal identity that can sign contracts and limit what members owe, and many DAOs have none.

Wyoming's 2021 law lets a DAO register as a limited liability company (LLC). Others use foundations or purpose trusts in offshore centres such as the Cayman Islands, or nonprofit associations in some US states; the protection each gives depends on the law and the facts. In July 2024 the Law Commission of England and Wales warned that DAOs can expose participants to significant legal liabilities.

The Ooki DAO case shows why. In September 2022 the US Commodity Futures Trading Commission (CFTC) sued it as an unincorporated association of token holders who had voted. In June 2023 a federal court held that the DAO could be sued as a "person", imposed a US$643,542 penalty and ordered its website shut down. The CFTC said it would not enforce the judgment against individual holders, but voters' personal liability remains unsettled.

The risks follow the pipeline. Governance capture happens when a large or borrowed holding controls the vote, as at Beanstalk. Low turnout lets a small group decide. A treasury raid sends funds to insiders or attackers, and a timelock helps only if someone is watching. Unclear liability means voters may not know what they could owe. Next, separate what a vote can authorise from the legal rights it grants.

A proposal may require eligibility, quorum and a vote threshold. Execution may occur automatically or through a committee, multi-signature account or administrator. A forum vote may not bind a contract, and an emergency power may bypass normal timing. A timelock can delay a change, but it does not ensure that every user sees the notice or can exit.

Voting rights and legal status

A governance token can grant specified protocol participation without granting company ownership, guaranteed distributions or the legal protections of a share. A DAO's legal status and participant liability depend on jurisdiction and arrangement. The existence of on-chain voting does not resolve those questions automatically.

Check the token's terms and the organisation's disclosed structure. Treasury decisions may benefit a protocol without paying every holder. A promise that the community owns everything needs precise documentation of ownership, control and enforceable rights. Keep technical voting authority separate from outside legal entitlement. This prevents governance enthusiasm from replacing the rights analysis learned at Level 0 and Level 5.

Understand the oracle problem

Think about a thermostat in a flat in Sydney. It controls the heating perfectly, but only if its temperature sensor tells the truth. Put a match next to the sensor and the "smart" system makes a bad decision with total confidence.

A smart contract is that thermostat. ethereum.org explains the oracle problem: a blockchain cannot fetch outside data on its own, and that isolation is deliberate, because every node must reach the same answer from data they all hold. But a lending app needs a price, an insurance contract needs the weather, and a game needs a random number. An oracle, which you met in the DeFi dependency lesson in Level 6, brings that information on-chain.

The problem is that a contract is only as trustworthy as its inputs. ethereum.org sets out three tests for an oracle: correctness (the data is authentic and unaltered), availability (it arrives on time) and incentive compatibility (honest reporting is rewarded and false reporting is punished). A single centralised oracle is weak on all three: even a reputable provider can be hacked or go rogue, and it becomes a single point of failure.

The thermostat analogy has a limit. A faulty sensor in a flat wastes some heat. A faulty price in a lending app can trigger liquidations or let someone borrow against worthless collateral in seconds, as the Mango Markets case in the DeFi dependency lesson in Level 6 showed.

See how oracle networks reduce manipulation

If one reporter can lie, ask many and compare. That is the idea behind a decentralised oracle network. ethereum.org describes many independent nodes that each query outside data, compare several sources and agree on one answer before it goes on-chain. It names Chainlink as an example and describes the median used by Maker's oracles.

Oracle networks reduce risk but do not remove it. Many nodes reading the same weak source still report a weak price, so thinly traded tokens remain dangerous inputs. Some protocols also use a time-weighted average price (TWAP), which averages a price over a period so that a brief spike moves it less, at the cost of reacting slowly to genuine moves. And, like a bridge, an oracle network adds its own trust assumption: you rely on its operators and their incentives.

If the inputs need checking, so does the code that uses them, which is the job of an audit.

A spot pool used as a price source may be vulnerable to thin liquidity or short-lived manipulation depending on its design. Several feeds can share underlying sources, so counting sources does not alone prove independence. Connect the data policy to the exact lending or trading action rather than describing the oracle as simply reputable.

Know what an audit promises and what it doesn't

Think about a building inspection before you buy a flat in Toronto. The inspector checks the rooms you agreed on, on the day of the visit, and writes down what they found. They do not promise the roof will never leak, and they cannot inspect an extension built next year.

A smart-contract audit works the same way. OpenZeppelin, a security firm, describes its process: confirm the exact code version and scope, have at least two auditors review it line by line with automated tools, report findings by severity, then review the team's fixes. ethereum.org is blunter: it says to avoid treating audits as a "silver bullet", because they won't catch every bug.

Reading the report takes a few minutes once you know what to look for.

Read an audit report summary

Most reports open with a summary you can read without understanding the code. Answer five questions: who audited it, when, what was in scope, what was found, and what was fixed.

OpenZeppelin's reports classify findings by severity: critical, high, medium, low and informational (notes on style or best practice). Reports commonly record what happened to each finding, for example fixed, partly fixed or acknowledged (accepted without change).

Two more checks help: the report should name a code commit or contract addresses you can match, and the auditor's own site should list the report, since fake reports and fake badges exist. Two other tools look at code differently.

Add bug bounties and formal verification

A bug bounty is a standing reward for anyone who finds a flaw and reports it privately. Think of a museum in Florence paying visitors who spot a broken alarm instead of using it. ethereum.org explains that good bounties scale the reward with the funds at risk, so that reporting pays better than exploiting. It describes a white-hat researcher who found an "infinite money" bug in Optimism and was paid a bounty instead of draining funds.

Formal verification goes further than testing. ethereum.org describes it as writing a precise, mathematical specification of what the contract must do, such as "no balance can ever go below zero", and then proving that the code satisfies the specified properties within the model and its assumptions. That proof is powerful, but only as good as the specification: a property nobody wrote down is never checked, and nothing off-chain is covered.

Next, turn the question round: what can others learn about you from a public blockchain?

Find the reviewed code commit or version, scope, date, methods, findings and assumptions. A report may exclude external dependencies, economic design or deployment procedures. Test results apply to the tested conditions and cannot certify every future interaction. Ask what an audit establishes rather than whether an audit exists. A report covering a bridge contract does not necessarily assess every signer, reserve or recipient token.

An exploit response can include pauses, upgrades, disclosures or attempted recovery. Each depends on available powers and the nature of the loss. A rapid response can limit harm while revealing concentrated control. Document both aspects rather than assuming emergency authority is always good or always bad. Check whether recovery claims are confirmed by primary evidence.

Public records can expose financial relationships when addresses are linked to people. Governance participation, donations or repeated transfers can add information to that link. Avoid publishing personal addresses in a course dossier. Finish the review by stating unknowns: unreviewed upgrades, opaque authorities, unavailable data or uncertain legal claims. The next lesson evaluates products and regulation using the same scope discipline.

Understand pseudonymity and chain analysis

Imagine a public noticeboard in Manchester where every payment is pinned up forever, signed with a nickname. Nobody knows who "BlueFox" is, until BlueFox collects a parcel and shows ID. From then on, every note signed BlueFox has a face.

Public blockchains are that noticeboard. Addresses are pseudonymous: not your name, but permanently visible and linkable. Bitcoin's design, Chainalysis notes, is a balance between privacy and transparency. Chain analysis firms group addresses that seem to belong together and match them with known services. The moment funds touch an exchange that checks identity (the provider checking lessons in Level 3), the link between a nickname and a person can appear. You saw in the on-chain and sentiment lessons in Level 7 that such clustering can also be wrong.

This matters for safety as much as privacy. The security lessons in Level 2 warned against advertising your holdings, because anyone who links your address to you can see your balance. To weaken those links, some people turn to mixers.

Understand privacy tools and changing legal rules

Privacy tools try to make links between deposits, withdrawals or participants harder to infer. A mixer may pool activity; privacy-focused assets can use protocol features that conceal particular information. None guarantees anonymity against every observer, device compromise or analysis method.

These tools also have operational and legal consequences. A provider may ask additional source-of-funds questions or restrict a supported asset. Sanctions, court decisions and listing policies can change. Read the current official notice for the exact jurisdiction and service instead of relying on an old timeline.

This course requires understanding and research only. It does not require using a mixer, bypassing controls or publishing your financial addresses. A useful privacy plan can begin with limiting disclosure, checking what is public and understanding the records a service already keeps.

Know why privacy coins are delisted

A service can delist an asset for legal, compliance, commercial or technical reasons. A delisting announcement is about that provider's supported route; it does not by itself determine the asset's status everywhere.

A delisted holding can remain recorded on its network while becoming harder to sell or withdraw through the chosen service. Record liquidity, custody and technical access separately. Avoid adopting current country-by-country restrictions from a dated secondary article.

Research a protocol on chain step by step

Before buying a used car in Busan, a careful buyer matches the number plate to the papers, checks who else holds a key and reads the service history. Researching a token works the same way, except that no registry certifies the answers: you compare sources yourself.

A fixed routine stops you skipping a step when a token looks exciting. The token research lesson in Level 5 gave you the red flags to look for. The on-chain and sentiment lessons in Level 7 showed what on-chain metrics can and cannot prove.

Step 1 comes first because anyone can create a token with the same name and symbol as a real one; only the address is unique. Step 3 needs the most care. Etherscan explains that a proxy passes every call to a separate implementation contract, which can be swapped while the address stays the same (proxies and admin keys appeared in the DeFi dependency lesson in Level 6). It also warns that its "Read as Proxy" view cannot prove the code shown is the code that runs. So "verified" tells you what the code says today, not who can change it tomorrow.

Step 6 repeats the questions Fatima asked earlier. Write every finding, with its source and the date you checked, into the token research template in the valuation and graduation lessons in Level 10's graduation project, and write "unknown" wherever you could not check.

With a routine for gathering evidence, you are ready to practise weighing it.

Try the following questions aloud or on paper before opening the worked answers. Compare your reasoning as well as your final answer.

References and further reading