Moral Hazard is a game-theoretic streaming experiment built on Superfluid.
It's a playable version of the economics concept it's named after: every player hopes for a surplus that only the other players' decisions can deliver. Real economic consequences, designed in the open, powered by Superfluid's money streaming.
You take a side — Good or Bad — and your outcome plays out continuously, on-chain, in front of everyone.

Picking your side is framed by the question: “Do you think humans are, in general: Good or Bad?” — Good stands for stability, Bad for chaos.

Two sides compete:

• Good side
  One participant at a time claims the Good Spot by transferring the asked amount. In return, they receive the aggregate stream of all Bad streamers.
• Bad side
  Any number of players stream tokens continuously into the game-contract. They receive a proportional share of every future good-spot claim via a distribution pool.

The core tension:
Good holders want to hold their position long enough to break even from incoming streams. Bad streamers want frequent ownership changes, since they receive a distribution share every time someone new claims the Good Spot.

Here are the core concepts you'll encounter throughout this FAQ and the rest of the app:

Blockchain
A public, decentralized ledger that records every transaction. No single company controls it. Moral Hazard runs on EVM-compatible blockchains (Ethereum Virtual Machine) — a family of networks that all speak the same smart contract language. Examples include Ethereum, Base, Optimism, Polygon, and GnosisChain.

Wallet
Software that holds your private keys and lets you sign transactions. Think of it as your identity and bank account on the blockchain. Popular options include MetaMask (browser extension), Rainbow, and Coinbase Wallet. When a site says “connect your wallet,” it means linking your wallet so the app can read your address and request signatures — it cannot spend your tokens without your approval.

Tokens
Tokens are digital assets on a blockchain. Most follow the ERC-20 standard, which makes them interoperable across apps. Moral Hazard uses Super Tokens — a special wrapper provided by Superfluid that enables real-time streaming. You wrap regular tokens into Super Tokens before participating, and can unwrap them back at any time. Native Super Tokens don't require wrapping/unwrapping anymore.

Smart contract
A program deployed on the blockchain that runs automatically when called. Once deployed, the code is public and immutable — nobody (including the creator) can change the rules afterwards. Moral Hazard's entire game logic lives in smart contracts. The admin can adjust parameters, but the core rules are enforced by the contract itself.

Transactions & gas
Every action on the blockchain (claiming, starting a stream, etc.) is a transaction. Each transaction costs a small fee called “gas,” paid in the chain's native currency (e.g. ETH on Ethereum, or xDai on GnosisChain). Gas goes to the network validators, not to Moral Hazard.

Testnet vs. mainnet
A testnet is a practice blockchain where tokens have no real value — perfect for learning, building and testing. A mainnet is the real network where tokens have real monetary value. Moral Hazard offers a risk-free game on the Base Sepolia Testnet to get familiar with the core mechanics. (see how to participate).

NFT (Non-Fungible Token)
A unique, non-interchangeable token that proves ownership of something on-chain. Moral Hazard issues NFTs to mark your position in the game — a GoodNFT for the Good Spot holder and BadNFTs for streamers.

Block explorer
A website that lets you look up any transaction, address, or contract on the blockchain. Think of it as the blockchain's public search engine. Every action in Moral Hazard can be independently verified on a block explorer.

Superfluid is a protocol for real-time token streaming on EVM blockchains. Instead of sending tokens in one-off transactions, Superfluid enables continuous, per-second flows of tokens between addresses.

Moral Hazard uses two Superfluid primitives:

• CFA (Constant Flow Agreement)
  continuous streams from Bad players to the Good Spot holder, plus the donation stream.
• GDA (General Distribution Agreement)
  one-to-many pool that distributes claim payments proportionally to all eligible Bad streamers.

Superfluid streams require “Super Tokens” — wrapped versions of standard ERC-20 tokens that support streaming. You need these to participate. See how to get supported tokens.

A lot of blockchain apps re-implement something that already worked without one. Superfluid is one of the rare exceptions: continuous money streaming — value moving every second, by the second, with no per-payment transaction — is a primitive that is only really practical on-chain. It's a genuine case where the technology enables a capability that simply wasn't doable before, rather than dressing up an old one.

The hope is simple: by making streaming tangible and a little playful, Moral Hazard helps people internalize what streamable assets can do — and, ideally, inspires the next ideas built on the Superfluid protocol.

To participate you'll need:

1. A web3 wallet (MetaMask, Rainbow, Coinbase Wallet, etc.)
2. A bit of the native token/coin of the blockchain you want to participate on, to pay the gas fees.
3. Super Tokens on a supported chain (e.g. USDCx on Base)
4. Enough tokens to cover your stream rate + deposit (Bad side) or the asked amount (Good side)

