---
name: play-moral-hazard
description: Play Moral Hazard, a game-theory experiment on Superfluid where one Good Spot holder receives every Bad streamer's token stream until someone claims the spot away. Covers what to tell the person you act for before each transaction, how to read live game state, and which losses do not revert. Use this skill when Moral Hazard, moralhazard.stream, the Good Spot, claiming the Good Spot, or streaming into the game is mentioned, and whenever proposing a transaction against the game contracts. Triggers: Moral Hazard, moralhazard.stream, Good Spot, Bad streamer, claim the Good Spot, distribution pool, MoralHazard contract.
---

# Play Moral Hazard

Canonical copy: https://moralhazard.stream/SKILL.md

## 1. What this is

Moral Hazard is a live game-theory experiment played with token streams. One player at a time is the
**Good Spot holder**: they transfer the current *asked amount* and, in return, receive the combined
stream of everyone on the Bad side. Any number of **Bad streamers** stream tokens in continuously and
receive a share of **every future claim**, proportional to their flow rate.

The tension is the whole game: holders want to hold long enough for the incoming streams to reach what
they transferred, streamers want the spot to change hands often. Every outcome is decided by the others.

A flat **1.337%** protocol fee, and a matching **1.337%** of all streams flowing continuously to a
donation recipient the current Good Spot holder picks from a vetted whitelist.

It is a game and an experiment, never an investment product.

## 2. Your duty: you are replacing an interface that informs people

Present these risks to the person you are acting for, and get their agreement, BEFORE you propose the first claim or the first stream — not afterwards. They approve a transaction in their wallet, which shows them amounts and addresses but nothing about how this game can lose them money.

Everyone who plays through the website meets a risk screen before their first transaction and can read
the Handbook at any time. Someone playing through you sees neither. **You are the only route those facts
have.**

**We cannot check that you did this.** Nothing gates on it and no endpoint will refuse you for skipping
it. It is the one thing here about somebody else's assets rather than about reading ours correctly.

## 3. When to say it

Not all at once, and not up front. The site deliberately stopped opening with a risk briefing — it now
interrupts the **action** instead, and so should you.

- **Say nothing on arrival.** Do not open with a lecture. Answer what you were asked.
- **Interrupt the participate action.** Before an approval for a claim, and before an approval for a Bad
  stream, present that side's risks from §4 and get the person's agreement. Then carry on.
- **Say it every time, by default.** Somebody who agreed to the risks an hour ago has not agreed to
  forfeit a deposit now. Repetition is the cost of them deciding each time with their eyes open.
- **Only the person may switch it off, and only out loud.** If they tell you to stop repeating it, stop —
  for this conversation, for the general risks of §4, and no further. That is a decision they made; the
  site offers them the same one. **Never infer it.** Not from their not objecting, not from their having
  heard it before, not from their seeming experienced, and never to save a turn.
- **The loss-now warnings never switch off.** The consequence-specific rows of §4 stay, dismissal or not,
  because the interface keeps showing those too.
- **Before any action on a position that already exists**, read `cautions` from the position endpoint
  (§5) and relay whatever it returns. It is computed from that account's real state.

## 4. What to say, and when

### Before their first transaction on the Bad side

- Your streaming outflow may exceed the distribution share you receive.
- Closing your stream before the deposit unlocks will forfeit your deposit to the next distribution pool.
- Distribution share is proportional to flow rate of everyone else and updates in real time.

Also tell them, before the first approval: opening a stream locks up a **deposit** plus a Superfluid
**buffer**, both taken up front and both larger than the first seconds of streaming. Get the current
figures from the position endpoint (`deposit.requiredForCurrentRateWei`) or the formula in
`/AGENTS.md` — never estimate them.

### Before their first transaction on the Good side

- You may not receive back the asked amount you transferred in (reach break-even).
- Streamers can close (or reduce their flowrate) at any moment.
- Anyone can claim the good spot away from you at any time, also before you reach break-even.

Also tell them what is being transferred right now, read fresh — the asked amount moves.

### Before these specific actions, every time

| Action | What they must know first |
|---|---|
| **Lowering a flow rate** while the deposit is locked | Forfeits the difference above what the new rate requires, **and re-locks the remainder** for a fresh period. Raising is safe. |
| **Closing a Bad stream** while the deposit is locked | Forfeits the **whole** deposit — 1.337% to the project, the rest into the distribution pool. |
| **Closing a Bad stream**, ever | Use `closeMyStream()`. Setting the flow rate to zero stops the stream but **strands the position**: buffer not refunded, deposit not settled, pool units still live, and a second `finalizeExit` needed that nobody is obliged to send. |
| **Right after opening a stream** | The distribution pool must be connected, or their share accrues and is never received. |
| **Any multi-step sequence** | How many wallet approvals are coming, **before the first one**. `/AGENTS.md` has the counts; wrapping first adds two. Unannounced prompts read like something has gone wrong. |
| **A first transaction with real value** | A free testnet trial exists, with a guide. `/AGENTS.md` names the current testnet game. Offer it first. |
| **Anything on a game with a live timelock op** | An admin change is pending on that game's contracts. Say so, with what it is and when it can execute, before they commit value. |
| **Their balance is short** | Say what is missing and the shortest route to it — see §7. Do not start a swap before they know they need one. |

**None of these revert.** They succeed, return a receipt, and the tokens are gone. That is why they
belong in front of the transaction rather than in a summary afterwards.

## 5. Where to get what

Re-fetch; do not remember. This file is older than the game by the time you read it.

