TALER-EXCHANGE.CONF(5)

📦 version 1.3.0, in nixos 26.05, nixpkgs unstable

💖 TALER-EXCHANGE.CONF(5) 💖

okay so this is taler-exchange.conf(5) from GNU Taler, and bestie, it's the config file for the Taler exchange — literally main character energy for your setup 🫶✨. Manual name folded in near the top, no boring header copy-paste, we move.

🌸 NAME 🌸

taler-exchange.conf — Taler exchange configuration file 💅

✨ DESCRIPTION ✨

The config file is line-oriented. Blank lines and whitespace at the beginning and end of a line are ignored. Comments start with # or % in the first column (after any beginning-of-line whitespace) and go to the end of the line.

The file is split into sections. Every section begins with [SECTIONNAME] and contains a number of options of the form OPTION=VALUE. There may be whitespace around the = (equal sign). Section names and options are case-insensitive.

The values, however, are case-sensitive. In particular, boolean values are one of YES or NO. Values can include whitespace by surrounding the entire value with " (double quote). Note, however, that there are no escape characters in such strings; all characters between the double quotes (including other double quotes) are taken verbatim. 💀

Values that represent a time duration are represented as a series of one or more NUMBER UNIT pairs, e.g. 60 s, 4 weeks 1 day, 5 years 2 minutes.

Values that represent an amount are in the usual amount syntax: CURRENCY:VALUE.FRACTION, e.g. EUR:1.50. The FRACTION portion may extend up to 8 places.

Values that represent filenames can begin with a /bin/sh-like variable reference. This can be simple, such as $TMPDIR/foo, or complex, such as ${TMPDIR:-${TMP:-/tmp}}/foo. The variables are expanded either using key-values from the [PATHS] section (see below) or from the environment (getenv()). The values from [PATHS] take precedence over those from the environment. If the variable name is found in neither [PATHS] nor the environment, a warning is printed and the value is left unchanged. Variables (including those from the environment) are expanded recursively, so if FOO=$BAR and BAR=buzz then the result is FOO=buzz. Recursion is bounded to at most 128 levels to avoid undefined behavior for mutually recursive expansions like if BAR=$FOO in the example above.

The [PATHS] section is special in that it contains paths that can be referenced using $ in other configuration values that specify filenames. Note that configuration options that are not specifically retrieved by the application as filenames will not see $-expressions expanded. To expand $-expressions when using taler-config, you must pass the -f command-line option.

The system automatically pre-populates the [PATHS] section with a few values at run-time (in addition to the values that are in the actual configuration file and automatically overwriting those values if they are present). These automatically generated values refer to installation properties from GNU autoconf. The values are usually dependent on an INSTALL_PREFIX which is determined by the --prefix option given to configure. The canonical values are:

  • LIBEXECDIR = $INSTALL_PREFIX/taler/libexec/
  • DOCDIR = $INSTALL_PREFIX/share/doc/taler/
  • ICONDIR = $INSTALL_PREFIX/share/icons/
  • LOCALEDIR = $INSTALL_PREFIX/share/locale/
  • PREFIX = $INSTALL_PREFIX/
  • BINDIR = $INSTALL_PREFIX/bin/
  • LIBDIR = $INSTALL_PREFIX/lib/taler/
  • DATADIR = $INSTALL_PREFIX/share/taler/

Note that on some platforms, the given paths may differ depending on how the system was compiled or installed, the above are just the canonical locations of the various resources. These automatically generated values are never written to disk.

Files containing default values for many of the options described below are installed under $TALER_EXCHANGE_PREFIX/share/taler-exchange/config.d/. The configuration file given with -c to Taler binaries overrides these defaults.

A configuration file may include another, by using the @INLINE@ directive, for example, in main.conf, you could write @INLINE@ sub.conf to include the entirety of sub.conf at that point in main.conf.

🚨 bestie, be extra careful when using taler-exchange-config -V VALUE to change configuration values: it will destroy all uses of @INLINE@ and furthermore remove all comments from the configuration file!

🌈 GLOBAL OPTIONS 🌈

The [PATHS] section is special in that it contains paths that can be referenced using $ in other configuration values that specify filenames. For Taler exchange, it commonly contains the following paths:

  • TALER_HOME — Home directory of the user, usually ${HOME}. Can be overwritten by testcases by setting ${TALER_TEST_HOME}. 🏠
  • TALER_DATA_HOME — Where should Taler store its long-term data. Usually ${TALER_HOME}/.local/share/taler-exchange/. 💾
  • TALER_CONFIG_HOME — Where is the Taler configuration kept. Usually ${TALER_HOME}/.config/taler-exchange/. 🎀
  • TALER_CACHE_HOME — Where should Taler store cached data. Usually ${TALER_HOME}/.cache/taler-exchange/. 🧚
  • TALER_RUNTIME_DIR — Where should Taler store system runtime data (like UNIX domain sockets). Usually ${TMP}/taler-exchange-runtime. 🔌

💸 CURRENCY SPECIFICATIONS 💸

Sections with a name of the form [currency-$NAME] (where "$NAME" could be any unique string) are used to specify details about how currencies should be handled (and in particularly rendered) by the user interface. A detailed motivation for this section can be found in DD51. Different components can have different rules for the same currency. For example, a bank or merchant may decide to render Euros or Dollars with always exactly two fractional decimals, while an Exchange for the same currency may support additional decimals. The required options in each currency specification section are:

  • ENABLED — Set to YES or NO. If set to NO, the currency specification section is ignored. Can be used to disable currencies or select alternative sections for the same CODE with different choices. ✅
  • CODE — Code name for the currency. Can be at most 11 characters, only the letters A-Z are allowed. Primary way to identify the currency in the protocol. 🔤
  • NAME — Long human-readable name for the currency. No restrictions, but should match the official name in English. 🏷️
  • FRACTIONAL_INPUT_DIGITS — Number of fractional digits that users are allowed to enter manually in the user interface. ⌨️
  • FRACTIONAL_NORMAL_DIGITS — Number of fractional digits that will be rendered normally (in terms of size and placement). Digits shown beyond this number will typically be rendered smaller and raised (if possible). 🔍
  • FRACTIONAL_TRAILING_ZERO_DIGITS — Number of fractional digits to pad rendered amounts with even if these digits are all zero. For example, use 2 to render 1 USD as $1.00. 🫶
  • ALT_UNIT_NAMES — JSON map determining how to encode very large or very tiny amounts in this currency. Maps a base10 logarithm to the respective currency symbol. Must include at least an entry for 0 (currency unit). For example, use {"0":"€"} for Euros or "{"0":"$"}` for Dollars. You could additionally use {"0":"€","3":"k€"} to render 3000 EUR as 3k€. For BTC a typical map would be {"0":"BTC","-3":"mBTC"}, informing the UI to render small amounts in milli-Bitcoin (mBTC). 🪙

🔥 EXCHANGE OPTIONS 🔥

