Venues — Cover-Charge Tuning (for Operators)

Evidence scope: The behavior below is from the pinned Solidity source. A source-file hash does not establish deployed bytecode equivalence. Check the selected deployment and caller before sending a transaction.

Bouncers control CoverCharge, BouncerDivisor, staff and guest-list entries. Direct QING owners control AllowCROWS, Rename, market rates and ownership. Creating a MAP venue establishes initial staff status, not a universal right to every owner method.

Cover is paid in the Asset from the Join caller to the QING when a paid entry is expired. It is not automatically collected on every Chat. A valid entry is not shortened by changing cover; setting cover to zero bypasses the expiry checks. Raising it again makes those checks relevant. Removing a guest does not prevent chat while cover is zero.

The play

Inspect actual role checks before configuring a room. Avoid a zero BouncerDivisor: candidates reaching that division can revert. Set only economically justified cover values after measuring actual demand and transfers. Chat payouts are conditional CHOA-token transfers; they are not newly minted inventory of the venue’s Asset and do not fund cover revenue automatically.

Use these calls here. Simulations preview the current state; each confirmed call is a separate transaction.

QINGResolve your player or venue above the call forms.

QING.CoverCharge()Read

Open this function to load its call form.

QING.setCoverCharge(uint256 _c)Simulate / call

Open this function to load its call form.

QING.AllowCROWS(bool _b)Simulate / call

Open this function to load its call form.

QING.setBouncerDivisor(uint16 _d)Simulate / call

Open this function to load its call form.

QING.Withdraw(address what, uint256 amount)Simulate / call

Open this function to load its call form.

YUEResolve your player or venue above the call forms.

YUE.Bar(address Qing)Read

Open this function to load its call form.

Sources

QING controls and CHOA payouts.