The process that generates tokens is only signing tokens; let’s call that process “the token provider”. The participant will check the validity of a token based on the public key of the token provider. If that succeeds, the participant will accept the command and it (the participant) will sign the transaction. (A typical transaction will be signed by more than one participant, as it will involve more than one party and those parties may be represented on different participants.)
The token provider is not part of the Daml system and only interacts with it by:
- Signing JWTs with a private key.
- Providing a public key for JWT signature verification.
This means that, on the ledger itself, the “trustable unit” is the participant, not the party or user. The thing that signs transactions is the participant node. From that perspective, if you want to minimize the number of things you need to trust, you should run your own participant node, and may be tempted to imagine a setup where every single party has their own participant and each participant only has one party. (There are cases where that’s feasible, but in most cases that’s going to be too much work for individual users.)