The following options are from the [exchange] section and used by most exchange tools.

  • CURRENCY — Name of the currency, e.g. EUR for Euro. 💶
  • CURRENCY_ROUND_UNIT — Smallest amount in this currency that can be transferred using the underlying RTGS. For example: "EUR:0.01" or "JPY:1". 🪙
  • DB — Plugin to use for the database, e.g. postgres. 🗄️
  • ATTRIBUTE_ENCRYPTION_KEY — Attribute encryption key for storing attributes encrypted in the database. Should be a high-entropy nonce. 🔐
  • SERVE — Should the HTTP server listen on a UNIX domain socket (set option to "unix"), or on a TCP socket (set option to "tcp"), or be activated via systemd (set option to "systemd"). 🌐
  • UNIXPATH — Path to listen on if SERVE is set to "unix". 🛤️
  • UNIXPATH_MODE — Access permission mask to use for the UNIXPATH. 🔑
  • PORT — Port on which the HTTP server listens, e.g. 8080. 🔢
  • BIND_TO — Hostname to which the exchange HTTP server should be bound to, e.g. "localhost". 📍
  • MASTER_PUBLIC_KEY — Crockford Base32-encoded master public key, public version of the exchange's long-time offline signing key. This configuration option is also used by the auditor to determine the public key of the exchange which it is auditing. 👑
  • TINY_AMOUNT — Small amount that can be transferred to the exchange for the KYC authentication wire transfers. Should be given as a hint for merchants what amount they need to transfer to begin the KYC transfer. Note that the amount is not enforced by the exchange and that this option is optional. However, if it is not given, merchants will have to guess what amount to transfer, so it really should be configured. 💸
  • SHOPPING_URL — Web URL where users can discover shops that accept digital cash offered by this exchange. Optional, but highly recommended. 🛍️
  • OPEN_BANKING_GATEWAY_URL — URL where wallets can find an open banking gateway to initiate wire transfers when withdrawing digital cash from this exchange. Optional (as obviously not every exchange will have an open banking gateway attached). 🏦
  • AML_SPA_DIALECT — Determines the variant of the AML SPA that should be shown. This will determine the set of forms shown to AML staff, statistics to be displayed on the main page, and influence the default set of properties/events the AML forms show when AML staff makes decisions. Possible values for now include "gls", "tops" and "magnet". Optional. The AML SPA will only show certain default forms and generic decisions if this option is not set. 🕵️
  • GLOBAL_PDF_FORM_DATA — Set to a JSON object that should be provided as additional input to the PDF form generation logic when generating AML records in PDF format. Useful to specify global attributes for the Typst forms. Optional, global PDF form data injection will simply be off if this option is not specified. 📄
  • BANK_COMPLIANCE_LANGUAGE — tells the wallets which legal language (and possibly other UI/UX stuff) they should use when they're showing the user interface for this bank. It's literally the bank saying "hey, here's the compliance language we want you to use" to the wallet. Wallets SHOULD follow the bank's guidance, but ngl some wallets MAY not understand every compliance language out there. It's optional — if you don't set it, wallets just use their default UI/UX. 💅
  • STEFAN_ABS — the absolute amount you add as an offset in the STEFAN fee approximation curve (see DD47). Defaults to CURRENCY:0 if you don't specify it.
  • STEFAN_LOG — the amount you multiply by the base-2 logarithm of (total amount ÷ amount of the smallest denomination), in the STEFAN fee approximation curve (see DD47). Defaults to CURRENCY:0 if you don't specify it.
  • STEFAN_LIN — a linear floating point factor that gets multiplied by the total amount, used in the STEFAN fee approximation curve (see DD47). Defaults to 0.0 if you don't specify it.
  • BASE_URL — the base URL where your exchange can be reached. It gets added to wire transfers so merchants can track stuff. Also used by the KYC logic when it's doing its OAuth 2.0 thing.
  • TOPLEVEL_REDIRECT_URL — where do you send visitors who hit the top-level / endpoint of the exchange? Point them at info about the exchange operator, bestie. Optional setting, defaults to /terms.
  • AGGREGATOR_IDLE_SLEEP_INTERVAL — how long should taler-exchange-aggregator snooze when it's idle before it goes looking for more work? Default is 60 seconds. 😴
  • CLOSER_IDLE_SLEEP_INTERVAL — how long should taler-exchange-closer snooze when it's idle before looking for more work? Default is 60 seconds.
  • TRANSFER_IDLE_SLEEP_INTERVAL — how long should taler-exchange-transfer snooze when it's idle before looking for more work? Default is 60 seconds.
  • WIREWATCH_IDLE_SLEEP_INTERVAL — how long should taler-exchange-wirewatch snooze when it's idle before looking for more work? Default is 60 seconds.
  • AGGREGATOR_SHARD_SIZE — which slice of the range [0,..2147483648] should be handled by one of the aggregator's shards. Only useful if you've got a Taler exchange with ultra high-performance needs, iykyk.
🚨 Real talk: when you change this value, you must stop all aggregators and run taler-exchange-dbinit -s before you resume. No skipping that step. Default is 2147483648 (which means no sharding).
  • SIGNKEY_LEGAL_DURATION — how long are signatures made with signing keys legally valid for?
  • MAX_KEYS_CACHING — how long should clients cache /keys responses at most?
  • MAX_REQUESTS — how many requests should the HTTP server process at most before committing suicide? 💀
  • TERMS_DIR — the directory where the terms of service of the exchange operator can be fund (yes, "fund" — you found it, congrats 🎀). The directory must contain sub-directories for every supported language, using the two-character language code in lower case, e.g. en/ or fr/. Each subdirectory then has to contain files with the terms of service in various formats. The basename of the file for the current policy must be specified under TERMS_ETAG. The extension defines the mime type. Supported extensions include html, htm, txt, pdf, jpg, jpeg, png and gif. For example, using a TERMS_ETAG of 0, the structure could look like this:
    • $TERMS_DIR/en/0.pdf
    • $TERMS_DIR/en/0.html
    • $TERMS_DIR/en/0.txt
    • $TERMS_DIR/fr/0.pdf
    • $TERMS_DIR/fr/0.html
    • $TERMS_DIR/de/0.txt
  • TERMS_ETAG — the basename of the file(s) in TERMS_DIR that hold the current terms of service. This value is also used for the Etag in the HTTP request to control caching. Whenever the terms of service change, the TERMS_ETAG MUST also change, and old values MUST NOT be repeated. Like, for example, the date or version number of the terms of service SHOULD be used for the Etag. If there are minor fixes (spelling, etc.) to the terms of service, the TERMS_ETAG probably SHOULD NOT be changed. However, whenever users must approve the new terms, the TERMS_ETAG MUST change. Periodt. 💅
  • PRIVACY_DIR — works exactly the same as TERMS_DIR, just for the privacy policy. 🦋
  • PRIVACY_ETAG — works exactly the same as TERMS_ETAG, just for the privacy policy.
  • ENABLE_KYC — must be set to YES to enable AML/KYC rule enforcement. Note that the administrative endpoints will always work, even if this flag is set to NO.
  • DISABLE_DIRECT_DEPOSIT — set to YES to signal to wallets that deposits by non-merchants aren't supported. Defaults to NO.

