Buyback campaign Terms

Terms

One rule about where things live: nothing that could surprise a participant goes into small print. What is here is definitions and procedure, not disclaimers.

DefinitionsWhat each word means here

Exact definitions

The miner’s reward for your blocks
the sum the network paid to the miner for blocks your address mined inside the announced range; in the explorer it is the Miner Coinbase Reward column. Each block’s emission is split: part goes to the miner, part to the holders of the tickets that voted on that block. Only the first part counts. This is not what arrived at your address, and not its balance. Three things follow, and all three are properties of the calculation rather than requirements on you: VAR transferred into the address does not raise your cap; ticket voting rewards are not included, because they are a different kind of transaction paid to a different address; and anything mined before the range began is not included either. Nothing else can enter this sum — not because we police it, but because the sum is computed from block rewards paid to the miner.
Campaign range
blocks 33,501 to 42,140 inclusive, 8,640 blocks.
Your cap
the miner’s reward for your blocks inside the range × 50%, up to 27,000 VAR. The 27,000 belongs to the mining address and is counted across every claim made from it that we buy — a claim that fails a check consumes none of it; claims are taken in the order their transfers arrived.
Payout condition
subscribed to the channel @monetarium_world and a member of the group @monetarium_world_chat. Two conditions, checked separately: the Telegram @username in your claim is looked up in the channel’s subscriber list and in the group’s member list. It is the one condition that is not read off the chain — nothing about your transfer or your signature carries it — so it alone is met without submitting anything: subscribe, join, and reply to our email. It is a payout condition like any other, and it has to be met before a window closes: by the main window’s close to be paid with the main batch, by the late window’s close to be paid at all. Subscribe when you claim, not when we write — we check after the main window has shut, so an email from us about it already means the main batch has passed you.
Main window
7 days from the moment block 42,140 is mined. Claims, and the last moment a transfer can arrive. A transfer sent earlier, while the range was still running, counts too — the window is a deadline, not a start. It is still worth waiting for the range to close: your cap is the miner’s reward for the whole range, so before it closes you are transferring against a number you cannot yet read, and anything above your cap comes back with the payouts instead of being bought. The exact closing time is published in UTC as soon as the end block is mined, so nobody has to work out whose midnight is meant. Block 42,140 was mined at 15 October 2026, 02:16 UTC, so the main window closes at 22 October 2026, 02:16 UTC and the late window at 15 March 2027, 02:16 UTC.
Settlement window
the 7 days from the close of the main window to the payout. This is when we check the main window’s claims and pay them; nothing is repaired here for the main batch, because everything that had to be true of a claim had to be true by the time the main window closed. A repair made after that close is not lost — the claim moves to the late track and is paid on day 151 instead.
Late window
from the close of the main window to +144 days. Open to anyone who did not make the main window — not only to those whose VAR was locked in tickets. A claim is paid with the window it was put right in. Everything that has to be true of it — the signature, the USDT address, the mining address among the inputs, the subscription and the group — has to be true before a window closes: before the main window closes to be paid with the main batch, before the late window closes to be paid with the late one. So a claim filed inside the main window and put right after it is filed on one track and paid on the other, and a claim still not put right when the late window closes is not paid at all. The length is set by the slowest case it has to cover: 41,472 blocks is the longest a ticket can hold coins — 256 blocks to maturity, 40,960 to expiry, and 256 more for the returned output to mature.
Rounding
VAR carries 8 decimals, USDT 6. Your payout is the VAR that arrived × $0.10, rounded to the nearest cent.
Where returned VAR goes
back to the address your transfer came from. It is not taken from anything you type into the form: the chain already records where the coins came from, and only that address’s owner holds its key. In the ordinary case it is your mining address, because that is where the transfer leaves from. If your transfer drew on several of your addresses, the return goes to the one that put in the most. Returns move with the payouts — the batch of the window your claim finally ended in, within 7 days of that window closing. Nothing leaves our side before then, and nothing goes back while a repair is still open to you: if your claim can still be put right in the late window, its return waits for that window to close.
SigningTransfer first, then sign

How to sign your claim

One wallet command. You do not need to unlock the wallet, and you do not need to configure monetarium-ctl: after the installer the wallet stays unlocked and ctl already knows both the node and the wallet.

The order matters — transfer first, then sign: the transaction id of your transfer is part of what you sign.

Have your USDT address chosen before you sign as well — it is inside the same string, so changing it afterwards means signing again.

This is the exact string that gets signed:

monetarium-promo:<transaction id>:<your USDT address>

The command

monetarium-ctl --wallet signmessage "<your mining address>" "monetarium-promo:<transaction id>:<your USDT address>"

One note about copying, and it is about spaces. What gets signed is exactly that string: no quotes, and no trailing space or newline. One extra character makes it a different string, and nobody holds a signature over that one. The quotes in the command are shell syntax, not part of the message — the string contains no spaces, so the command works without them too.

You can check yourself before you submit, on our signature verification page — monetarium.online/verify-message. Enter the address, the message and the signature, and you see exactly what we will see.

A complete example:

Address:   MsjMpQD65rGvGQgPttkkH57qRYxiZafeVzd
Message:   monetarium-promo:e8cdb5bf0297dee5e47cbbaa013bb4600716eb29db9d7254947c9330fe0be06a:TKPBgf5aMA9EEANE5xNxcswnKhh3nGqf9C
Signature: H9Tzogamad0CDDGuELwqA4Ny8YMnybWKqy8iRGihfOJ9RcpSB9SK8k2NWyzMaTTTKw6eKc/g0UxwKhYIttnJUuA=
Why a signatureWhat it proves, and what it does not

Why a signature is required

Addresses and their payouts are public: anyone can open the explorer, find an address with large payouts and file a claim in its name. The signature proves the address is yours. Your key is never revealed, no coins move, and no fee is paid.

What gets signed is not an arbitrary string but the transaction id of your transfer together with the USDT address, for two reasons.

A transaction id is not a secret. Transfers to our address are visible to the whole network, and anyone can quote someone else’s. But a signed id turns that substitution into a collision of two claims on one transfer, and a collision is visible before any money moves — we pay in one batch after the window closes. Claiming first wins nothing.

And the USDT destination cannot be substituted, in transit or on our side: it is inside what you signed. That does not make it final, only unforgeable: while the window is open you may submit a new claim for the same transfer, signed by the same mining address and naming a different USDT address — the last valid claim before the window closes is the one that stands.

DisputesWhich signature decides

How disputes are settled

Two claims on one transfer. We look at which address signed each one.

The same mining address
a re-submission, not a dispute: the last valid claim before the window closes stands. Our own rules produce these: when a signature fails we ask you to submit again, and a form is only submitted whole. An unconfirmed subscription or group membership is the one case that does not work this way — it needs no new signature, so it is settled by email and no second form is filed. The deadline is the same as for everything else about a claim — the close of your track’s window. But we check after the main window has shut, so meeting the condition then moves the claim to the late track.
Different addresses
a collision. Both claims wait until the window closes and no money moves on either. The right is settled by a signature from one of the addresses the transfer was sent from: they are listed among the transaction’s inputs, and only the sender holds their keys. Same command, same verification page.

The same input check runs on every claim, not only on a collision: your mining address has to be among the transfer’s inputs, because a signature proves the address is yours and only an input proves the transfer is. It usually never gets that far — the transfer leaves the mining address itself, so the input already matches the claim. The second signature is needed whenever it does not — a second wallet of your own, or VAR that came back from tickets onto other addresses of the same wallet — and it is needed then whether or not anyone is disputing your claim.