QUOTEXbrokers documentation

QUOTEXbrokers is a collectible game on Robinhood Chain. It consists of 4,444 non-fungible worker tokens, 4,444 computers they can optionally run, a fungible payroll token with the ticker $QTX, and a browser client that renders every worker at a fixed desk in a single shared office.

Status: draft · Version 0.1 · Updated 2026-09-01 · Chain ID 4663

Overview

Each worker token is an entry on a fixed staff roster of 4,444. A worker occupies one permanent desk in the office client and holds a mutable employment state. A worker in the INACTIVE state earns nothing and is rendered as an unoccupied desk. A worker in the ACTIVE state earns a share of hourly payroll and is rendered as an occupied desk.

The state transition from INACTIVE to ACTIVE requires burning 25,000 QTX. This is the primary demand mechanism for the token. Additional burns raise a worker's pay grade, which raises its share of payroll.

Payroll is funded from three measured revenue sources: trading fees on QTX, cosmetic item sales, and secondary market royalties. Payroll is distributed once per hour in proportion to worker weight. The distributed amount is determined by revenue collected in that hour and is not fixed.

A second collection of 4,444 computers sits alongside the roster. A computer is optional equipment, not a second staff roster: installing one multiplies a single worker's weight while it stays plugged in, and a worker without one earns normally. Computers can be lent to other holders for a share of what they earn. See Computer reference.

Scope of this document

This document specifies token parameters, state transitions, payroll arithmetic, revenue allocation, and access control. It does not cover client rendering internals, sprite generation, or wallet integration. For mint pricing, see Parameter reference; that value is undecided.

Architecture

The client is a set of static files. It has no backend, no database, and no server-side session. All state that affects payroll is held in contracts on Robinhood Chain. The client reads that state over a JSON-RPC endpoint and writes to it only through transactions signed by the user's wallet.

Terminology

The following terms have exact meanings in this document. Two pairs are commonly confused and are kept lexically distinct for that reason: rank against pay grade, and burn against transfer.

Worker reference

Each worker is generated once. No two workers share an identical trait combination. There is no delayed reveal; the assigned artwork is readable immediately after mint.

Seat assignment

Desks are assigned by a seeded Fisher-Yates permutation of the office seat list. The seed is a fixed constant. The permutation is therefore stable: tokenId 1204 resolves to the same desk on every client load, for every visitor, indefinitely.

seats = seededShuffle(officeSeats, 20260901)
desk(tokenId) = seats[tokenId]

Seats are not interchangeable. The office floor plan produces four seat classes, distributed unevenly by construction:

Seat class is published as a trait. It is derived from the floor plan and the permutation, both of which are fixed, so it is independently reproducible.

Rank reference

Rank is assigned at generation and never changes. Higher ranks draw from restricted accent and background palettes. Rank does not affect payroll.

$QTX token reference

QTX is a fixed-supply ERC-20 token. Its function is to be burned. Every game action that changes a worker's earning capacity consumes QTX permanently.

How the pool is launched

QTX is deployed through letscash.fun on Robinhood Chain rather than by a contract written for this project. A single transaction deploys the token, mints the entire supply into a Uniswap pool, and locks the liquidity position at the platform's factory locker. Table 5's zeroes for team allocation, presale, and pre-mine are a consequence of that mechanism rather than a policy applied on top of it: there is no allocation step at which any account could be favoured, and every QTX that is ever burned must first be bought from the pool.

The trade fee is chosen once, from a fixed menu, and cannot be altered afterwards by anyone. The platform keeps 0.3 percentage points of it. The remainder is paid out in ETH and never in QTX, which matters to payroll in two ways: the protocol is never required to sell its own token to pay anyone, and the buyback destination is a real market purchase rather than a transfer of tokens the protocol already held. It also means the pot arrives in the chain's native asset, which is what Payout calculation already assumes.

One property of the launch is not fixed, and it is stated here rather than left to be discovered. The recipient of the trade fee is an address the deploying account can reassign for as long as the coin trades. Pointing it at the splitter is what makes the published allocation real; nothing in the launchpad prevents it from being pointed elsewhere later. The splitter's own behaviour is immutable; the stream into it is not, and no wording in this document should be read as a guarantee of the latter.

Supply dynamics

Two independent mechanisms remove QTX from circulation, and because there is no mint function after deployment, nothing returns it.

1. Direct burns. Activation, promotion, and merge operations burn QTX supplied by the user.
2. Buyback burns. A fixed share of all revenue purchases QTX on the open market and burns it. See Revenue allocation.

Activate a worker

Activation moves a worker from INACTIVE to ACTIVE and enrolls it in hourly payroll at pay grade 1.