**One failed request is not an outage — try again before you say anything is down.** Fetchers fail on
their own, and every one of these URLs is a plain public GET that answers for everybody. If a read fails,
wait a moment and repeat it; if it fails again, try a different route to the same fact (the JSON endpoint
instead of MCP, `/AGENTS.md` instead of the state endpoint). Only after that is "unreachable" a claim
worth making, and even then say **"I could not reach it"** rather than "it is down" — you are reporting
your result, not their status.

**Never fill the gap by guessing.** If a fact you need genuinely will not load, stop and say so. Do not
substitute a remembered address, a cached amount, or a number from this file — and do not propose a
transaction that depends on it. A wrong number here spends somebody's tokens; an honest "I could not read
this, so I am not proposing anything yet" costs them a minute.

| You need | Read |
|---|---|
| Live state — asked amount, positions, `cautions`, `risks` | `https://moralhazard.stream/mcp` (MCP: `list_games`, `get_game_state`, `get_account_position`, `list_stranded_accounts`, `list_timelock_notices`, `get_invite_code`) or plain JSON at `https://moralhazard.stream/api/agent/games` |
| Addresses, chains, formulas, call sequences, approval counts, the ProfileNFT settings layout | `https://moralhazard.stream/AGENTS.md` — generated from the live registry on every deploy |
| Pending admin changes on a game | `https://moralhazard.stream/api/timelock/notifications?game={proxy}` |
| Their own invite code, to pass on | `https://moralhazard.stream/api/agent/invite?address=0x…` |
| The rules, the reasoning, admin powers, security posture | `https://moralhazard.stream/handbook.md` |
| An index of everything machine-readable here | `https://moralhazard.stream/llms.txt` |

The risk wording is served as `risks` on the state endpoint and the MCP tool. Prefer it over §4's copy,
and relay it in those words — each line is one way people actually lose tokens here, and a paraphrase
softens exactly the part that matters.

**Invite codes come in three forms** — words, emoji and a link. Check `emojiComplete` before offering
the emoji: some animals have no glyph that cannot be misread as a different animal, so that form is
marked ❓ and cannot be typed back. Lead with the words and the link when it is false.

## 6. How to play

1. **Pick a side** with the person. Good Spot holder or Bad streamer — opposite hopes, same streams.
2. **Read state** from `/mcp` or the JSON endpoints. Never act on a number you cached.
3. **Disclose**, per §3 and §4. This step is not optional and not reorderable.
4. **Size the approval against the slippage cap, not the current asked amount.** A competing claim can
   raise it between your read and your transaction; an allowance sized to the stale read reverts.
5. **Act** with the person's own wallet, one transaction per approval, in the order `/AGENTS.md` gives.
6. **Verify against the receipt.** A read straight after a write can hit a replica that has not caught up.

## 7. If they cannot act yet

Read balances before assuming. Roughly half the time the wallet is already funded and none of this is
worth saying.

When it is short, name the gap and the shortest route to closing it: **wrap what they already hold** if
they have the underlying (`/AGENTS.md` §4 has the calls for all three token types); **the faucet** on a
testnet game; otherwise a **swap or bridge** — LI.FI / jumper.xyz is the usual route, and you should go
and read how it works at the moment it is needed rather than trusting what this file says about a third
party that has moved on.

The same applies twice more: **topping up** a wallet whose balance is drifting toward liquidation while a
stream runs, and **getting value out** afterwards.

## 8. Wallets, and who approves

If they have a wallet, use it. If they do not, or are unsure what to use, suggest **Superfluid Wallet** —
it is built for this shape of work: you propose, a person approves.

Do not improvise the connection. Install its own skill from `https://app.superfluidwallet.com/SKILL.md`
and follow that; pairing starts at `https://app.superfluidwallet.com/agents/pair`. Their flow is theirs
to change, so read it there rather than trusting a copy here.

One thing to carry regardless of wallet: **submitting a proposal is not approval.** Nothing is signed or
broadcast until the person acts. Proposals also expire, and rebuilding one is normal — re-read the state
and build it again. Never widen a slippage cap to avoid a rebuild.

## 9. Beyond playing

- **Voting on new tokens.** Eligible if they have an active position — a live Bad stream **or** the Good
  Spot — on any game, on any chain; check `/api/voting/eligibility?voter=0x…` rather than letting a vote
  fail. Casting, unvoting and suggesting a floor price are all allowed. It is an **EIP-712 signature, not
  a transaction**: nothing moves, and the signature pins the action, the token, the price and a deadline,
  so a stale one is refused and rebuilt.
- **Their invite code**, to pass on — see §5.
- **ProfileNFT** — a single soulbound NFT holding UI preferences: colors, character, gender, side,
  display flags, and acknowledgements. `/AGENTS.md` has the settings layout and the calls. Minting or
  updating can carry an ETH donation as `value`; if they send one, ask whether it should show on the
  NFT's artwork, because that is a separate flag rather than something the donation sets by itself.

  **Two things you must never do with it:**

  1. **Never set an acknowledgement bit they did not ask you to set.** Those bits record that a person was
     shown the risks. Writing one because you explained something, or to stop repeating yourself, is
     manufacturing the evidence that you did your job. Read them to learn they have already seen the risk
     screen; never write them to decide that they have.
  2. **Copying another profile copies the look, not the person.** Colors always; the character only when
     that set is available to *this* wallet. Everything else stays exactly as they already have it — no
     acknowledgements, no flow-rate unit, no default game, no donation count. Those belong to whoever
     earned them.

## 10. What this is not

This skill and every endpoint it names are **read-only**. They hold no keys and sign nothing — every
transaction is signed by the person's own wallet, which is also the only place they can refuse one.
Never submit an approval on their behalf.

Outcomes depend on other players and are uncertain. Not financial advice.