Module transfer 

CIP-56 transfers: resolve the factory, take its context, exercise the choice.

A transfer is not a command a client can build on its own. The factory that implements it is the registry’s contract, and the choice needs reference data only the registry has. So it takes two steps, and the first one is an HTTP call:

1. Ask the registry for the transfer factory, passing the transfer as the choice arguments it will be exercised with. The registry answers with the factory’s contract id, how the transfer will be carried out, and the choice context.
2. Exercise TransferFactory_Transfer on that factory with the context filled in, disclosing the contracts the registry named.

The transfer passed in step 1 carries empty extraArgs — the standard says so — because the context does not exist yet. It is filled in for step 2.

Structs

TokenCommand

A command that carries the contracts it needs disclosed.

Functions

accept

Accept an offered transfer — the receiver’s move.

empty_extra_args

ExtraArgs with nothing in it — what the standard says to send when asking for a factory, since the context being asked for does not exist yet.

reject

Reject an offered transfer — the receiver’s move.

transfer

Resolve the transfer factory and build the exercise that performs transfer.

withdraw

Withdraw an offered transfer — the sender’s move, before it is accepted.