Before you begin

• Hold the worker token in a standard externally owned account. Smart-contract accounts and multisig accounts are not supported.
• Hold at least 25,000 QTX in the same account.
• Hold enough of the chain's native asset to pay gas.

Procedure

1. Connect the wallet holding the worker.
2. Select the worker and call activate().
3. Approve the QTX allowance, then confirm the transaction.

The contract burns 25,000 QTX, sets state to ACTIVE, sets payGrade to 1, and increases burnedTotal by 25,000.

Timing

Payroll periods are aligned to the hour. A worker activated at 14:42 becomes eligible at 15:00 and receives its first distribution when that period is processed. Expect approximately two hours between activation and first delivery.

Promote a worker

Promotion raises payGrade by one level and increases the worker's grade multiplier. Grade thresholds are expressed as cumulative burnedTotal, not as incremental payments. The step cost is the difference between the current and target thresholds.

Procedure

1. Confirm the worker is ACTIVE. Promotion of an INACTIVE worker reverts.
2. Call promote() with the target grade.
3. Confirm the transaction. The contract burns the step cost and increments payGrade.

Promotions are permanent, attach to the token, and survive transfer. A worker sold at grade 4 arrives at the buyer at grade 4; the buyer must still pay the 25,000 reactivation burn, but does not repay the 300,000 already accumulated.

Merge workers

A merge combines 2 or 3 workers into a single surviving token. The surviving token retains its own tokenId, artwork, rank, and desk. All other workers in the operation are destroyed.

Three workers is the maximum group size. Weight is computed by summing the pre-merge weights of all participants and multiplying the sum by mergeMultiplier:

The multiplier is set above the promotion that the same QTX would buy. 50,000 QTX spent on burning promotes one grade-1 worker to grade 2 and adds 0.4 weight. The same 50,000 spent on a 2-way merge of two grade-1 workers returns (1.0 + 1.0) × 1.60 = 1.60, which is 1.2 more weight than one of them carried before — but on one token instead of two, and the other token is gone for good. Merging trades headcount and future upgrade paths for weight density; it is not the cheaper route to weight.

The surviving worker inherits the vaultBalance of every destroyed worker. The desks of destroyed workers become permanently unoccupied, and roster headcount decreases.

Collect pay

Each worker has a payoutMode that determines delivery:

Procedure

1. Call setPayoutMode() and setPayoutAsset() per worker. The default asset is USDG.
2. For VAULT mode, call withdrawVault(tokenId) for one worker or withdrawAll() for every worker held by the caller.

Any account may call the period processing function. Project automation is a convenience and not a permission; if it stops, holders can process periods themselves.

Asset selection

Assign one payout asset per worker. Splitting a single worker's payout across multiple assets subdivides an already small hourly amount, and the resulting fractions frequently fall below the minimum economical swap size. Such fractions remain unconverted rather than being lost.

Computer reference

A computer is a token in a second collection of 4,444 machines, minted once and independent of the worker roster. Holding a worker grants no computer and holding a computer grants no worker. The two sets are unrelated, and one wallet may hold any number of either.

A computer does exactly one thing. While it is installed on an ACTIVE worker, that worker's weight is multiplied by the computer's tier multiplier — between ×1.05 and ×1.50. It changes nothing else: not rank, not desk, not pay grade, not payout asset, not the worker's artwork. A worker with no computer earns normally. A computer is an upgrade to a worker's payroll weight, never a precondition for being paid.

One machine, one desk

A worker runs at most one computer, and a computer sits on at most one worker. There is no stacking: two machines cannot be pointed at the same worker to compound their multipliers, and installing a second machine on an occupied worker is rejected rather than replacing the first. Uninstalling is free and immediate, and the worker returns to the weight it had without a machine.

Where the artwork appears

Each machine has its own animated artwork, drawn at 512×512 and served alongside a 144×144 thumbnail. It appears on the borrow market, on the Computers tab of the staff control page, and wherever the collection's metadata is read by a marketplace. The office floor plan renders desks and workers only — a computer is never drawn in the office, and installing one does not change how a desk looks.

Configuration and tiers

Every machine carries a full spec sheet. Eight of its axes are scored; cores, clock, and model year follow from the CPU and are descriptive only. Each axis is a ladder of rungs from worst to best, and a machine's config_score is the weighted sum of the rung it reaches on each:

The axes are not drawn independently. Each machine is given one overall build quality first, nudged a little by its chassis, and every axis is then drawn near it. A machine is therefore coherent — a 500 MHz eight-core desk does not ship with a cassette tape — and the score distribution keeps real spread instead of collapsing to the mean, which is what eight independent draws would produce. The chassis shift is small next to the per-machine spread, so a well-specced classic desk out-scores a neglected dark one: chassis correlates with tier, it does not decide it.

