BitAspire Wiki
CyberTokensCyberTokens

Payments & Transactions

Configure how CyberTokens handles /pay, taxes, transaction history, rollback, and cleanup.

CyberTokens treats every economy mutation as a transaction-oriented workflow. That is what makes /money-log, rollback, and retention policies possible.

Player payments

/pay is governed by config.currency.payments:

Setting areaWhat it controls
min / maxAccepted payment range
cooldownDelay between player transfers
allow-offlineWhether offline targets are allowed when global command settings also permit them
tax.*Optional percentage-based sink on each transfer

If tax is enabled, the sender pays the full amount and the receiver gets the amount minus tax.

Transaction history

When config.currency.transactions.enabled is true, CyberTokens stores a transaction record for balance changes and transfers. The log is what powers:

  • /money-log
  • last-transaction placeholders
  • /eco rollback
  • cleanup via /eco purge

Reasons can also be stored and capped in length through config.currency.transactions.reasons.*.

Administrative recovery

/eco rollback <transactionId> attempts to undo a stored transaction. It only succeeds when:

  • the transaction still exists
  • the transaction type is supported for rollback
  • the resulting balances still respect max-balance and non-negative rules

Rollback is useful, but it is not a replacement for proper staff permissions or database backups.

About the extra guardrail fields

The default config also exposes require-confirmation.* and anti-abuse.* branches under payments. Those keys are part of the public config surface, but you should verify their exact runtime behavior on your current build before depending on them for production policy.

Operational advice

If transaction history matters to your server economy, do not rely only on rollback. Keep regular backups of the configured database backend as well.

Last updated on

On this page