💖 EXCHANGE KYC PROVIDER OPTIONS 💖

These following options have to go in the [kyc-provider-$PROVIDER_NAME] sections.

  • LOGIC — the API type of the KYC provider.

Additional logic-specific options may be given in the section. ✨

🌈 EXCHANGE KYC OAUTH2 OPTIONS 🌈

The following options must go in the [kyc-provider-XXX] sections with LOGIC = oauth2.

  • KYC_OAUTH2_VALIDITY — duration (e.g. 12 months) of how long the performed KYC check is valid for. Can be forever. ⭐
  • KYC_OAUTH2_AUTHORIZE_URL — the URL of the OAuth2 endpoint used for KYC checks. The authorize URL is where the exchange will redirect the client to kick off the authorization process. Example: http://localhost:8888/oauth/v2/authorize. To use the plugin together with the Challenger service's /setup step, append #setup, so like https://challenger.example.com/authorize#setup. Heads up: here #setup is not a fragment — it's merely a hint to the logic to figure out the full authorization URL via the /setup/$CLIENT_ID handler.
  • KYC_OAUTH2_TOKEN_URL — the URL of the OAuth2 endpoint used for KYC checks. This is where the server will ultimately send the authorization token from the client and obtain its access token (which currently must be a bearer token). Example: http://localhost:8888/oauth/v2/token (or just /token).
  • KYC_OAUTH2_INFO_URL — the URL of the OAuth2-protected resource endpoint, where the OAuth 2.0 token can be used to download info about the user who's gone through the KYC process. The exchange will use the access token obtained from the KYC_AUTH2_AUTH_URL to show that it's authorized to obtain the details. Example: http://localhost:8888/api/user/me or http://localhost:8888/oauth/v2/info.
  • KYC_OAUTH2_CLIENT_ID — the client ID of the exchange when it talks to the KYC OAuth2 endpoint.
  • KYC_OAUTH2_CLIENT_SECRET — the client secret of the exchange to use when talking to the KYC Oauth2 endpoint.
  • KYC_OAUTH2_SCOPE — the scope argument to pass in the Oauth2 /authorize request. Optional — if you don't give it, no scope will be provided.
  • KYC_OAUTH2_POST_URL — the URL the exchange will redirect the client's browser to after a successful authorization/login for the KYC process. Example: http://example.com/thank-you.
  • KYC_OAUTH2_CONVERTER_HELPER — the helper that converts JSON with KYC data returned by the OAuth2.0 info endpoint into GNU Taler internal format. Specific to the OAuth 2.0 provider.
  • KYC_OAUTH2_DEBUG_MODE — set to YES to let error responses include potentially sensitive private info (like full responses from the OAuth 2.0 server) that might help you debug problems. 👍
🙈 Should be set to NO in production. No cap.

🧚 EXCHANGE KYC KYCAID OPTIONS 🧚

The following options must go in the [kyc-provider-XXX] sections with LOGIC = kycaid.

  • KYC_KYCAID_VALIDITY — duration (e.g. 12 months) of how long the performed KYC check is valid for. Can be forever.
  • KYC_KYCAID_AUTH_TOKEN — the authentication token to access the KYC service.
  • KYC_KYCAID_CONVERTER_HELPER — the helper that converts JSON with KYC data returned by KYCAID into GNU Taler internal format. Should probably always be set to taler-exchange-kyc-kycaid-converter.sh.
  • KYC_KYCAID_FORM_ID — the ID that specifies which form to use for the KYC process.
  • KYC_KYCAID_POST_URL — the URL the exchange will redirect the client's browser to after a successful authorization/login for the KYC process.

🎀 EXCHANGE KYC PERSONA OPTIONS 🎀

