> For the complete documentation index, see [llms.txt](https://parad0xlabs.gitbook.io/parad0xlabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://parad0xlabs.gitbook.io/parad0xlabs-docs/marketplace-.null-names/fees-and-governance.md).

# Fees & Governance

**For someone new to crypto:** when you sell a `.null` name on the marketplace, the protocol keeps a small cut of the sale — like the listing fee on an auction site. The question every marketplace has to answer is: *what stops the operator from quietly cranking that fee up to 30% next week?*

Our answer is to put the fee in a public on-chain account and put the **rules for changing it into the program itself**, where everyone can read them. The fee can be lowered the instant we decide to. But it can **never** go above 5%, and any attempt to raise it (within that ceiling) is announced on-chain 48 hours before it takes effect. You always get to see a raise coming.

**For the technically inclined:** the treasury cut on every secondary sale — buy-now, accept-offer, and English-auction settle — is read from an on-chain `AuctionConfig` PDA at settlement time, not from a hardcoded constant. Two invariants are enforced *inside* the deployed program: a hard `MAX_FEE_BPS = 500` ceiling, and an **asymmetric timelock** — decreases are instant, increases are queued 48 hours.

***

## Where the fee lives

|                     |                                                     |
| ------------------- | --------------------------------------------------- |
| Auction program     | retired/superseded — see config (pending) (mainnet) |
| `AuctionConfig` PDA | `55bVNW3E3VbuWo936VfkERT1YBcMbbMo2ZwLccQ3Y99o`      |
| Seed                | `["auction-config"]` (singleton)                    |
| Default fee today   | **500 bps = 5%**                                    |
| Hard cap            | **500 bps = 5%** (`MAX_FEE_BPS`)                    |
| Increase delay      | **48 hours** (`172,800s`)                           |
| Decrease delay      | none — instant                                      |

The account is tiny and entirely public. Anyone can fetch it and read the current fee, plus any pending change and the exact timestamp it would activate. The proof here is the account itself, not our description of it — go read `55bVNW3E…` on any explorer.

## The rules, enforced in the program

These are not policy promises. They are checks in the `SetFee` instruction; a transaction that violates them reverts.

| Rule         | Behaviour                                                                                                                                        |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Hard cap** | `SetFee` with `fee_bps > 500` reverts (`FeeTooHigh`). The 5% ceiling is fixed in code.                                                           |
| **Lowering** | Any value at or below the current fee applies **instantly** and **cancels** any pending raise.                                                   |
| **Raising**  | A higher value is **queued**: a `pending_fee_bps` plus an `effective_at = now + 48h`. The current rate is untouched until that timestamp passes. |
| **Reads**    | The effective fee is computed against the on-chain clock. A matured pending raise auto-activates on the next read.                               |

So the fee can be tuned in exactly one user-friendly direction freely (down), and the only other direction it can move (up, never past 5%) is visible on-chain 48 hours in advance.

## Decrease vs. increase: the timeline

A decrease and an increase are not symmetric. That asymmetry is the whole point — good-for-users changes are immediate; raises are slow and announced.

```mermaid
sequenceDiagram
    participant A as Authority
    participant C as AuctionConfig (on-chain)
    Note over C: current_fee = 500 bps (5%)
    A->>C: SetFee(300)  (decrease)
    Note over C: current_fee = 300 bps — effective NOW
    A->>C: SetFee(450)  (increase)
    Note over C: current stays 300 · pending = 450 · effective_at = T+48h
    Note over C: ...48 hours pass...
    Note over C: next read activates pending → current_fee = 450 bps
```

| Action                                  | When it takes effect                                       |
| --------------------------------------- | ---------------------------------------------------------- |
| `SetFee(300)` — a cut from 5% to 3%     | **Immediately**                                            |
| `SetFee(450)` — a raise from 3% to 4.5% | **At T + 48h**, announced on-chain the moment it is queued |
| `SetFee(600)` — above the cap           | **Reverts** — never possible                               |

## One caveat: the program is upgradeable

The fee logic above is real and enforced. But the program is **upgradeable**, so the precise claim is:

> **The fee is capped at 5% and can only go down — under the current program.**

It is **not** "immutable forever." A future program upgrade could, in principle, change these rules. This protection becomes truly ironclad only once the program's **upgrade authority is moved to a multisig or burned**. Until then, the guarantee is "the rules are on-chain, public, capped, and asymmetric" — strong, but contingent on the upgrade authority.

## When does the fee actually go down?

There is **no automatic on-chain mechanism** that lowers the fee. Lowering is a **manual founder decision**, made by reading real `$NULL` holder distribution and ecosystem maturity, then sending a `SetFee` transaction. The program *permits* and instantly applies a decrease; it does not *schedule* one. If you see a lower fee on-chain, a human chose it and it is real — but do not expect the number to drift down on a timer by itself.

## Status

* **LIVE on mainnet** — the `AuctionConfig` PDA exists under the auction program (program id being finalized — retired/superseded — see config (pending)), initialized with `current_fee_bps = 500` (5%) and no pending change.
* **LIVE / enforced in-program** — the 5% hard cap (`MAX_FEE_BPS`), the instant-decrease / 48h-queued-increase asymmetric timelock, and clock-based effective-rate reads. These are checks in the deployed `SetFee` / settlement code.
* **In-design / contingent** — moving the program's upgrade authority to a multisig or burning it. Until that happens, the "capped, can only go down" guarantee holds under the current program but is not immutable forever.
* **Manual, not automated** — any fee *reduction* is a founder decision based on holder distribution; there is no on-chain auto-lowering.
* The marketplace is **Public Beta, non-custodial, and not yet audited.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://parad0xlabs.gitbook.io/parad0xlabs-docs/marketplace-.null-names/fees-and-governance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.