Tier assignment

Machines are ranked by config_score, ties broken by id, and tiers are cut by rank position in fixed counts. The supply behind every multiplier is therefore known at mint and cannot drift when the parts ladders are retuned:

Score ranges are observations of the generated collection, not the rule. Tier is decided by rank alone, so two machines sharing a score can fall on opposite sides of a boundary; the machine with the lower id takes the better tier.

The nine founder machines

Ids 0–8 are the desks of the nine founder workers and are built to a spec floor. They reach MAINFRAME because their parts are the best in the collection, not by exemption: every one of the nine earns its rank on config_score like the other 4,435. Their sheets still differ from each other, near the top of each ladder rather than at it.

Install a computer

Installing plugs a machine into one worker's desk and multiplies that worker's weight. It costs no QTX, takes effect from the next payroll period, and can be undone at any time.

Four preconditions. The worker must be yours and ACTIVE — a machine multiplies a weight, and an idle worker has none, so installing onto an unhired worker is refused rather than silently wasted. The worker's desk must be empty: one machine per desk, no stacking. The machine must be yours and not out on lease, or one you are currently borrowing. And the machine must not already be installed somewhere else; move it by uninstalling first.

The install writes two fields on the worker — the machine's id and its multiplier — and one on the machine, the worker it now sits on. Weight is then recomputed:

A grade-3 founder on a merged desk with a SERVER installed: baseWeight 1.9 × 1.5 × 1.60 = 4.56, and 4.56 × 1.35 = 6.156. The firm's Σ weight rises by 1.596 the moment the machine goes in, which is the only reason anyone else's payout moves: a machine does not create pot, it changes how the pot is divided.

Uninstalling

Uninstalling is free, immediate, and reversible. The worker's weight drops back to baseWeight and the firm's Σ weight follows. Nothing is refunded because nothing was paid, and the worker keeps working — it simply earns at its own weight again. Either side of a lease may uninstall a borrowed machine: the borrower to move it to a different desk, the owner never, because while the lease runs the owner cannot touch it at all.

What a machine survives

Lend and borrow

A machine you are not using can be lent to someone else's worker for a fixed number of payroll periods, in exchange for a share of what that worker earns while it is installed. The token never leaves your wallet.

Lending grants a usage right, not the token: an address recorded as the machine's current user together with the period the right expires. Every read of the market and of your own machines sweeps expired rights first, so a lease ends on time whether or not either side does anything about it. This is the ERC-4907 pattern, and it is the reason the guarantees below are structural rather than promises — the borrower is handed a right that reverts, never the asset.

A borrower cannot steal or sell a borrowed machine because a borrower is never given anything that could be stolen or sold. The token stays put; what moves is a right with an expiry on it.

Listing terms

An owner sets two things. The share, in basis points, must fall inside the band the machine's tier allows — a MAINFRAME may ask 1.5%–2%, a TERMINAL 0.1%–0.4% (Table 10). Better machines command more because they are worth more to the borrower, and the band keeps that relationship from inverting. The term is one of three fixed lengths:

A machine can only be listed while it is idle — not installed on one of your own workers, not already out on lease. Taking a listing down is free and immediate, and does nothing to a lease already running.

How the owner is paid

Out of earnings, every period, never up front:

The cut comes off the borrowing worker's payout before it reaches that worker's vault, and is credited to the owner. Worked: a worker at weight 6.156 in a firm at Σw 240 with a 150 USDG pot takes 150 × 6.156 ÷ 240 = 3.8475 USDG for the period. On a SERVER borrowed at 1.25%, the owner receives 3.8475 × 0.0125 = 0.0481 USDG and the worker banks 3.7994.

Two consequences follow, and both are deliberate. A borrower who never installs the machine pays nothing at all — there is no rent, no deposit, no minimum. And an owner whose machine is borrowed but left in a drawer earns nothing, which is why the share is charged on output rather than on time. Lending is profitable exactly when the machine is put to work.

The borrower still comes out ahead: the machine adds 35% to that worker's weight and costs 1.25% of its payout. The share bands are set well below every multiplier they attach to, so borrowing is positive for both sides at any legal ask — the negotiation is over how the gain splits, not whether there is one.

Lifecycle

Weight calculation

Weight is the only worker property that determines payroll share, and it is the product of exactly four multipliers — no other field in the token participates.

