How to build and send a complex Flow transaction from the command line
Simple Transactions
Sending a transaction using the Flow CLI can simply be achieved by using the send command documented here.
Complex Transactions
If you would like to build more complex transactions the Flow CLI provides commands to build, sign and send transactions allowing you to specify different authorizers, signers and proposers.
The process of sending a complex transactions includes three steps:
Read more about each command flags and arguments in the above links.
We will describe common examples for complex transactions. All examples are using an example configuration.
The simplest Flow transaction declares a single account as the proposer, payer and authorizer.
Build the transaction:
1> flow transactions build tx.cdc2--proposer alice3--payer alice4--authorizer alice5--filter payload --save tx1
Sign the transaction:
1> flow transactions sign tx1 --signer alice2--filter payload --save tx2
Submit the signed transaction:
1> flow transactions send-signed tx2
Transaction content (tx.cdc
):
1transaction {2prepare(signer: AuthAccount) {}3execute { ... }4}
A transaction that declares same payer and proposer but multiple authorizers each required to sign the transaction. Please note that the order of signing is important, and the payer must sign last.
Build the transaction:
1> flow transactions build tx.cdc2--proposer alice3--payer alice4--authorizer bob5--authorizer charlie6--filter payload --save tx1
Sign the transaction with authorizers:
1> flow transactions sign tx1 --signer bob2--filter payload --save tx2
1> flow transactions sign tx2 --signer charlie2--filter payload --save tx3
Sign the transaction with payer:
1> flow transactions sign tx3 --signer alice2--filter payload --save tx4
Submit the signed transaction:
1> flow transactions send-signed tx4
Transaction content (tx.cdc
):
1transaction {2prepare(bob: AuthAccount, charlie: AuthAccount) {}3execute { ... }4}
A transaction that declares different payer, proposer and authorizer each signing separately. Please note that the order of signing is important, and the payer must sign last.
Build the transaction:
1> flow transactions build tx.cdc2--proposer alice3--payer bob4--authorizer charlie5--filter payload --save tx1
Sign the transaction with proposer:
1> flow transactions sign tx1 --signer alice2--filter payload --save tx2
Sign the transaction with authorizer:
1> flow transactions sign tx2 --signer charlie2--filter payload --save tx3
Sign the transaction with payer:
1> flow transactions sign tx3 --signer bob2--filter payload --save tx4
Submit the signed transaction:
1> flow transactions send-signed tx4
Transaction content (tx.cdc
):
1transaction {2prepare(charlie: AuthAccount) {}3execute { ... }4}
A transaction that declares same payer, proposer and authorizer but the signer account has two keys with half weight, required to sign with both.
Build the transaction:
1> flow transactions build tx.cdc2--proposer dylan13--payer dylan14--authorizer dylan15--filter payload --save tx1
Sign the transaction with the first key:
1> flow transactions sign tx1 --signer dylan12--filter payload --save tx2
Sign the transaction with the second key:
1> flow transactions sign tx2 --signer dylan22--filter payload --save tx3
Submit the signed transaction:
1> flow transactions send-signed tx3
Transaction content (tx.cdc
):
1transaction {2prepare(signer: AuthAccount) {}3execute { ... }4}
This is an example configuration using mock values:
1{2...3"accounts": {4"alice": {5"address": "0x1",6"key": "111...111"7},8"bob": {9"address": "0x2",10"key": "222...222"11},12"charlie": {13"address": "0x3",14"key": "333...333"15},16"dylan1": {17"address": "0x4",18"key": "444...444"19},20"dylan2": {21"address": "0x4",22"key": "555...555"23}24}25...26}