The following options must go in the [kyc-provider-XXX] sections with LOGIC = persona.

  • KYC_PERSONA_VALIDITY — duration (e.g. 12 months) of how long the performed KYC check is valid for. Can be forever.
  • KYC_PERSONA_AUTH_TOKEN — the authentication token to access the KYC service.
  • KYC_PERSONA_SALT — the salt value to use for request idempotency. Optional — generated at random per process if you don't give it.
  • KYC_PERSONA_SUBDOMAIN — the subdomain to use under Persona.
  • KYC_PERSONA_CONVERTER_HELPER — the helper that converts JSON with KYC data returned by Persona into GNU Taler internal format. Should probably always be set to taler-exchange-kyc-persona-converter.sh.
  • KYC_PERSONA_POST_URL — the URL the exchange will redirect the client's browser to after a successful authorization/login for the KYC process.
  • KYC_PERSONA_TEMPLATE_ID — the ID of the Persona template to use.

🦋 EXCHANGE KYC PERSONA GLOBAL OPTIONS 🦋

This following option must be in the [kyclogic-persona] section.

  • WEBHOOK_AUTH_TOKEN — the authentication token Persona must supply to our webhook. Optional setting. 💜

👑 EXCHANGE KYC CHECK OPTIONS 👑

The following options must be in [kyc-check-$CHECK_NAME] sections.

  • TYPE — which type of check is this? It also determines the SPA form shown to the user for this check.
    • INFO: wait for staff, or contact staff out-of-band (only information shown, no SPA action)
    • FORM: the SPA should show an inline (HTML) form
    • LINK: the SPA may start an external KYC process or upload
  • PROVIDER_ID — the provider id, present only if the type is LINK. Refers to a kyc-provider-$PROVIDER_ID section.
  • FORM_NAME — the name of the SPA form. If the type is FORM, then "INFO" and "LINK" are reserved and must not be used, bestie. The exchange server and the SPA must agree on a list of supported forms and the resulting attributes. The SPA should include a JSON resource file forms.json mapping form names to arrays of attribute names each form provides. The list of possible FORM names is fixed in the SPA for a particular exchange release. 💅
  • DESCRIPTION — descriptions to use in the SPA to display the check. ✨
  • DESCRIPTION_I18N — JSON with internationalized descriptions to use in the SPA to display the check. 🎀
  • REQUIRES — a ';'-separated list of fields that the CONTEXT must provide as inputs to this check. For example, for a FORM of type CHOICE, this might state choices: string[];. The type after the ":" is for now purely for documentation and is not checked. However, it may be shown to AML staff when they configure measures. 🫶
  • OUTPUTS = "business_name street city country registration" — description of the outputs provided by the check. Basically, the check's output is expected to provide the following fields as attribute inputs into a subsequent AML program. INFO never has any outputs. 🌸
  • FALLBACK — name of an original measure to take if the check fails (for any reason, e.g. provider or form fail to satisfy constraints or provider signals user error). Usually should point to a measure that requests AML staff to investigate. The fallback measure context always includes the reasons for the failure. 🦋

💖 EXCHANGE KYC RULES 💖

The following options must be in "[kyc-rule-$RULE_NAME]" sections.

  • OPERATION_TYPE = WITHDRAW — operation that triggers this rule. Must be one of AGGREGATE, BALANCE, CLOSE, DEPOSIT, MERGE, REFUND, TRANSACTION or WITHDRAW. See the Exchange KYC/AML Operator Manual for the operations these refer to. 🔥
  • NEXT_MEASURES — space-separated list of next measures to be performed. The SPA should display all of these measures to the user. (They have a choice of either which ones, or in which order they are to be performed.) A special measure name "verboten" is used if the specified threshold may never be crossed (under this set of rules). This option is equivalent to the "new_measure" string in an AmlDecisionRequest (with IS_AND_COMBINATOR replacing the "+"-prefix). 👑
  • IS_AND_COMBINATOR — "YES" if all NEXT_MEASURES will eventually need to be satisfied, "NO" the user has a choice between them. Not actually enforced by the exchange, but primarily used to inform the user whether this is an "and" or "or". YES for "and". 🌈
  • EXPOSED — YES if the rule (specifically, operation type, threshold, timeframe) and the general nature of the next measure (verboten or approval required) should be exposed to the client. Defaults to NO if not set. 👀
  • THRESHOLD — threshold amount above which the rule is triggered. The total must be exceeded in the given timeframe. 💰
  • TIMEFRAME — timeframe over which the amount to be compared to the THRESHOLD is calculated (for example, "30 days"). Ignored for BALANCE. Can be 'forever'. ⏳
  • ENABLED = NO — set to YES to enable the rule (default is NO). ✅

🦋 EXCHANGE AML PROGRAMS 🦋