The split matters. baseWeight is what the worker owns: it can only go up, and every step of it was paid for by burning QTX. The computer factor is borrowed capacity — free to apply, free to remove, and gone the moment the machine is uninstalled or a lease expires. A merge is computed on baseWeight alone, which is why a machine is never baked into a survivor.

Payout calculation

Each hourly period, the payroll pot is divided among all ACTIVE workers in proportion to weight:

Worked example

Assume pot = 100 USDG, 3,000 active workers, and Σw = 4,200. A grade 3 worker with no founder or merge multiplier has w = 1.9:

payout = 100 × (1.9 / 4200)   = 0.04524 USDG

Promoting that worker to grade 5 sets w = 3.5 and raises Σw to 4,201.6:

payout = 100 × (3.5 / 4201.6) = 0.08330 USDG

Borrowed machines

When a worker's payout is computed on a weight that includes a borrowed machine, the owner's share is deducted from that worker's payout before delivery:

The cut is settled every period out of that period's earnings. Nothing is charged in a period where the worker earns nothing, and the owner is never paid from the borrower's balance — only from what the machine helped produce. See Lend and borrow.

Dust handling

Payroll is collected in the chain's native asset and converted to each worker's payoutAsset in batches. If a worker's share is worth less than the cost of converting it, the amount carries forward to the next period until conversion is economical. Carried amounts do not expire.

Pay grade reference

Thresholds are cumulative burnedTotal values. The efficiency column is gradeMultiplier ÷ (burnedTotal ÷ 25,000), normalized so grade 1 equals 1.00.

Pay grade titles are deliberately disjoint from rank names. A worker can hold rank Intern and pay grade Golden Parachute simultaneously, or rank Legendary and pay grade 0.

Desk rendering by grade

The client renders pay grade as visible desk furniture, so grade is observable without reading contract state.

Founder bonus

Nine workers carry isFounder = true and a fixed founderMultiplier of 1.5. The field is immutable and cannot be acquired, purchased, or granted. The founder count is fixed at 9 and cannot be increased.

The founder multiplier composes with the other three factors:

w = 3.5 × 1.5           =  5.2500  // grade 5 founder, never merged
w = (3 × 5.25) × 2.10   = 33.0750  // three grade-5 founders merged into one
w = 33.075 × 1.50       = 49.6125  // that survivor, running a MAINFRAME

The second line is the maximum baseWeight a single token can own, and reaching it means destroying two of the nine founder tokens. The third is the protocol maximum weight, but it is not owned — it lasts only while that machine stays installed, and a borrowed MAINFRAME pays up to 2% of the worker's payout to its owner for the privilege.

A founder in the INACTIVE state has w = 0 and receives no payroll. The founder multiplier does not exempt a worker from activation or reactivation.

Vault

Each worker holds a vaultBalance. When payoutMode is VAULT, hourly payouts accumulate in that balance instead of being sent to the owner's account.

The vault is a property of the token, not of the account. On transfer, the balance moves with the worker. This makes a funded worker a quantifiable listing: grade, merge multiplier, founder flag, seat class, and vault balance are all readable from chain state before purchase.

Transfer behavior

Transfer sets state to INACTIVE. This applies to every transfer, including sales, gifts, and moves between accounts controlled by the same person. The worker stops accruing payroll in the period of the transfer, and its desk renders as unoccupied.

Transferring a computer follows the same principle from the other side: the machine carries its tier, multiplier, and lending band, all immutable, and arrives uninstalled. A computer with a lease running cannot be transferred at all until the term ends — the buyer would otherwise inherit an obligation they never agreed to.

Revenue allocation

Three revenue sources fund the protocol. Each source has a fixed allocation across three destinations. Every allocation sums to 100% of the amount that reaches the splitter; there is no unallocated remainder. The QTX trade fee is the one source that is reduced before it arrives, because the launchpad keeps 0.3 of its 3 percentage points — see How the pool is launched.

Destination behavior

• Payroll. Added to the current period pot and distributed by weight.
• Buyback and burn. Purchases QTX on the open market and sends it to the burn address.
• Operations. Funds art, development, hosting, and promotion.

There is no liquidity destination. The pool holds the entire supply and its position is locked with no withdrawal path, so revenue cannot deepen it; opening a second position would produce liquidity that could be withdrawn, which is the opposite of the guarantee the lock exists to give. The buyback destination is the closest substitute, since it also spends revenue on QTX, and it is the reason buyback carries 20% of the trade fee rather than a smaller share.

The mint is not a revenue source. Mint price is undecided and may be zero; protocol funding does not depend on it.

Burn sink analysis

Sink capacity is the total quantity of QTX that game actions can permanently remove. It determines whether token demand terminates after an initial adoption phase.

