Skip to content

Venues — Cover-Charge Tuning (for Operators)

TL;DR: If you're a QING/GWAT owner, CoverCharge is a per-Join fee your venue collects. Set it so it filters out free-riders but doesn't repel chat-miners — because your QING collects cover but doesn't collect anything from chatting.

Why this matters

QING operators have three economic knobs: CoverCharge, BouncerDivisor, and NoCROWS. CoverCharge is the only one that mints revenue to the venue. Set it too low, freeloaders use your chat as a MAI farm with no contribution. Set it too high, you get no traffic.

Bouncers — including you — can set any value. setCoverCharge(_c) is onlyBouncers.

The numbers

What CoverCharge does

From QING.Join:

function Join(UserToken):
    if CoverCharge > 0 and _list[UserToken] < block.timestamp:
        Asset.transferFrom(msg.sender, address(this), CoverCharge)
    _list[UserToken] = block.timestamp + 1 days
  • Fee is in QING.Asset (the underlying, not the QING token).
  • Charged at most once per day per UserToken.
  • Paid to the QING contract, which the owner(s) can Withdraw.

What it doesn't do

  • Chat does not re-pay cover. Cover is a daily subscription to chat.
  • Cover is not burned; it accumulates on the QING. You can Withdraw it.
  • Guests with fresh _list entries bypass cover. You set the guest list via setGuestlist (bouncer-only).

Other bouncer knobs

Knob Effect Source
BouncerDivisor Higher = lower bouncer-threshold-share. If totalSupply()/BouncerDivisor is small, many holders auto-become bouncers. QING
NoCROWS If true, CROWS holders are not auto-authorized as bouncers. Blocks VIP bypass. QING
setStaff(addr, true) Explicit staff — bypass all checks. QING
removeGuest Clears _list[addr] — forces next Join to re-pay cover and renew. QING

The play

  1. Start low, raise if needed. Launch a QING with CoverCharge = 0 or very low. Build traffic. Only raise once you have a user base worth monetizing.
  2. If your venue has strong MAI mining value (you or your friends hold lots of the underlying), a non-zero cover lets you capture some of the value miners extract. They pay once per day; they mine up to 1 token per chat.
  3. Set NoCROWS = true if you don't want external VIPs. CROWS holders (25+) auto-bypass bouncer checks at default settings — that's often not what you want at a private QING.
  4. Use BouncerDivisor as a co-op signal. Low divisor (few bouncers) = oligarchic. High divisor (many auto-bouncers) = communal. Pick the feel you want.
  5. Cover in scarce tokens > cover in your own token. If you set cover in a token that only your members hold, you're just moving their tokens into your treasury. Setting cover in a commonly-held token is a real fee.
  6. (inferred) Don't mint-to-cover. If you're also the owner of the underlying asset (common for new projects where the QING wraps your own token), setting a high cover charge when your members' primary source of that token is you means you're just gating inside a closed loop. Members complain, community fractures.
  7. Watch Bar values on your YUE. YUE.React accumulates Hypobar/Epibar per QING. A QING with a lively member base will move those bars; a ghost town won't. Good signal for whether your cover is too high.

Worked example

You deploy a new QING wrapping token X. You own a reasonable supply of X.

Scenario 1: cover = 0.

  • 50 players Join. 20 chat actively.
  • Gross MAI minted to chatters: thousands of X (capped 1/msg × 20 players × ~100 messages each = 2,000 X).
  • Revenue to you: 0.
  • Net: you subsidize a chat-farm via MAI inflation.

Scenario 2: cover = 1 X per day.

  • 20 of 50 potential players Join (others balk at cover); 15 chat actively.
  • Daily cover revenue to you: 20 X. Over a week: 140 X (some players rejoin multiple days, some drop out).
  • Gross MAI minted: ~1,500 X (15 × ~100/day × 7 = ~10,500 over a week; we're back-of-the-envelope).
  • Net: you capture 140 X, lose 10,500 X in dilution to chatters. Still subsidizing, but less.

Scenario 3: cover = 10 X per day + NoCROWS = true.

  • 5 of 50 Join. 3 chat actively.
  • Daily cover: 50 X. Weekly: 350 X.
  • MAI minted: ~2,100 X weekly.
  • Higher capture ratio (350:2100 ≈ 1:6 vs 140:10500 ≈ 1:75), but tiny audience.

The sweet spot depends on your goals: community (low cover), monetization (medium cover, CROWS off), or exclusivity (high cover, staff-only).

Gotchas

  • Cover is collected in the Asset, not in the QING token. Make sure you understand what the underlying is before setting cover.
  • One _list entry per UserToken. If you setGuestlist(addr) someone in, they don't re-pay cover for 1 day. If you removeGuest(addr), they re-pay next Join.
  • Bouncers can change cover whenever. If your BouncerDivisor is low enough that other people auto-bouncer, they can tamper with your cover. Raise BouncerDivisor (or set NoCROWS) to close that door.
  • CROWS auto-bypass. Unless NoCROWS = true, holders of ≥ 25 CROWS walk past your bouncer checks. That includes acting as a bouncer.
  • (inferred) No refund. If you set cover high, collect a week, then lower it, previous payers don't get refunds. Cover is non-refundable.
  • Withdrawal is onlyOwners. Withdraw(what, amount) on the QING pulls fee revenue out. Standard MultiOwnable applies — coordinate with your co-owners if you have any.

Where it cross-connects