The following options must be in "[aml-program-$PROG_NAME]" sections.

  • COMMAND — name of the program to run. Must match a binary on the local machine where the exchange is running. 🖥️
  • DESCRIPTION — human-readable description of what this AML helper program will do. Used to show to the AML staff. 📝
  • ENABLED — true if this AML program is enabled (and thus can be used in measures and exposed to AML staff). Optional, default is NO. 🌟
  • FALLBACK — name of an original measure to take if COMMAND fails. Usually points to a measure that asks AML staff to contact the systems administrator. The fallback measure context always includes the reasons for the failure. 😭

🌸 EXCHANGE KYC MEASURES 🌸

The following options must be in "[kyc-measure-$MEASURE_NAME]" sections. These sections define the original measures.

  • CHECK_NAME — name of a possible check for this measure. Optional. If not given or set to SKIP, PROGRAM should be run immediately (on an empty set of attributes). 🎀
  • CONTEXT = {"choices":["individual","business"]} — context for the check. The context can be just an empty JSON object if there is none. 🧚
  • PROGRAM — program to run on the context and check data to determine the outcome and next measure. Refers to a [aml-program-$PROG_NAME] section name. ⚙️
  • VOLUNTARY — optional. Set to YES to allow this measure to be done voluntarily by a client. Used to offer the SPA to display measures even if they are not required. Default is NO. 💜

🎀 EXCHANGE EXTENSIONS OPTIONS 🎀

The functionality of the exchange can be extended by extensions. Those are shared libraries which implement the extension-API of the exchange and are located under $LIBDIR, starting with prefix libtaler_extension_. Each extension can be enabled by adding a dedicated section "[exchange-extension-<extensionname>]" and the following option:

  • ENABLED — if set to YES the extension <extensionsname> is enabled. Extension-specific options might be set in the same section. 🧩

🌈 EXCHANGE EXTENSION FOR AGE RESTRICTION 🌈

The extension for age restriction support can be enabled by adding a section "[exchange-extension-age_restriction]" with the following options:

  • ENABLE — must be set to YES in order to activate the extension. 🔓
  • AGE_GROUPS — a colon-separated string of increasing non-negative integers, defining the buckets of age groups supported by the exchange. Each integer marks the beginning of the next age group. The zero'th age group implicitly starts with 0. For example, the string "10:18" would define three age groups:
    1. Group 0: ages 0 through 9 (including)
    2. Group 1: ages 10 through 17 (including)
    3. Group 2: ages 18 and above

If not provided, the default value is "8:10:12:14:16:18:21". 🎂

Note: Age restriction is bound to specific denominations and must be enabled for each selected denomination in the corresponding section by adding the option AGE_RESTRICTED = YES, see EXCHANGE COIN OPTIONS. However, the age groups are defined globally for all denominations. 🫶

🔐 EXCHANGE OFFLINE SIGNING OPTIONS 🔐

The following options must be in the section "[exchange-offline]".

  • MASTER_PRIV_FILE — location of the master private key on disk. Only used by tools that can be run offline (as the master key is for offline signing). Mandatory — fr fr, no skipping. 🗝️
  • SECM_TOFU_FILE — where to store the public keys of both crypto helper modules. Used to persist the keys after the first invocation of the tool, so that if they ever change in the future, this is detected and the tool can abort. Mandatory. 📌
  • SECM_DENOM_PUBKEY — public key of the (RSA) crypto helper module. Optional. If not given, we will rely on TOFU. Note that once TOFU has been established, this option will also be ignored. 🔑
  • SECM_ESIGN_PUBKEY — public key of the (EdDSA) crypto helper module. Optional. If not given, we will rely on TOFU. Note that once TOFU has been established, this option will also be ignored. 🪄

💅 EXCHANGE RSA CRYPTO HELPER OPTIONS 💅

The following options must be in the section "[taler-exchange-secmod-rsa]".

  • LOOKAHEAD_SIGN — how long do we generate denomination and signing keys ahead of time? ⏰
  • OVERLAP_DURATION — how much should validity periods for coins overlap? Should be long enough to avoid problems with wallets picking one key and then due to network latency another key being valid. The DURATION_WITHDRAW period must be longer than this value. 🔄
  • SM_PRIV_KEY — where should the security module store its long-term private key? 🔒
  • KEY_DIR — where should the security module store the private keys it manages? 📂
  • UNIXPATH — on which path should the security module listen for signing requests? 🛎️

Note that the taler-exchange-secmod-rsa also evaluates the [coin_*] configuration sections described below. 👑

🧊 EXCHANGE CS CRYPTO HELPER OPTIONS 🧊

