Skip to main content
V4 is the current production protocol. It already supports permanent identities, permanent channels, signed cumulative commitments, bundle settlement, and cooperative clearing rounds under Ed25519. The roadmap below describes directions that extend V4’s reach without altering the separation of execution and settlement that makes the protocol work.

​
BLS signature aggregation

Today, cooperative rounds carry one Ed25519 signature per participant. The practical effect is that transaction size grows linearly with the number of co-signers, which caps the largest round that fits in one Solana transaction. BLS aggregation would change density, not semantics:
  • Many participant signatures collapse into a single aggregate signature.
  • The signed round body stays the same.
  • More participants and channels fit in a single cooperative transaction.
What BLS does not change:
  • Payment execution is still separate from settlement.
  • Unilateral commitments still work without cooperation.
  • Bundle settlement still works without cooperation.
  • Cooperation remains optional for any relationship.
BLS is a future signature compression feature for denser cooperative rounds. It is not what makes the protocol work today.

​
Token-2022 and fixed-balance yield assets

V4 currently uses the original SPL Token program. Fixed-balance yield-bearing assets — Maple’s syrupUSDC and similar products — fit the protocol’s accounting model today because stored balances stay constant while redemption value rises over time. Token-2022 interest-bearing mints are conceptually close to this model on-chain. First-class Token-2022 support would require token-interface work across the vault accounts, deposit flow, and withdrawal flow, but does not change the signed-message or settlement surface. See Yield-bearing assets for the current guidance on which token designs fit V4 cleanly.

​
Additional settlement tokens

The token registry is designed to grow. New allowlisted tokens can be registered by the registry authority without changing the signed-message format or settlement surface. Each new token simply appears with its own token_id, vault token account, and decimals. The authority model for token registration is intentionally separate from the configuration authority, so ecosystem token rollout can follow its own operational process.

​
Operator and facilitator tooling

Agon’s base layer is intentionally minimal. Most of the usability improvements for real-world deployments belong outside the program:
  • Bundle-collection and relay services.
  • Clearing-round proposers.
  • Monitoring, alerting, and invoicing.
  • Compliance and KYT integrations built above authorized_settler.
These are natural places for independent teams to build on top of the protocol without changing how settlement works.

​
What stays constant

Across these directions, the core protocol model does not change:
  • Balances live in program-owned accounts.
  • Signed cumulative commitments remain the hot-path primitive.
  • Direct settlement is always available as a fallback.
  • Cooperation is signalled by shared signed messages, not by operator custody.
  • message_domain remains deployment-scoped and derived in-program.
Extensions should extend reach — more participants per round, more assets, better tooling — without relaxing those properties.