You can also make sats optional to indicate a leftover output, but not entirely sure.

Personally I think just one Output type is fine, not sure if we need another interface.

Also, for gasless payments, sats should be optional to indicate to the UTXO selector that we don’t need to add sats for the payment.

BTW for GENESIS, we might need to have a placeholder for outputs that receive a GENESIS output (atoms or mint baton).

I see two options:

• set tokenId to "GENESIS"
• add a Boolean like isGenesis

And then the wallet tx builder knows how to build the genesis pushdata.

I think this is adding too many terms. There’s config, instructions, action, send, transaction, event, all kinda meaning the same thing.

I think we have to pick one, and also a verb to interact with the wallet

I think the correct one is Action (ie an abstract description of what the user wants to do), and it indicates that it could potentially be multiple Transactions.

The wallet then maps Actions to Transactions.

Then, the wallet takes an Action and "builds" a list of Transactions.

The Transactions are then "broadcast" on the network (not sent, as this is already a thing in SLP/ALP).

This is good. But I think we need to remove the output data from these (and move it into outputs), and also we need to add the token ID to each (except GENESIS).

There can be a mint, burn, send, genesis all in one tx (at least for ALP).

And these will most likely be commonplace in the future: You can burn tokens of one type and mint of another, which is kind of a „reminting“.

Or you can genesis and burn, where the genesis could be a sort of NFT receipt of the burn.

Only these are needed.
The rest can be inferred from the outputs

don’t forget that there can be multiple burns per tx (possibly combined with a SEND)

I think the mint config should be encoded in the outputs.

So here we only need the genesisInfo

Might be worth considering moving this into the Action, then it is self-contained.

Oh wow there’s Required

Should it be exported though? Since it’s internal

I think in the "long form" we have to have 4 functions in total. There ofc will be shorthands:

• Wallet.calcTotal(Action): ActionTotal: Calculate the total token and sats amount
• ActionTotal.prepareUtxos(): PreparedAction: Select UTXOs to fulfill the action. I like prepare because it has a nice adjective (select is a bit worse there)
• PreparedAction.build(): WalletTxs: Build the actual txs (signed and everything).
• WalletTxs.broadcast(): Promise<string[]>: Broadcast the txs and return the txids

This may seem a bit overkill, but trust me, it’ll be important.

Especially for gasless payments, you want to have a lot of fine grain control.

Especially prepareUtxos should give a lot of fine grained control, eg which SIGHASH to use.

I think this function should

nice yeah this makes sense / is simplest

Difficult to get this right at the abstract level, i.e. before we are actually building these txs, getting the utxos for these transactions

High level -- should probably either

1. define all token actions using only Output; design the interface of Output to accomodate this
2. define all token actions where outputs must be calculated by token spec separately from Output in e.g. MintAction, BurnAction.

Imo there is a stronger case for 2.

For example if we have two genesis txs in Action ... we can't just have a bunch of outputs with no tokenId and isGenesis at the outputs key. We need to group the specific genesis outputs we want with each request. Would make sense to do this in distinct GenesisAction objects.

For this diff, I think we need a reasonably-acceptable framework + tentative dev direction. Will need to focus on the specific logic in diffs that add + test this functionality.

If we go this way, do we need MintAction at all? could be a useful interface for GenesisAction but I don't see why we need it as a tokenAction; mint outputs could be defined by isMintBaton and tokenId in Output ....

With this approach, we would also need some way in Output to distinguish between MINT outputs and SEND outputs.

It seems pretty complicated if we specify Outputs for MINT actions in the outputs: key but then also have to "color" these outputs with a MintAction. Want to limit as much as possible the need for a spec just to create the input for ecash-wallet txs.

As above tho, it's hard to get this right in a diff that is not building and testing mint txs. For now we should get a loose placeholder and general agreement on the dev direction, likely to change as we implement.

what if we have more than one GenesisAction? How do we know which isGenesis outputs belong to which GenesisAction?

imo it makes sense to define action-specific genesis outputs in an action interface. Or we could make a rule about only one genesis action allowed.

yes, this is simpler. Since Action will need to be some kind of Interface anyway, might as well add config there as keys. Can still get the desired behavior of "if these keys are not specified, ecash-wallet will use sensible default values".