Sending a Versioned Transaction
Last updated
Was this helpful?
Last updated
Was this helpful?
On October 10, 2022, Solana introduced the concept of . Currently, the Solana runtime supports two types of transactions: legacy
(see ) and v0
(transactions that can include ).
The goal of v0
is to increase the maximum size of a transaction, and hence the number of accounts that can fit in a single atomic transaction. With LUTs, developers can now build transactions with a maximum of 256 accounts, as compared to the limit of 35 accounts in legacy transactions that do not utilize LUTs.
On this page, we'll go over the following:
Building a Versioned Transaction
Signing and Sending a Versioned Transaction
Building an Address Lookup Table (LUT)
Extending an Address Lookup Table (LUT)
Signing and Sending a Versioned Transaction utilising a LUT
Versioned transactions are built in a very similar fashion to . The only difference is that developers should use the VersionedTransaction
class rather than the Transaction
class.
The following example show how to build a simple transfer instruction. Once the transfer instruction is made, a MessageV0
formatted transaction message is constructed with the transfer instruction. Finally, a new VersionedTransaction
is created, parsing in the v0
compatible message.
Address Lookup Tables (LUTs) can be used to load accounts into table-like data structures. These structures can then be referenced to significantly increase the number of accounts that can be loaded in a single transaction.
This lookup method effectively "compresses" a 32-byte address into a 1-byte index value. This "compression" enables storing up to 256 address in a single lookup table for use inside any given transaction.
Here's a code snippet that creates a Lookup Table.
Up until now, we have:
Learned how to create a VersionedTransaction
Created an Address Lookup Table
Extended the Address Lookup Table
At this point, we are now ready to sign and send a VersionedTransaction
utilizing an Address Lookup Table.
First, we need to fetch the account of the created Address Lookup Table.
We can also parse and read all the addresses currently stores in the fetched Address Lookup Table.
We can now create the instructions array with an arbitrary transfer instruction, just the way we did while creating the VersionedTransaction
earlier. This VersionedTransaction
can then be sent using the signAndSendTransaction()
provider function.
Check out the function in our code sandbox for a live example of creating a versioned transaction.
Once a Versioned transaction is created, it can be signed and sent via Phantom using the signAndSendTransaction
method on the provider. The call will return a for an object containing the signature
. This is the same way a legacy transaction is sent via the Phantom provider.
You can also specify a SendOptions
as a second argument into signAndSendTransaction()
or as an options
parameter when using request
.
For a live demo of signing and sending a Versioned transaction, please refer to the section of our developer sandbox.
With the @solana/web3.js
function, developers can construct the instruction needed to create a new lookup table, as well as determine its address. Once we have the lookup table instruction, we can construct a transaction, sign it, and send it to create a lookup table on-chain. Address lookup tables can be created with either a v0
transaction or a legacy
transaction. However, the Solana runtime can only retrieve and handle the additional addresses within a lookup table while using v0
transactions.
Please refer to the in our code sandbox for a live demo of creating a lookup table.
Once an Address Lookup Table is created, it can then be extended (i.e. accounts can be appended to the table). Using the @solana/web3.js
library, you can create a new extend
instruction using the method. Once the extend instruction is created, it can be sent in a transaction.
Please refer to the in our code sandbox for a live demo of extending a lookup table.
Please refer to the in our code sandbox for a live demo of signing and sending a versioned transaction utilizing an Address Lookup Table.