The following options must be in the section "[taler-exchange-secmod-cs]".

  • LOOKAHEAD_SIGN — how long do we generate denomination and signing keys ahead of time? ⏰
  • OVERLAP_DURATION — how much should validity periods for coins overlap? Should be long enough to avoid problems with wallets picking one key and then due to network latency another key being valid. The DURATION_WITHDRAW period must be longer than this value. 🔄
  • SM_PRIV_KEY — where should the security module store its long-term private key? 🔒
  • KEY_DIR — where should the security module store the private keys it manages? 📂
  • UNIXPATH — on which path should the security module listen for signing requests? 🛎️

Note that the taler-exchange-secmod-cs also evaluates the [coin_*] configuration sections described below. 👑

🦋 EXCHANGE EDDSA CRYPTO HELPER OPTIONS 🦋

The following options must be in the section "[taler-exchange-secmod-eddsa]".

  • LOOKAHEAD_SIGN — how long do we generate denomination and signing keys ahead of time? ⏰
  • OVERLAP_DURATION — how much should validity periods for coins overlap? Should be long enough to avoid problems with wallets picking one key and then due to network latency another key being valid. The DURATION_WITHDRAW period must be longer than this value. 🔄
  • DURATION — for how long should EdDSA keys be valid for signing? ✍️
  • SM_PRIV_KEY — where should the security module store its long-term private key? 🔒
  • KEY_DIR — where should the security module store the private keys it manages? 📂
  • UNIXPATH — on which path should the security module listen for signing requests? 🛎️

🗄️ EXCHANGE DATABASE OPTIONS 🗄️

