Balance Tracking in Programs

[dboehm-avalabs]

Vms do not currently expose a standard way to interact with the fee paying currency except through the FeeHandler interface. This makes it difficult for programs to interact with this currency and prevents it from being used within programs.

• Do we want and expect programs to be able to interact with this currency natively?
• Do we want to have a common interface for all vms or should it be up to each vm creator to add the required host functions for programs to interact with?
• Should fee currency be attachable to program calls, so that program calls can also be used to transfer?

[patrick-ogrady]

This was one of the design topics we punted on until we gathered more conviction on the design of Programs. I think we could either:

1. Assume everything that happens on a program-enabled VM occurs in Programs. This would mean defining a native token program that other programs could use (would need to be invoked in every transaction to pay fees)
2. Create non-program interactions that can be interleaved with programs (potentially managing things like native balances for accounts outside of program scope)

The EVM looks closer to [2] and the SVM looks closer to [1].

[patrick-ogrady]

Do we want and expect programs to be able to interact with this currency natively?

I think this makes sense? In most chains, I believe the native currency is the most popular asset used in smart contracts.

Do we want to have a common interface for all vms or should it be up to each vm creator to add the required host functions for programs to interact with?

I think having a standard, small library of native balance host functions for program-enabled VMs seems reasonable.

Should fee currency be attachable to program calls, so that program calls can also be used to transfer?

I also think this would be useful. I would refer to this as "native currency" (you would attach it via a separate type of invocation, not just bumping up the available fees).