participant_id. The mapping does not recycle, so off-chain systems can treat wallet → participant_id as stable for the life of the deployment.
What a participant stores
The participant account is Agon’s long-lived identity record. Each account holds:| Field | Meaning |
|---|---|
owner | The wallet that controls the participant |
participant_id | The compact numeric ID used inside signed messages and PDA seeds |
token_balances | One balance record per allowlisted token |
inbound_channel_policy | Whether other parties may open channels to this participant |
bump | PDA bump for canonical address checks |
token_balances vector stores available balance, pending-withdrawal state, and withdrawal destination for each token the participant has used. Up to 16 tokens can coexist per participant. See Account layouts for the exact byte layout.
Why participants are permanent
V4 does not let participants close and recreate their accounts. This preserves three simple invariants:participant_idstays stable for the life of the deployment.- Off-chain services can index users without worrying about ID reuse.
- Replay protection is simpler because there is no reopened identity for an old signed message to target.
Inbound channel policy
Each participant chooses how other parties may open channels to it:| Policy | Meaning |
|---|---|
Permissionless | Anyone may create a channel to this participant |
ConsentRequired | The payee must sign channel creation |
Disabled | New inbound channels are rejected |
ConsentRequired. The policy can be changed later with update_inbound_channel_policy.
Registration
Registration is deliberately small:participant_id:
What participants do not store
Participants are identity and balance containers. They do not store:- whom they are paying
- the latest signed commitments
- operator business logic
ChannelState, in off-chain systems, or both.

