Skip to main content

Treasury & Admin

merca.earth is operator-run. The team controls the treasury and can upgrade the protocol. This page is full transparency on who has what power and why.

Treasury As Project Revenue​

A share of every payment goes to the protocol treasury. This is project revenue — it funds development and operations, not a community pool.

Current documented splits:

  • register and expand_unclaimed: 92% treasury, 8% hierarchy pool
  • buy_full and acquire_slice: 85% seller, 7% treasury, 8% hierarchy pool

See Fees for the current breakdown.

Operator Control Model​

The team holds four capability objects that grant admin authority over the protocol:

  • AdminCap — controls the spatial index (parcel removal, cap rotation)
  • MarketAdminCap — controls the market (treasury withdrawals, pause, tax config, board creation)
  • UpgradeCaps — one each for the protocol and market packages; required to publish upgrades

All four are currently held by a team multisig. Treasury withdrawals, upgrades, and all admin operations require multisig approval. The signer sets for the two multisigs may partially overlap. Do not assume signer independence unless the project publishes it explicitly.

The audit report states that the MarketAdminCap holder can withdraw treasury funds. Users should know this authority exists before they use payment-bearing flows.

Admin Powers​

Pause and Unpause the Market​

The operator can halt all high-impact market operations — registration, buyouts, and geometry mutations — with a single transaction. While the market is paused, those operations are blocked for all users. The operator can resume them at any time.

This power exists as an emergency brake: if a critical bug is discovered, the team can stop further damage before a fix is deployed.

Tax Configuration​

The operator sets the tax rate and per-level tax parameters. Each spatial level (block, neighborhood, district, and so on) can carry its own tax configuration. The operator can update these at any time.

Tax configuration changes take effect for new tax periods. Existing tax buckets already accrued are not retroactively recalculated.

Proposal Boards and Mark Boards​

The operator creates the shared objects that power the POI proposal system and the parcel marking system. Without an active proposal board, users cannot submit POI proposals for a given spatial index. Without a mark board, the marking feature is unavailable.

Creating these boards is a one-time setup step per deployment. Once created, they are shared objects — any user can interact with them within the rules of the protocol.

Parcel Removal​

The operator holds the ability to remove any parcel from the spatial index. This is an emergency operation intended for corrupted state (e.g., zero-area polygons caused by edge-case geometry bugs that cannot be fixed retroactively through a code upgrade alone, since the broken data already exists on-chain).

When a parcel is removed by admin:

  • Any pending tax buckets for the parcel are swept to treasury.
  • Uncollected tax buckets (pending collection by parent parcel owners) are swept to protocol treasury.
  • The parcel itself is destroyed. Registration cost and premium investment are not refunded — the protocol never held those funds (they went to the previous seller or treasury at the time of the original transaction).

No refund mechanism exists because it would create a fraud vector: an owner could inflate premium through repeated buy_full cycles and then request removal to extract value that was never deposited into the protocol.

What You Should Not Assume​

  • No decentralized governance. The team makes decisions. There is no DAO.
  • No community treasury. Revenue funds the project, not a community pool.
  • No signer independence. Treasury and upgrade signers may overlap unless explicitly stated otherwise.

Read With Context​

Last updated on