Skip to content

docs(activation-service): correct the ACTIVATION_AMOUNT guidance - #1110

Open
sameh-farouk wants to merge 1 commit into
developmentfrom
fix/activation-amount-docs
Open

docs(activation-service): correct the ACTIVATION_AMOUNT guidance#1110
sameh-farouk wants to merge 1 commit into
developmentfrom
fix/activation-amount-docs

Conversation

@sameh-farouk

Copy link
Copy Markdown
Member

Follow-up to #1105/#1109. Two documentation errors of mine, found while checking whether ACTIVATION_AMOUNT is chart-specific.

The .env example contradicted the chart

readme.md      ACTIVATION_AMOUNT=1        -> 10,000,000 base units = 1 TFT
values.yaml    activation_amount: 0.1     ->  1,000,000 base units = 0.1 TFT

Both are meant to be the recommended starting value. Anyone deploying from the readme with Docker or locally would have funded ten times the Kubernetes default, and ten times what the service actually pays out today. Example changed to 0.1.

It documented a default that cannot happen

The readme said the value "defaults to 0.1 when unset", then a few lines later that it "is required, so set it explicitly even though it has a default". Both, in the same file.

bin/www lists ACTIVATION_AMOUNT in REQUIRED_ENV_VARIABLES and refuses to start without it, so the fallback in lib/config.js is unreachable through the normal entrypoint — it only applies to callers that bypass it, such as the tests. Confirmed:

$ MNEMONIC=... URL=... node ./bin/www          # ACTIVATION_AMOUNT unset
"msg":"Missing env variables"
"msg":"failed to run startup actions, closing service"

Now stated once, accurately.

The unit does not depend on the deployment method

Worth making explicit, since it was the question that prompted this. ACTIVATION_AMOUNT is read straight from process.env in lib/config.js, so it is whole TFT for Helm, docker run -e, and a local .env alike — the unit is a property of the application, not of how it is deployed.

The image sets no environment variables of its own (no ENV or ARG in the Dockerfile), so every deployment must supply all three. The deployment section now shows a docker run invocation instead of telling the reader to "configure the environment variables listed above", and points at the chart for the Kubernetes equivalent.

Verification

ACTIVATION_AMOUNT=0.1  -> 1000000 base units  = 0.1 TFT
ACTIVATION_AMOUNT=1    -> 10000000 base units = 1.0 TFT
unset                  -> refuses to start

Lint and unit tests pass. Documentation only — no code changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_011YKJm3zuWdSepriT9KL9zy

Two things I got wrong when the variable was first documented.

The .env example still said ACTIVATION_AMOUNT=1 while the Helm chart defaults to
0.1. Both are meant to be the recommended starting value, so anyone deploying
from the readme with Docker or locally would have funded 1 TFT per activation —
ten times the Kubernetes default and ten times what the service actually pays out
today. The example is now 0.1.

It also claimed the value "defaults to 0.1 when unset", and then a few lines later
that it is required and must be set anyway. Both statements were in the same file.
bin/www lists ACTIVATION_AMOUNT in REQUIRED_ENV_VARIABLES and refuses to start
without it, so the fallback in lib/config.js is unreachable through the normal
entrypoint and only applies to callers that bypass it, such as the tests. Said
plainly now instead of two ways at once.

Also makes it explicit that the unit does not depend on how the service is
deployed. The value is read from the environment, so Helm, `docker run -e` and a
local .env all take whole TFT. The image itself sets no environment variables, so
every deployment supplies all three; the deployment section now shows a docker run
invocation rather than telling the reader to configure the variables listed above.

Verified: 0.1 resolves to 1000000 base units, 1 to 10000000, and an unset value
stops startup with "Missing env variables".
@sameh-farouk
sameh-farouk requested a review from LeeSmet as a code owner July 27, 2026 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant