GUD://PROTOCOL_DOCS

TECHNICAL WHITEPAPER

LIVE TERMINAL ↗
GUD TEK PROTOCOL

Systematic support.
Verifiable execution.

Gud Tek turns a tax-funded treasury into a bounded buyback-and-burn engine. It observes live pool conditions, confirms sustained weakness, executes staged micro-buys, and sends every acquired token directly to an unrecoverable burn address.

01. Abstract

Gud Tek is a treasury-controlled market support system for a token launched into an existing Robinhood Chain liquidity pool. Trading taxes fund the vault. A permissioned worker observes the market every 60 seconds and proposes executions. The onchain vault independently enforces price thresholds, confirmation timing, campaign budgets, cooldowns, reserve requirements, and spending limits.

The worker supplies observations and calls execution. The contract remains the final authority over treasury spending.

02. System architecture

01V4 POOL
02WATCHER
03VAULT
04SWAP
05BURN

Liquidity pool

The canonical pool supplies swap activity, price movement, and liquidity depth. The protocol reads market state without taking custody of LP positions.

Worker

An offchain process indexes swaps, calculates value-weighted pressure, refreshes observations, and calls public execution functions when a stage appears eligible. It cannot bypass contract limits.

Onchain vault

The vault holds the buyback reserve and records the peak reference, triggered stages, campaign state, daily use, and cumulative execution totals. Purchased tokens settle to the configured burn address.

03. Market signals

Drawdown

Drawdown is measured from the stored reference peak: (peak price − current price) / peak price. A stage becomes a candidate once its threshold is crossed. Recovery can refresh the reference according to the configured peak policy.

Value-weighted selling pressure

Trade value carries 85% of the pressure score while transaction count carries 15%. This lets one material sell outweigh many negligible buys. The default execution gate requires a combined score of at least 55%.

Liquidity and TWAP

Liquidity depth bounds the safe order size. A time-weighted observation and a second reading at least 60 seconds later reduce sensitivity to brief wicks and single-block manipulation.

04. Five-stage buyback ladder

Deeper drawdowns unlock larger campaigns. Each percentage is a bounded campaign allocation rather than one market order.

Stage 1 · −10%5% allocation across 5 micro-buys
Stage 2 · −20%8% allocation across 8 micro-buys
Stage 3 · −30%13% allocation across 12 micro-buys
Stage 4 · −40%18% allocation across 16 micro-buys
Stage 5 · −50%25% allocation across 20 micro-buys

Stage state is persistent. A completed level cannot spend its campaign allocation twice under the same ladder cycle.

05. Micro-buy execution

A qualified stage creates a campaign budget. The vault divides that budget into slices spaced 30 to 90 seconds apart. Before each slice, the system refreshes price, pressure, liquidity, treasury availability, daily usage, and minimum output.

  1. The watcher identifies an eligible stage.
  2. A later observation confirms that market conditions persist.
  3. The vault opens the stage campaign within all spending bounds.
  4. Each slice swaps quote asset for the target token.
  5. Output is delivered straight to the burn address and recorded in an event.

06. Treasury and execution safeguards

Slippage capMaximum 5%, enforced through minimum output.
Pool-relative capA slice cannot exceed the configured share of quote-side liquidity.
Daily treasury capAggregate daily deployment is bounded.
Permanent reserveA configured balance floor remains unavailable to campaigns.
CooldownsStages and slices require time separation.
Circuit breakerSevere conditions reduce size through up to four bounded halvings.

07. Transparent accounting

Every successful execution emits an onchain event containing the spend, token output, stage context, and transaction receipt. The terminal reconstructs these events, places buy-and-burn markers on the price chart, and displays cumulative treasury deployment and burned supply.

Public monitoring covers the vault balance, recorded peak, current drawdown, pressure score, liquidity estimate, stage mask, campaigns, execution count, quote spent, and tokens burned.

08. Roles and trust model

Worker role

The worker pays gas and submits observations or eligible executions. Its authority is constrained by the vault rules.

Configuration authority

The owner can manage documented parameters and operational roles where the deployed contract permits it. Changes remain visible onchain.

Market participants

Users trade through the underlying pool. Gud Tek does not custody user wallets or require deposits from holders.

09. Limitations and disclosures

Buybacks consume a finite treasury and cannot guarantee price appreciation, liquidity, execution, or recovery. Pool manipulation, adverse ordering, RPC interruption, contract failure, and extreme volatility remain possible. The system responds only when its configured gates pass. It does not promise a floor price or investment return.

Live figures shown in the terminal are monitoring outputs. The Robinhood Chain explorer and contract state are the source of record for confirmed executions.