BitAspire Wiki
CyberTokensCyberTokens

config.yml

Global CyberTokens configuration for currency rules, database storage, commands, and autosave.

config.yml is the operational core of CyberTokens. It defines how the single currency behaves, where balances are stored, what limits player payments obey, and how cached user data is persisted.

Main sections

PathWhat it controls
config.currency.symbolCurrency symbol shown in formatted output
config.currency.name.single / pluralSingular and plural currency names
config.currency.format.*Output pattern, compact suffixes, decimals, trimming, rounding, overflow
config.currency.economy.*Starting balance, max balance, negative-balance protection
config.currency.payments.*Payment min/max, cooldown, offline targets, tax, and extra guardrail branches
config.currency.transactions.*Whether transaction history is stored, how long it is kept, and whether reasons are recorded
config.database.*Storage backend, credentials, table name, SSL, and SQLite file
config.commands.offline-players.*Whether commands may target or tab-complete offline users
users.request-throttle-msLightweight cache throttle for repeated lookups
users.autosave.*Autosave schedule, scope, and post-save cache handling

Notes that matter in production

  • config.database.type accepts SQLITE, MYSQL, MARIADB, POSTGRES, and POSTGRESQL.
  • SQLite uses config.database.sqlite.file.
  • SQL backends use host, port, database, username, password, SSL, and pool settings.
  • users.autosave.mode can be ONLINE, OFFLINE, or ALL.
  • users.autosave.after-save.clear-cache and reload control whether saved users are reloaded after cache cleanup.

Configuration areas worth testing

CyberTokens publicly exposes these payment branches in the config schema:

  • config.currency.payments.require-confirmation.*
  • config.currency.payments.anti-abuse.*

They are valid config keys, but if you plan to rely on them for strict policy, validate the exact behavior on your deployed build during staging.

Last updated on

On this page