The following options must be in the section "[exchangedb]".

  • IDLE_RESERVE_EXPIRATION_TIME — after which time period should reserves be closed if they are idle? 😴
  • LEGAL_RESERVE_EXPIRATION_TIME — after what time do we forget about (drained) reserves during garbage collection? 🧹
  • AGGREGATOR_SHIFT — the lil pause between a deposit becoming eligible for aggregation and the aggregator actually going "k, bet" and triggering ✨
  • DEFAULT_PURSE_LIMIT — how many purses a reserve can have active at the same time if it paid to have them opened for a year 💅
  • MAX_AML_PROGRAM_RUNTIME — the max time an AML program is allowed to run before we pull the plug ⏱️ (this one's optional for taler-auditor)

🗄️ EXCHANGE POSTGRES BACKEND DATABASE OPTIONS

okay so these ones go in the section [exchangedb-postgres] — but ONLY if you picked the postgres plugin for the database, iykyk 🫶

  • CONFIG — how to actually reach the database, e.g. postgres:///taler-exchange to use the taler-exchange database. Testcases use talercheck 🧪

🏦 EXCHANGE ACCOUNT OPTIONS

an exchange (or a merchant, bestie, they can both do it) can have multiple bank accounts, and these options live in sections named [exchange-account-SOMETHING]. the SOMETHING part is arbitrary — just pick something that uniquely identifies the bank account for whoever's running this thing 💖

these options are read by taler-exchange-aggregator, taler-exchange-closer, taler-exchange-transfer and taler-exchange-wirewatch.

  • PAYTO_URI — the full payto://-URL of the account. general format is payto://$METHOD/$DETAILS?receiver-name=NAME. some examples, slay:
payto://x-taler-bank/localhost:8899/Exchange?receiver-name=Exchange

or

payto://iban/GENODEF1SLR/DE67830654080004822650/?receiver-name=Exchange

or

payto://iban/DE67830654080004822650/?receiver-name=Exchange

(providing the BIC is optional, no pressure 🦋)

  • ENABLE_DEBIT — must be set to YES for the accounts that taler-exchange-aggregator and taler-exchange-closer should debit 💸
  • ENABLE_CREDIT — must be set to YES for the accounts that taler-exchange-wirewatch should check for credits. whether the merchant implementation also checks this flag is, uh, still uncertain 🙈

so for every enabled account there MUST be another matching section called [exchange-accountcredentials-SOMETHING]. and this one SHOULD live in a secret/ configuration file that only taler-exchange-wirewatch and taler-exchange-transfer can read 👀🔒 it holds the credentials for getting into the bank account:

  • WIRE_GATEWAY_URL — URL of the wire gateway. typically shaped like https://$HOSTNAME[:$PORT]/accounts/$USERNAME/taler-wire-gateway/ where $HOSTNAME is the hostname of the system running the bank (think the Taler Python bank or the Nexus) and $USERNAME is the username of the exchange's bank account (usually matching the USERNAME option used for authentication). example:
https://bank.demo.taler.net/accounts/Exchange/taler-wire-gateway/
  • WIRE_GATEWAY_AUTH_METHOD — determines how the exchange (auditor/wirewatch/aggregator) authenticates with the wire gateway. choices are basic, bearer and none 🎀
  • USERNAME — user name for basic authentication with the wire gateway
  • PASSWORD — password for basic authentication with the wire gateway
  • TOKEN — token for bearer authentication with the wire gateway

🪙 EXCHANGE COIN OPTIONS

these go in sections starting with [coin_] and are mostly used by taler-exchange-httpd to figure out the meta data for the denomination keys. a few of them are used by taler-exchange-secmod-rsa to decide which RSA keys to create (and how long they should be) 🔑

⚠️ heads up bestie: the section names must match, so this part of the configuration MUST be shared between the RSA helper and the exchange. and configuration values MUST NOT be changed in a running setup. if the parameters for a denomination type need to change, introduce a fresh section name and delete the existing one. no take-backs, no edits-in-place 💀
  • VALUE — value of the coin, e.g. EUR:1.50 for 1 Euro and 50 Cents (per coin) 💰
  • DURATION_WITHDRAW — how long should the same key be used for clients to withdraw coins of this value?
  • DURATION_SPEND — how long do clients have to spend these coins?
  • DURATION_LEGAL — how long does the exchange have to keep records for this denomination?
  • FEE_WITHDRAW — what fee is charged for withdrawal?
  • FEE_DEPOSIT — what fee is charged for depositing?
  • FEE_REFRESH — what fee is charged for refreshing?
  • FEE_REFUND — what fee is charged for refunds? so when a coin is refunded, the deposit fee gets returned — instead, the refund fee is charged to the customer 🫶
  • CIPHER — which cryptosystem should be used? must be set to either "CS" or "RSA". the respective crypto-helper will then generate the keys for this denomination 🔐
  • RSA_KEYSIZE — what's the RSA keysize modulos (in bits)? only used if CIPHER=RSA
  • AGE_RESTRICTED — setting this to YES marks the denomination as age restricted (default is NO). for this option to be accepted, the extension for age restriction MUST be enabled 🧚

🚨 EXCHANGE SANCTIONSCHECK OPTIONS

this section configures the taler-exchange-sanctionlist tool to enforce sanctions. the tool scores KYC records in two dimensions: the quality of the match (rating) and the number of attributes that were found in both sets (confidence) 🔍

the following options must be in the section [exchange-sanctionscheck].

  • RATER_COMMAND — program (plus command-line arguments) for the helper program to execute when comparing sanction list records. usually set to something like robocop $SANCTIONLIST.json, but honestly it can be any program that reads KYC attributes in JSON line-by-line and outputs a rating (0-1), confidence (0-1) and a free-form sanction list identifier for each JSON input it receives 🎯
  • MIN_ROW_FILENAME — name of the file where taler-exchange-sanctionscheck will store the last row it processed during sanction list evaluation. it's not in the database because we frequently need to reset it whenever we get a new list, so transactionality isn't needed or even desirable. there should be no need to change the default 🙅‍♀️
  • FREEZE_RATING_LIMIT — match quality rating (on a scale of [0,1]) that must be exceeded for the exchange to automatically freeze an account. the account has to satisfy both the rating limit and the confidence limit to get frozen 🧊
  • FREEZE_CONFIDENCE_LIMIT — match confidence rating (on a scale of [0,1]) that must be exceeded for the exchange to automatically freeze an account. a rating of 0 means no attributes were available, while a rating of 1 means we could compare the accounts across all dimensions 💅
  • INVESTIGATION_LIMIT — limit (on a scale of [0,1]) that must be exceeded for an account to be flagged for manual investigation. only applies if the account isn't automatically frozen. the limit given is compared against the quality rating divided by the confidence score. if set at 0.95, a modest 0.8 match with low 0.5 confidence will trigger (1.6 > 0.95), but a good 0.9 match with a super-high 1.0 confidence would not (0.9 < 0.95). on the other hand, a bad 0.2 match with super-low 0.1 confidence would again trigger (2.0 > 0.95) 😭 math is wild fr fr

🌈 SEE ALSO

taler-exchange-dbinit(1), taler-exchange-httpd(1), taler-exchange-offline(1), taler-exchange-sanctionscheck(1)

💀 BUGS

found a bug? report it at https://bugs.taler.net/ or send electronic mail to <taler@gnu.org> 🫶

👑 AUTHOR

GNU Taler contributors

2014-2025 Taler Systems SA (GPLv3+ or GFDL 1.3+)

and that's the whole page, bestie, you ate that 🍓✨ this was TALER-EXCHANGE.CONF(5), version 1.0, dated Dec 22, 2025 — go forth and configure responsibly 💜🦋

📦 where this page comes from