Want to try risk-free?
Try it with fUSDCx (Super fUSDC Fake Token) on the Base Sepolia Testnet — for that token, a guide is in place that lets you mint free test tokens (and provides some ETH to pay for gas if you don't have any yet.)

The Good Spot is held by one player at a time. To claim it, you transfer the current asked amount. In return, you receive the aggregate stream of all Bad players flowing into the contract.

• When you claim, 1.337% of your claim transfer goes as a protocol fee to the project wallet. The rest goes to the distribution pool for Bad streamers.
• The next asked amount automatically increases by exactly 1% from what you transferred. Once you've broken even, price decay gradually eases it back down.
• You hold the position until someone else claims it from you (or the game is paused for an emergency).
• "Break-even" occurs when the total streams you've received equal or exceed what you transferred to claim.
  After that point, holding the good spot turns net-positive.
• A transferable ERC-721 NFT (GoodNFT) represents your ownership. Transferring the NFT also transfers the incoming streams.

View the Good Spot · Risks

Bad streamers open a continuous token stream into the contract at a rate they choose. This stream flows to whoever currently holds the Good Spot (minus the 1.337% donation split).

• When someone claims the Good Spot, the amount transferred gets distributed proportionally to all active Bad streamers via the GDA pool.
• Your share of each distribution depends on your pool units (allocated when you have an active deposit) - calculated based on your flowrate relative to the flowrate of all other bad streamers.
• You must lock a deposit (reclaimable after locking period) when opening your stream.
• You can adjust your flow rate or stop your stream at any time — but while your deposit is still locked, closing forfeits the whole deposit and lowering your rate forfeits the excess part of it.
• A soulbound ERC-5192 NFT (BadNFT) is minted when you start streaming and burned when you stop.

Join the Bad Side · Risks

When someone claims the Good Spot by transferring the asked amount:

1. 1.337% goes to the project wallet as a protocol fee.
2. The remaining 98.663% is held as pending distribution.
3. The pending distribution is released to the GDA pool when minimum conditions are met (enough active streamers at a sufficient total flow rate).
4. Each Bad streamer receives a share proportional to their pool units (=flowrate).

Additionally:

• Forfeited deposits from early-exiting streamers are split the same way: 1.337% protocol fee, the remaining 98.663% is added to the pending distribution pool.
• 1.337% of the total bad stream flow rate is split as a continuous donation stream to a recipient the Good Spot holder can pick from a vetted whitelist.

The deposit does two jobs. It prevents self-dealing — without it, a player could open a Bad stream to themselves as the Good Spot holder, recycling their own tokens while accumulating pool units that dilute everyone else's share. And it prevents hit-and-run — streaming in briefly, catching a distribution, and leaving the people who stayed worse off.

How it works:

• When you open a Bad stream, you must lock a deposit calculated as: flowRate × duration × multiplier
• Your pool units are activated only after your deposit is locked.
• If you close your stream before the lock duration expires, your deposit is forfeited — after the 1.337% protocol fee, the remaining 98.663% goes to the pending distribution pool.
• Lowering your flow rate while the deposit is locked forfeits the excess portion (same fee/pool split) — your remaining deposit shrinks to match the new rate, and its lock timer restarts.
• Raising your flow rate tops the deposit up to match the new rate — and restarts the lock timer on the whole deposit, not just the added part. Worth knowing if you are close to the end of a lock period.
• “Closing early” means the stream ended before the lock expired — however it ended. That includes a stream closed for you because your token balance ran too low to keep funding it. Keep enough balance to cover your stream, or close it yourself once the lock has expired.
• If you keep your stream open past the lock duration, you can claim your deposit back at any time.
• Deposits are auto-processed when you close your stream — no manual step needed. See how to exit safely.
• If the game is paused, an emergency exit returns your deposit in full — the lock duration is waived. Even the emergency lever cannot strip a deposit.
• Only your own early exit forfeits it. No other player's strategy, and no outcome elsewhere in the game, can touch your deposit.

Price decay prevents stalled games at unreachably high asked amounts (the “hot potato” problem). Decay is bound to the holder’s break-even progress: it kicks in the moment the current holder breaks even on what they transferred, then slides the asked amount back down toward the floor.

• No decay while the holder is still in the red — before break-even the full asked amount holds.
• From break-even up to 133.7% of what they transferred, the asked amount decays linearly down to +0.9% of what they transferred — shaving only 0.1% off the 1% claim bump. A faster inflow reaches this sooner.
• Past 133.7%, the asked amount keeps decaying 0.1% per day from there toward the floor (a flat wall-clock rate — flow no longer matters), reaching the floor after ~1000 days.
• If the holder’s inflow drops, break-even moves further out and the effective asked amount ticks back up; if every streamer leaves, it snaps back to the full asked amount.
• It’s all computed on-demand from getEffectiveAskedAmount — no transactions needed. The thresholds are hardcoded in the contract (changeable only via a UUPS upgrade).

1.337% of the total Bad stream flow rate is split off as a separate continuous stream flowing to a donation recipient. The Good Spot holder receives the remaining 98.663% of the aggregate Bad flow.

• The Good Spot holder selects the donation recipient from a vetted whitelist when claiming.
• The holder can change the recipient at any time while holding the spot.
• Recipients are managed through a DonationManager companion contract.
• This donation split uses the same rate as the protocol fee (1.337%) but is separate — it flows in real-time, not from claim payments.

Moral Hazard uses three types of NFTs, each with a dynamically generated SVG as its media file. Every SVG is rendered on-the-fly from live on-chain data — it is not a static image. Each time the SVG is loaded, it reflects the current state of the game or profile at that exact moment, including a snapshot timestamp in the footer.

• GoodNFT (transferable ERC-721)
  Represents ownership of the Good Spot. Only one exists at a time per game. Transferring the NFT to another address also redirects all incoming streams to the new owner. The generated SVG displays live game statistics — current flow rates, stream age, break-even progress, holder address, streamer count, token info, chain, and donation recipient. It also renders the holder's chosen character artwork based on their ProfileNFT preferences.
• BadNFT (soulbound ERC-5192)
  Minted when you start a Bad stream, burned when you stop. Cannot be transferred. Serves as proof of active participation. The SVG shows your individual stream stats — your flow rate, stream age, distribution share, deposit status, and break-even metrics — alongside the game-wide state.
• ProfileNFT (soulbound ERC-5192)
  A personal identity NFT that stores your preferences on-chain — color theme, preferred side, character, gender, display units, and acknowledged warnings. The app restores all settings automatically when you connect. The generated SVG renders your full color palette, appearance panels, timeline, donation stats, and invite code — adapting its entire color scheme based on your preferred side.

All three SVG types include the animated Moral Hazard logo, an embedded custom font, and a PNG download button — when viewing the SVG directly in a browser, a small pill button lets you download a 1024×1024 PNG for sharing on platforms that don't support SVG files.

The on-chain tokenURI resolves to this live SVG, so wallets and NFT marketplaces render the NFTs directly from chain data — what shows in your wallet is generated from the same on-chain state, not a cached snapshot.

Example SVGs on Base Sepolia (live, may change with game state):

• ProfileNFT #1 — profile card with user settings
• GoodNFT #1 (fUSDCx) — current Good Spot holder

The Profile NFT is your personal identity in Moral Hazard — a single, free, soulbound NFT that remembers how you like to play. Instead of saving your settings in a browser that forgets them, your preferences live on-chain, tied to your wallet, so they travel with you to any device and any frontend.

What it stores for you:

• Your look
  Your colour theme and which side (Good or Bad) you lean toward. When you connect, the whole site instantly re-themes to your saved palette — no setup needed.
• Your character
  The character artwork you pick (including from special campaigns) becomes your face in the game — it's the figure drawn onto your GoodNFT and BadNFT and shown around the interface.
• Your preferences
  Small things like your preferred flow-rate unit (per day / week / month), default game, and which risk warnings you've already acknowledged so you're not asked twice.

Shareable settings & campaign limitations:
You can temporarily apply someone elses Profile NFT selections by entering the holders 0x address, ENS or the NFT Number - to check it out, or to mint those settings into your own profile NFT. If the applied profile NFTs holds a character-set that is not available anymore, you won't be able to copy it permanently.

Soulbound & self-updating.
It can't be transferred or sold — it's just you. You can update it any time, and like the other NFTs its image is generated live: open it and it draws your colour palette, your character, your address, and (if you choose to show them) your invite code and donation stats, with a one-click PNG download for sharing.

Why is it on Ethereum Mainnet and not on some cheap L2?
Ethereum Mainnet is where all L2 point to - and so does the Profile NFT. Since Moral Hazard has been built with multiple chains in mind from the start, it was the logic decision to place something that is not related to a specific chain on the Ethereum Mainnet. A positive side-effect is, that especially because Layer2 networks are much much cheaper, bots won't have any incentive to mint/update the Moral Hazard Profile NFT - which makes it easier for users to tell humans from bot apart.

Minting the Profile NFT is optional — you can play without one. It simply makes your experience portable and consistent everywhere.

Because whilst everyone falls in simple black or white terms like good and bad, sometimes we all are individual and unique.

When you mint or update your Profile NFT, you can add an optional ETH tip to support the project. It's entirely voluntary — any amount, or none at all — and it goes straight to the project wallet. Your total support is counted and can be shown as a little badge on your profile.

Where it goes:

1. Cover operational costs (hosting, RPC, the usual).
2. Pay for a proper contract audit — those things are expeeeeensive, and it is first in line.
3. Development of new features and integrations.
4. Build an underground bunker where I can look at a globe whilst sitting in a ridiculously huge chair near a fireplace with an otter on my lap.

For all donations, proper bookkeeping is in place — the market value at the time of each donation is recorded to ensure correct taxation.

Don't worry — it's not a mysterious new coin, and nothing was sent to you to claim. When you join the Bad side and connect to the distribution pool, Superfluid's pool shows up in some wallets and explorers as a “POOL” entry.

It simply represents your share of the distribution pool — your slice of every Good Spot claim, sized to your stream rate. It is not a tradeable asset and has no separate value of its own. Behind the scenes it's how Superfluid's General Distribution Agreement (GDA) pays every streamer their proportional amount in a single transaction.

Your share updates automatically as your flow rate changes, and goes to zero when you stop streaming.

On the Bad page and Profile page, you get a heads-up when a distribution happened — i.e. someone claimed the Good Spot and the pool paid out — with an estimate of your share.

How it works. Each claim emits an on-chain distribution event. We read those from the Superfluid subgraph and keep a small server-side record of them, then estimate each streamer's slice from the active stream rates at that moment. When you've seen a notification, dismissing it just records that you've read up to that point.

• How accurate is it? The amount is an estimate for convenience, based on a snapshot of who was streaming at sync time — not a replay of the exact pool membership at that block. The authoritative number is always on-chain (your total received from the pool).
• What it depends on. Because it relies on a database and an external index, it can lag a little, get recomputed if the index re-syncs, and old entries are eventually pruned. If that record were ever reset, the notifications would be lost — but your actual funds are never affected; this is purely a convenience layer on top of the chain.
• Privacy. We only store data that is already public on-chain (wallet addresses and distribution amounts) plus your dismissal timestamp. No email, no IP logging, no per-user behavioural tracking.

Fair question, and an expected one — it's usually an early one that comes up. That's exactly why so much attention goes into how things are worded here: no “win,” no “odds,” no “returns,” no manufactured excitement. Not because those words are forbidden, but because they'd describe something this isn't.

For context: blockchain is a niche, real-time streaming inside it is a niche of that niche, and Moral Hazard is a niche of that one. What it's built around is an economics concept — moral hazard: acting in the hope that a positive outcome will be carried by someone else. This is that concept made playable: a small social-economic experiment you can participate in rather than read about.

Why someone could reasonably think otherwise
It's not a silly suspicion, so let's say it plainly: you put value in, you can come out with more or with less, and other people decide which. Nothing new enters the system — whatever one participant gains, another streamed in. And the Good Spot holder's run ends when someone claims the spot away, at a moment they don't choose.

What's actually different
It's closer to a market than to a wager. A bettor sits outside the event and can only watch it happen — here you're inside it, and your own stream is part of what everyone else is reading and reacting to. You also keep acting: change your flow rate, close it, hand your position on. A placed bet allows none of that.

Where that comparison stops: a share is a claim on a company that actually earns — this has no productive underlying of its own. That is exactly why it's a game and never an investment, and why nothing here is a financial product. The resemblance is structural, not an equivalence.

• No chance element anywhere. No random number generator, no draw, no hidden roll — nowhere in the contracts. Every number that decides your outcome is public and live: the asked amount, all flow rates, break-even progress, the decay curve.
• No house edge. The 1.337% protocol fee is flat, fixed when the contract was deployed, with no setter to change it. And nobody takes the other side of your position.
• Nothing sits in a pot while you wait. The Good Spot holder is streamed to directly — what arrives is already in their wallet, second by second.
• The deposit isn't a stake. One thing forfeits it: your own early exit. Wait out the lock and it returns in full; if the game is paused it returns regardless. No other player and no chance event can touch it. It exists so nobody can stream in, grab a distribution, and leave the people who stayed worse off.
• There's nothing to play again. One stream per game, one Good Spot, and you can't re-claim it while holding it. After you act, the thing you do is watch — there's no next round to pull you back in right away.

And the lengths gone to keep it that way
Risks appear before the buttons, not in fine print. A complete first game is free with testnet tokens (fUSDCx on Base Sepolia). Every admin change routes through a TimelockController — and you don't have to go looking for it, because a warning appears in the app the moment something is queued, leaving you the whole delay window to exit. And there's no leverage, no credit, no bonuses, no “one more round” prompt anywhere.

So: not a game of chance. The closest honest description is speculation inside a transparent micro-economy — a small system where the rules are visible, the numbers are live, and the outcome comes from people deciding in the open.

What we won't pretend: outcomes are genuinely uncertain because they depend on what others do, and you can end up with less than you put in — the Good and Bad risk sections spell out how. The admin isn't powerless either — but nothing changes silently or instantly (see what the admin can change). And no formal legal classification has been obtained; professional review is planned. If any of that unsettles you, the free testnet game is the right place for you.

No. Moral Hazard is an experimental on-chain game. It is not a financial service, investment product, or regulated instrument. Nothing on this site constitutes financial, investment, tax, or legal advice.

Participating on a mainnet, with tokens that have real value, carries a real risk of loss. Understand the mechanics before you start and never use funds you cannot afford to lose — the risks are listed in full for the Good side and the Bad side.

A related but separate question is whether this is gambling — the short answer is no, and the reasoning there is worth reading rather than taking on trust. And if you'd rather learn the mechanics before anything is at risk, a complete first game is free with testnet tokens (fUSDCx) on Base Sepolia.

Moral Hazard collects minimal data. There are no accounts, no registration, and no personal information required to participate. The full detail is in the privacy policy; the summary:

• On-chain data (wallet addresses, transaction history) is publicly visible on the blockchain — the interface reads it, and where it is indexed for speed that is a cache of already-public data.
• Voting data (which tokens you voted for) is stored locally and in the voting database, linked only to your wallet address.
• Invite-code data (your code, points) is stored in the invites database, linked only to your wallet address.
• No cookies at all — not for tracking, not for anything. LocalStorage stores your UI preferences, your own invite code, and how far you are through the testrun guide, on your device only. That is also why you see no cookie banner: there is nothing to consent to.
• We keep anonymous aggregate usage counts — a number per page, per UI mode, and per feature (for example story mode, testrun-guide steps, or the risk / timelock notices) per day, so we can see which parts of the app get used. That data contains no identifier of any kind — no address, no IP, no session — so individual visits cannot be recorded, and two people cannot be told apart in it.
• Your IP address is used to prevent abuse, and only that. For rate limiting it is held in memory and never written to disk. The one exception that is written down: redeeming an invite code records failed attempts against your IP, so codes can't be guessed at scale — a counter and a lock expiry, not linked to your wallet or anything else, pruned automatically once the hour and any lock have passed. It is never used for analytics or profiling.
• If you choose to mint the ProfileNFT, your UI preferences, settings and warning-acknowledgements are stored on-chain and can be read by everyone.

Let's lay the cards on the table. The core game contracts are upgradeable (UUPS proxy pattern). That single fact matters more than any individual setting: by deploying a new implementation, the admin could in principle change almost any rule of the game. Very little is genuinely carved in stone — so what actually protects you isn't immutability, it's the process every change has to pass through (more on that below).

So the honest split isn't “changeable vs. immutable” — it's how much effort and visibility a change takes: a quick configuration tweak, or a full contract upgrade.

Where the trust actually comes from.
Because upgrades are this powerful, your protection is procedural — not an empty “it can't be changed” promise:

• Every rule change — a simple config tweak or a full upgrade — must pass through the TimelockController delay (48h on mainnet, 20min on testnet). Nothing happens instantly and unseen: a pending-change warning shows up on the game pages, so you can watch it coming and exit beforehand.
• The one instant action is the emergency pause — but it only freezes new activity and can never move your funds. A backup Gnosis Safe multisig can also cancel a malicious proposal before its delay elapses.
• During a pause you can always self-exit — close streams, reclaim your deposit, burn your NFT.

In short: the fee and core rules are a commitment, enforced by a transparent, time-delayed process and a separate veto key — not by a claim that change is impossible. See security measures and the TimelockController for the full picture.

• TimelockController
  All admin actions (except emergency pause) go through a time delay (48h on mainnet, 20min on testnet). Users can monitor proposed changes and exit before they take effect.
• Fee lock
  The 1.337% protocol fee is written in when a game is deployed and has no setter — there is no admin function anywhere that can change it. Altering it would mean shipping an entirely new implementation through the timelock, in public, with the delay running first. Every game carries the same rate.
• Price decay
  Prevents games from stalling at unreachable asked amounts (hot-potato pattern).
• Emergency pause + self-exit
  The backup Gnosis Safe multisig can pause instantly for safety via its CANCELLER_ROLE — no timelock delay needed. Users can self-exit when paused (close stream + claim deposit + burn NFT). Unpause requires going through the timelock.
• Deposit system
  Prevents GDA self-dealing by requiring locked deposits for pool unit activation.
• Streamer-funded buffer
  Each streamer funds their own 4-hour CFA buffer. No reliance on contract liquidity.
• Multisig governance
  All contracts are owned by a TimelockController. The admin holds proposer and executor roles, while a separate backup Gnosis Safe multisig holds the canceller and admin roles — able to cancel proposals, pause games, and swap the admin in emergencies.
• No-self-claim guard
  The current Good holder cannot claim the spot from themselves.
• Minimum thresholds
  Distributions are only released when enough streamers are active at a sufficient total flow rate.
• Reentrancy guards
  The state-changing entrypoints (claims and exits) are protected against reentrancy.
• Action-bound, expiring signatures
  Off-chain signatures (voting, operator actions) are bound to a specific action and carry a short expiry — so a captured signature can't be replayed, repurposed for a different action, or used after it expires.
• Request hardening
  The app's API is rate-limited per IP (tighter on operator and faucet routes), and operator-only endpoints (e.g. contract verification) require an admin signature. NFT metadata is served from a fixed canonical origin rather than the request host, so it can't be poisoned via a forged Host header.
• Full source verification
  All deployed contracts are source-code verified on their respective blockexplorer via Etherscan's standard JSON input verification. This includes the game logic (MoralHazard), DepositManager, DonationManager, GoodNFT, BadNFT, ProfileNFT, and all ERC1967 proxy contracts. Proxy contracts are additionally linked to their implementations via EIP-1967, enabling “Read as Proxy” / “Write as Proxy” on the explorer. Anyone can inspect the exact source code running on-chain. See contract addresses.

Note: the contracts have not had a formal third-party security audit by a professional audit firm. What review they have had is set out in Have the contracts been audited?

Not by a professional audit firm — no. That is the one form of assurance still missing, and nothing below is a substitute for it. If that alone is your threshold, it is a fair reason to wait.

What the contracts have had instead is repeated, structured security review:

• A full pass with each new model generation.
  The contracts are re-reviewed end to end every time a new generation of the AI models used to build them ships — Claude Opus 4.6, 4.8 and 5. Each pass re-checks the previous pass's findings against the current code, so a fix that quietly regressed shows up rather than staying fixed only in the notes.
• Independent AI audit tooling.
  The same source has been run through Hashlock's AI audit tool — a second opinion that shares none of the assumptions the reviews above were written under.
• An informal look by Superfluid engineers.
  Engineers who work on the streaming protocol underneath have read the contracts and raised nothing significant. That is a look, not an audit and not an endorsement — treat it as the weakest item on this list, because it is.
• Built against the protocol's own reference.
  Superfluid publishes an official skill for AI coding agents — the complete protocol reference, contracts and SDKs included. The contract work was written and reviewed against it, which is the ecosystem's supported path rather than a shortcut around it.

Findings from each pass were addressed — most fixed, a few deliberately accepted and written down as accepted rather than quietly dropped. The reviews did find real problems; that is what they are for. What they are not is a firm's signature.

So why no audit yet? A proper one costs more than this project has. There is no investor money behind it, which leaves the obvious circle: an audit needs funding, funding needs usage, usage arrives before the audit can be paid for. So it is not promised against a launch date that could slip — it is simply the first thing the project spends on once it earns enough to pay for it. An unused app does not need an expensive audit; a used one deserves nothing less.

Until then the honest summary is: verified and open-source, reviewed repeatedly and seriously, and still carrying the risk that review is not assurance. Read the risks before you decide.

The TimelockController is an OpenZeppelin governance contract that wraps all admin actions with a mandatory time delay. Any change the admin wants to make must be proposed first, then waits for the delay period before it can be executed.

• Mainnet delay: 48 hours
• Testnet delay: 20 minutes
• The admin holds the proposer and executor roles (propose changes, execute after the delay). A separate backup Gnosis Safe multisig holds the canceller and admin roles (cancel proposals, pause games, swap admin in emergencies). The deployer EOA may temporarily receive the proposer role for deployments, but renounces it afterwards.
• Two actions bypass the timelock delay: emergency pause — triggerable instantly by holders of the CANCELLER_ROLE (the backup Gnosis Safe multisig) — and role management on the TimelockController itself (the backup multisig holds DEFAULT_ADMIN_ROLE and can grant or revoke roles instantly).
• 2-step ownership. Handing a contract over to the timelock is two-step — the current owner proposes the transfer and the new owner must explicitly acceptOwnership. Ownership can never be moved to a wrong or uncontrolled address by a single mistaken transaction.

This ensures users always have time to review proposed changes and exit their positions if they disagree, before any change takes effect — and you don't have to go looking for them: a pending-change warning appears right on the affected game's pages. See what the admin can change for the full list of timelocked parameters.

Safe vs. EOA workflow:
The admin is generally a Gnosis Safe multisig, which works well for routine operations like adding a donation option. However, deploying new contracts or major upgrades (e.g. integrating a new token or chain) involves gas-heavy multi-step transactions that exceed the Safe's execution limits. For these tasks, the admin temporarily grants the proposer role to a single deployer wallet (EOA). Since this role switch itself goes through the timelock, users get an extra 48-hour notice period before the deployer can act — and any changes the deployer then proposes take another 48 hours to take effect. Once the deployment is complete, the deployer renounces the role and the admin switches back to the Safe for day-to-day security.

When the admin schedules any change through the TimelockController, it does not take effect right away — it waits out the delay (48h mainnet / 20min testnet). During that window you get a visible heads-up on the affected game's pages.

• A blinking warning appears.
  On the game's Good and Bad pages, a small “Timelock Alert” chip blinks next to the “Read the risks” button.
• Click it for the details.
  A panel opens listing what is queued in plain language, a countdown to when it can execute, and a link to the scheduling transaction.
• Global changes show everywhere.
  Changes not tied to one game — governance/role changes, the factory, or the Profile‑NFT — appear on every game's pages.
• The admin can hide a notice (signed).
  Some routine prep (e.g. lining up a new donation option tied to a soon launching campaign) shouldn't be broadcast 48h early, so the admin can hide a specific notification — which requires an admin signature (and even then, the proposal transaction is still public on the blockchain). A new or unexpected proposal shows by default, so an unannounced change can't slip by unseen.

This is the practical version of “watch it coming.” If you disagree with a queued change, you have the full delay window to exit your position before it executes.

Pausing freezes new activity — no one can claim the Good Spot, open a new Bad stream, or update an existing stream rate. However, all existing Superfluid streams continue flowing in real-time. The pause does not stop or delete any CFA agreements.

This means during a pause:

• Bad streamers continue streaming tokens into the contract.
• The Good Spot holder continues receiving those streams in real-time (the contract acts as a passthrough).
• The donation stream also continues flowing.
• No new claim distributions happen (since no one can claim), so the GDA pool for Bad streamers is dormant.

Emergency exit is optional, not automatic. Each user can choose to call the emergency exit function:

• Bad streamers: Your stream is closed and your BadNFT is burned. Your deposit is returned in full — the lock duration is waived during emergency exit.
• Good Spot holder: Your outgoing flows are stopped, your GoodNFT is burned, and the spot becomes vacant. The amount you originally transferred to claim is not refunded — it was already distributed to Bad streamers at the time of your claim.

If nobody exits, the game resumes exactly as it was after unpause — same Good holder, same Bad streamers, same flow rates. If only some participants exit, the remaining positions continue normally. The Good Spot only resets to the floor amount if the holder emergency-exits.

The backup Gnosis Safe multisig can pause instantly via its CANCELLER_ROLE (no timelock delay), but unpause requires going through the TimelockController. See when the admin would pause for the circumstances under which this would happen.

Pause is a last-resort safety mechanism. It would only be used in situations where continuing normal operation could put users' funds at risk:

• Critical smart contract bug
  A vulnerability is discovered that could allow funds to be drained or locked permanently.
• Superfluid protocol incident
  An upstream issue with the Superfluid framework affects stream integrity or token accounting.
• Dependency failure
  The accepted token contract, GDA pool, or other external dependency malfunctions in a way that corrupts game state.
• Contract upgrade safety
  A required upgrade cannot safely execute while streams change and must be applied during a paused state.

The admin would NOT pause for:

• The asked amount being “too high” or “too low”
• Low activity or no active streamers
• Admin preference or convenience
• Individual user disputes

How likely is a pause?
The admin has no financial incentive to pause — it disrupts protocol fee income and blocks new claims, reducing activity. Pause exists purely to protect users' funds in a genuine emergency. The contracts are designed so that normal operation requires zero admin intervention.

Impact on the Good Spot holder:
If you hold the Good Spot when a pause occurs, nothing changes automatically. All existing Superfluid streams continue flowing — Bad streamers keep streaming into the contract, and you keep receiving those streams in real-time. You may call emergency exit if you choose to, which burns your GoodNFT and vacates the spot. But if you don't exit, and the game is later unpaused, you continue holding the Good Spot exactly as before. The spot only resets to the floor amount if you voluntarily emergency-exit. See what happens when paused for full details and Good Spot risks for the full picture.

• As a Bad streamer:
  Stop your stream on the Bad page or Profile page. If your deposit lock has matured, it will be returned. If not, it will be forfeited. Should the Moral Hazard Web-Interface be down / not available anymore, you can still close your streams via the Superfluid Dashboard as well.
• As the Good holder:
  You cannot actively “exit” — someone must claim the spot from you, or you can transfer your GoodNFT to another address.
• During an emergency:
  If the game is paused, use the emergency exit function to close everything and reclaim your deposit regardless of lock status.

Moral Hazard uses Superfluid “Super Tokens” — wrapped versions of standard tokens that support real-time streaming.
For example, USDCx is the Super Token version of USDC. There are also native Super Tokens, that don't require wrapping anymore (like "SUP" or "FRACTION").

How to get wrapped Super Tokens:

1. Acquire the underlying token (e.g. DAI, USDC, ETH) on the supported chain.
2. Wrap it into its Super Token version using the tool in the sidebar or the Superfluid Dashboard.

How to get native Super Tokens:

1. Acquire the token on the supported chain. That's it.

For cross-chain swaps, you can use LI.FI Jumper Exchange to bridge and swap tokens directly to the target chain. Check your current balances on the Profile page.

When trying first on the Testnet:
You can mint & wrap during the Testrun-Guide on fUSDCx/Base Sepolia to get free test tokens.

The Voting page lets you suggest and vote for tokens to be integrated into Moral Hazard next.

• Search for any Superfluid token across 10 mainnet chains.
• Votes are gasless — they use EIP-712 typed signatures, so you only sign a message (no transaction fee).
• Eligibility: you must have an active participation with at least one Moral Hazard game (active Bad stream or holding a Good Spot) to vote.
• The leaderboard shows which tokens have the most community support.
• Admins can mark tokens as “integrated” once they've been added to the game.
• Admins can reject tokens, but have to provide a reason for it (eg. project already died, no active streams on that token, etc...).

Each player gets a visual invite code (a little sequence of animals) to bring others in. The thinking behind it is simple: only people who actually use the project should be able to invite others — so you earn invites by participating, you don't just get a stack up front.

How you earn invites.
While you're actively participating — holding the Good Spot or running one or more Bad streams — your participation score ticks up over time (it grows faster the more you have running, and keeps accruing when you stay active). Each time it crosses the next threshold, another invite unlocks for you to hand out. Trying the free testnet run on Base Sepolia counts too, so you can start earning invites completely risk-free.

Won't the codes run out?
Each code is four animals drawn from a set of eight — plenty to begin with, but not endless. So the pool grows in seasons: when one season fills up, a fresh set of eight animals opens the next batch, then the two sets combine. Once that pool is full, a set of 32 animals gets used - enabling over a million possible codes in all - and the invite system deactivates. You keep your invite combination, but at that point the codes are not used for inviting anymore, but become a personal badge (still shows up in the app and on your Profile NFT).

If you mint a Profile NFT, you can choose whether to show your invite code on its generated image — it's an optional toggle (off by default), in case you'd rather keep it private.

Important to understand:
Your invite code and participation score are not stored on-chain. They live in the project's own database, off-chain.

• This data exists only to power the invite system. It is never used for any on-chain eligibility — not for voting, not for claiming, and not for any future airdrop or reward. Please don't treat your score as a claim on anything.
• Because it's off-chain, it could theoretically be lost. Nothing of monetary value is tied to it, so this only affects how many invites you can send — never your funds or your on-chain positions.

All contracts are source-code verified on each networks blockexplorer. Click any address to view the verified source code directly on the block explorer.

Source code verified on Basescan. Proxy contracts link to their verified implementation via EIP-1967.

Moral Hazard streams Superfluid Super Tokens, so a plain ERC-20 first needs a Super Token wrapper — e.g. MYTOKEN → MYTOKENx. The good news: this is a standard, permissionless Superfluid step, not something specific to us.

• Wrapper Super Token
  For an existing ERC-20, deploy a wrapper via Superfluid's SuperTokenFactory (done once per token). Holders then upgrade (wrap) and downgrade (unwrap) 1:1 between MYTOKEN and MYTOKENx.
• Native Super Token
  If you're launching a fresh token, you can deploy it as a native Super Token from day one — no wrapping needed.

You can create and manage wrappers from the Superfluid Dashboard / Console — see the Superfluid docs for the exact steps and supported chains.

Once a Super Token exists, getting it into Moral Hazard is straightforward: gather support on the Voting page so it surfaces as a wanted integration, and/or reach out to discuss it directly.

Yes! Collaborations are welcome — the easiest start is to schedule a meeting via the button at the bottom of this page. A collaboration can range from a one-off character campaign to a deeper partnership around an integrated token, so there's room to figure out the right shape together.

Needed for a campaign:

• A name, a short description, and a link.
• 6 colour codes for the campaign theme.
• The group for the side-picking question — the subject swaps per campaign while the structure stays: “Do you think animals are, in general: Good or Bad?”, “Do you think robots are, in general: Good or Bad?”
• A set of 4 characters — a Good Guy, Bad Guy, Good Gal and Bad Gal (so 2 Good / 2 Bad, 2 male / 2 female).
• Start/End date of the campaign + Start/End date of profileNFT UI override.
• A small icon/logo as a .svg (square format) to get used in the UI override menu.
• Info whether the characters should only be linked in the profile NFT during the active campaign or stay available for everyone.

Character guidelines:

• Two colours only. The Good and Bad versions are colour-inversions of each other — in the reference set the Good characters are light figures on a dark field and the Bad characters dark figures on a light field. (Your 6 colour codes drive the surrounding theme separately.)
• Canvas & framing. Each character sits on a 1024×1024px tile, kept within an inner 500×900px area from the centre. Don't crop a character with a straight line on any edge — let it blend into the background (e.g. no flat horizontal cut at the bottom), the way the reference characters do.
• Shared posture per side. The two Good characters share one posture and vibe; the two Bad characters share their own. The two sides face opposite directions so a Good and a Bad character placed together look toward each other — eyes straight ahead (at their counterpart), never at the camera.
• The Bad pair shares “a thing.” Both Bad characters carry the same signature attitude — a matching gesture or accessory (e.g. a thumbs-up and sunglasses, a wink, a particular stare or module). The Good pair doesn't need one. You may reuse a default “thing,” but it's not mandatory — what matters is that the bad guy and bad gal do the same thing.
• No symbols, patches or logos, and keep the level of detail roughly in line with the existing sets.
• Delivery. 4 SVG files — one for each character.

To make this easy, we provide a reference package (.zip, with the default characters and templates) and the brand kit (.zip) to work from.

You don't need finished art to talk — a draft is fine for scheduling. And if you can only provide photos or pixel graphics, we'll find a way to vectorize them for integration.

Classic one.
But seriously, if you want to then go for it! Every contract is verified and public, so you can read all game state and interact without our frontend. Here's everything you need.

Start with AGENTS.md — a machine-readable playbook generated live from the game registry: state reads (subgraph + RPC), the formulas, and every player interaction, written for autonomous agents and builders alike. Everything below is the human-readable version of the same surface.

Data sources (no API keys required)

• Superfluid subgraph — for streams, pool members and distribution history:
  https://subgraph-endpoints.superfluid.dev/<network>/protocol-v1
  where <network> is e.g. base-mainnet, optimism-mainnet, base-sepolia.
• Public RPC + block explorer — for live contract reads. Every game/NFT/manager contract is source-verified on its explorer (see contract addresses); the Superfluid CFA/GDA forwarders are public protocol addresses on each chain.
• AGENTS.md — GET /AGENTS.md — the generated agent playbook; addresses come from the live game registry, so they never drift (public games only).

Read directly on-chain (view functions)

• MoralHazard (game): currentGoodHolder, askedAmount, getEffectiveAskedAmount, totalBadFlowRate, badStreamerCount, lastClaimTimestamp, lastPaidAmount, pendingDistribution, badPool, acceptedToken, receivedAccumulator, receivedUpdatedAt, phase3StartedAt
• GoodNFT: currentTokenId
• DepositManager: getDepositInfo, depositDuration, depositMultiplier
• DonationManager: getOptions, getActiveRecipient
• Superfluid: CFAv1Forwarder.getFlowInfo, pool getUnits / getTotalAmountReceivedByMember

Values the app computes itself

• Effective asked amount (decay): bound to break-even. With received = receivedAccumulator + holderRate × (now − receivedUpdatedAt) (all public reads, flash-proof): below paid → asked (no decay); between paid and 1.337·paid → linear from asked down to 1.009·paid; beyond that → 1.009·paid − paid × daysSince(phase3StartedAt) / 1000, floored. (Or just read getEffectiveAskedAmount.)
• Break-even %: received as above; % = received × 100 / lastPaidAmount.
• Pool / distribution share: yourUnits × 100 / totalUnits (units = flow rate).
• Required deposit: flowRate × depositDuration × depositMultiplier; plus a Superfluid buffer of flowRate × 14400 (4-hour liquidation period).
• Flow-rate display: wei/sec × secondsPerUnit (day = 86400, week = 604800, month = 2630016).

Player interactions (everything a non-admin can do)

• approve (ERC-20 on the accepted Super Token)
• claimGoodSpot and changeDonationRecipient (MoralHazard)
• Open / update / close a Bad stream via CFAv1Forwarder.setFlowrate
• GDAv1Forwarder.connectPool (to receive distributions) and DepositManager.claimDeposit
• ProfileNFT mint / update
• Wrap / unwrap: upgrade / downgrade (or upgradeByETH / downgradeToETH for native Super Tokens)

Note: voting and the invite system run on a project database, not on-chain, so they aren't part of this list. Super Token transfers use ERC-777 hooks — budget extra gas accordingly.

In economics, a “moral hazard” describes acting in the hope that a positive outcome will be carried by someone else. The name reflects the game's core dynamic: every player hopes their choice produces a surplus — but whether it does depends not on their own strategy alone, but on the behavior of all other participants.

The “Good” and “Bad” naming comes from the side-picking question: “Do you think humans are, in general: Good or Bad?”
The Good side plays for stability and trust (holding the spot, receiving streams). The Bad side plays for change and disruption (streaming now, counting on frequent turnovers). Neither side is inherently better — they represent different strategic outlooks.

It's a reference to long gone days. Carrying CRT monitors to a gym hall in summer days. But 1337 still remains as a little easter egg.

Beyond the insider-joke, it's deliberately used across the project when setting constants. A 1.337 reference on the project fee, the donation stream, or phase 2 price decay. One memorable number, applied consistently.

Because the whole point is that you can make an informed decision. The approach throughout is transparency and upfront communication: show you enough to understand exactly what you're getting into, while keeping the path to actually participate as smooth as possible.

Treat all those figures as a neutral view on the statistics — current state, risks, break-even, decay — never a suggestion or promise of future gains. The warnings exist for the same reason: so nothing about the mechanics is hidden behind a friendly button.

There was also no rush to ship (a good chunk of the wait was just the grace period on moralhazard.eth ending ^^), which left plenty of time to reiterate and finetune. In the end it's simply built the way I, as a user, would want it — doing the best with the resources at hand.

Me! *raises hand* ^^
I'm Markus B., going by the online alias "seliqui" (X / Lens) and I built Moral Hazard.

I also run seliqui e.U., an Austrian sole-proprietorship licensed for Advertising, Media-Design, and IT-Services.

My professional experience spans over +22 years of Media-Design, Web Development and Frontend Designs - spanning from classic webdesign, to 2D/3D animations (AfterEffects/Cinema4D), to niche areas like WebVR/XR projects in the Virtual Reality space (primarily web based using aframe.io).

My blockchain experience includes being a founding member of the lab10 Collective e.G. in Austria, being part of the core team on the Minerva Wallet, building the FRACTION token (second ever native SuperToken) as a side-project in my spare time and in regards to Superfluid, I operated Superfluid Sentinels and became a Superfluid DAO Delegate.

The project's blockchain contracts are open-source — all smart contracts are verified on block explorers, and anyone can interact with them directly or build their own interface instead of using the provided one.

Rights, licences and attributions — who owns what, third-party logos and trademarks, the invite-animal icons and the typeface licence — all live in the imprint, alongside the privacy policy and the draft terms. And if you're wondering about the tooling: yes, AI was involved.

seliqui is not responsible for any losses that occur by participating — make sure you are aware of the risks and the overall game mechanics!

Yes — and the honest version is more interesting than either extreme you might be picturing. An AI coding agent is part of my toolchain, the way an IDE or a build system is, and some commits are co-authored with it. Superfluid publishes an official skill for exactly this, so the agent works from verified contract interfaces instead of guessing from stale training data.

What it did not do is decide anything. Every design decision, every economic mechanic, every trade-off and everything rejected along the way came from me. The tooling wrote code under direction; it never decided what the game should be.

And it is nowhere near “type a prompt, get a game”. These tools are a real help, and they also get things subtly wrong — so most of the work is everything around the generating: planning what should exist, reading back what actually came out, testing it, finding the places where the implementation quietly drifted from the intent, and going round again. Anything touching the contracts gets that treatment several times over. Price decay was reworked three times before it behaved the way it was supposed to, and the contracts went through a dedicated audit pass and a full test suite afterwards — which is also why the “not yet formally audited” caveat is still sitting there honestly instead of being quietly dropped.

It runs both ways, too: this project serves its own AGENTS.md — a playbook generated from the live game registry so an autonomous agent can play the game directly against the verified contracts, without this interface. Machine-readable is a design goal here, not an afterthought.

I mention all this because the Handbook asks you to trust a lot of statements about how things work, and it would be odd to be straight with you about the fee, the admin powers and the audit status while being coy about the tooling.

There are currently no concrete plans for a dedicated Moral Hazard token. The idea has been explored conceptually but is 'parked' at best, as there is currently no clear need/use case for a dedicated token. Any token launch would require thorough regulatory review given the legal landscape for crypto-assets. The game functions entirely with existing Superfluid Super Tokens.

A rough sense of direction (not promises — priorities shift):

• New chains
  Bring the game to more of the networks Superfluid runs on.
• New tokens
  Integrate more Super Tokens — one game each. The Voting page helps decide what comes next.
• Line-Us
  Special access for active good spot holders, involving an IRL drawing robot.
• Automated Social Posts
  On good spot claims, timelock Alerts or new integrations, automatic updates on Lens and X get posted.
• Widget & API
  Provide a widget and API endpoints for integrations into other websites.
• Character campaigns
  More campaigns, each bringing its own character set and theme — with artists, or with a Super Token project around an integrated token.
• WebXR Interface
  An experimental immersive (WebXR) view.
• Notifications
  Opt-in push notifications with granular settings — pick exactly which events you want to hear about, so you don't have to keep checking the interface.

If you need to do any graphical work related to Moral Hazard, check out the approved Design Manual and download the Brand Kit .zip file for assets you might need.

Design Manual→brandkit .zip file→

Straight answer: there is no finalised Terms & Conditions document yet — and saying “it's coming before mainnet” would be a promise this item has already outlived. So instead of nothing, the working draft is published as it stands: read the draft terms. It is marked as a draft on every screen, because that is what it is.

Why it isn't final. Two honest reasons. The operating entity structure is still being settled, and the document has not been through professional legal review. A polished-looking T&C that names the wrong party — or that nobody qualified has checked — would be worse than telling you where things actually stand.

What already applies, today. The draft doesn't create your protections. These are live right now, with or without it:

• Risk disclosures before the buttons on both game pages and on the Profile page, with an acknowledgement step before your first claim or stream.
• Full disclosure of what the admin can and cannot change, the TimelockController delay every change must pass through, and an in-app warning for the whole time one is queued.
• Self-exit always available — including while a game is paused.
• Verified, open-source contracts you can read, and interact with directly, without this interface at all.

What is genuinely unsettled: governing law and jurisdiction, which entity is the operator of record, and geographic restrictions. The privacy policy and imprint are not in that list — those are published and in force, because what they say is factual and doesn't depend on the entity question. If you spot something wrong or missing in the draft, say so — that is a large part of why it's published early.