Two observations follow from these figures.

1. One-time capacity exceeds supply. S_grade is 3.78× total supply. The promotion ladder alone cannot be fully consumed, so the ladder never saturates.
2. Recurring capacity is unbounded. S_reactivate has no terminal value because it is a function of transfer volume rather than of token count. At an average of two transfers per worker per year, annual reactivation burn is 4,444 × 2 × 25,000 = 222,200,000, or 22.22% of initial supply per year.

For comparison, a design in which activation burns once and never repeats caps its sink at S_activate. Under this collection's parameters that ceiling would be 11.11% of supply, reached permanently once the last worker is activated, after which the mechanism generates no further demand.

Cosmetics

Cosmetic items change desk and floor appearance. They are purchased with the native asset or QTX. They do not modify payGrade, mergeMultiplier, isFounder, or weight, and they confer no payroll advantage.

Cosmetics exist to decouple part of payroll funding from QTX trading volume. Trading fees are correlated with speculative activity: in a low-volume period, a trading-fee-only pot approaches zero, which reduces payouts, which can further reduce participation. Cosmetic revenue is generated by gameplay purchases and is not conditional on trading volume, so it continues to fund payroll during low-volume periods. It is expected to be the smaller contributor in high-volume periods.

Parameter reference

Limitations

Payroll is variable

The pot equals revenue collected in that period. There is no minimum, no guaranteed rate, no annual percentage yield, and no target. A period with no trading, no cosmetic sales, and no resales produces a pot of zero and pays nothing. Historical payout figures are measurements of past periods and are not forecasts.

Payout depends on other participants

Payout is a share of a fixed pot, so it falls when Σw rises. Activations, promotions, and computer installs by other holders reduce your payout without any change to your own workers.

Lending is not a yield

An owner who lends a machine is paid a share of what the borrowing worker earns, and nothing otherwise. A borrower who never installs it, a borrowed machine sitting on an INACTIVE worker, or a period with an empty pot all pay the owner zero. The share is a claim on output, not a rental fee, and a lease carries no minimum. An owner also gives up the machine's own multiplier for the whole term: lending is an exchange of certain capacity for uncertain income.

Revenue is partly reflexive

The trade fee is a function of QTX trading volume. Reduced volume reduces payouts, which may reduce participation, which may further reduce volume. Cosmetic revenue and royalties are not conditional on QTX volume and dampen this feedback, but they do not eliminate it. Which source is largest in a given period is a measurement rather than a design choice: the trade fee delivers 2.7% of QTX volume and the royalty 10% of secondary NFT volume, and those two volumes move independently.

Royalties are not enforceable

The royalty on each collection is an ERC-2981 signal that a marketplace chooses to honour. A sale on a venue that ignores it pays this protocol nothing, and no contract here can compel that payment or even observe the omission. Royalties carry 50% of their amount to payroll, so a migration of secondary volume to non-honouring venues reduces payouts with no cause visible on chain. The rate also cuts against the recurring burn sink: a higher royalty raises the cost of reselling a worker, and resale is the transaction that forces re-activation.

Irreversible operations

• Burns cannot be refunded or reversed.
• Merges destroy NFTs permanently.
• Chain transfers cannot be recalled.
• Loss of a wallet recovery phrase results in permanent loss of all assets in that account.

Operational constraints

• Payouts below the economical conversion threshold are delayed, not lost.
• Splitting one worker's payout across several assets can leave fractions permanently below the minimum swap size.
• A transferred worker earns nothing until 25,000 QTX is burned again.
• Payout assets are issued by third parties. Availability is outside protocol control; the asset menu can be edited but the assets themselves cannot.
• Smart-contract accounts and multisig accounts are not supported for mint or activation.

Fraud exposure

• No QTX contract exists at the time of writing. Any token using that ticker is fraudulent.
• Mint only from an address published on an official channel. Cloned mint pages are the most common loss vector for collections of this type.
• The project does not initiate direct messages, does not request recovery phrases, and does not ask holders to validate or synchronize a wallet.

Access control

One operator key exists after launch. The following tables state its exact scope.

Artwork and metadata are pinned on IPFS. Collection administrative controls are relinquished after launch. Every statement in these two tables is verifiable in contract source; none should be accepted on the basis of this document alone.

Contract addresses

The computer collection is deployed and verified. Everything else is listed here as it ships, with every address linked to Robinhood Chain Blockscout. An address absent from this table is not part of this project.

A live metrics panel reading from chain state will accompany the registry: workers activated, QTX burned, cumulative payroll distributed, and the previous period's pot. That panel ships only when the underlying calls resolve. A verification surface that displays placeholders provides no verification.