Resulting in a loss of $44.7 million worth of assets

On April 19th of this year, Hedgey Finance fell victim to a standard flash loan attack by hackers who stole $2.1 million on the Ethereum Mainnet and $42.6 million worth of assets on the Arbitrum network, resulting in approximately $44.7 million lost funds.

Cyvers first reported the exploit, and Hedgey Finance confirmed it a few hours later.

But what does Hedgey finance do?

Background

Hedgey Finance provides a free platform for creating and managing on-chain token vesting, lockups, claim portals, and associated functionalities. It claimed to be “the #1 token vesting and lockup tool,” to this day, it does the same even after the exploit. It’s so ironic. They will need a lot of work to regain that trust.

Vulnerability Analysis & Impact

On-Chain Details

Attacker Address: 0xDed2b1a426E1b7d415A40Bcad44e98F47181dda2

Attack Contract: 0xC793113F1548B97E37c409f39244EE44241bF2b3

Vulnerable Contract: 0xBc452fdC8F851d7c5B72e1Fe74DFB63bb793D511

Main Attack Transactions: 0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739

Root Cause

The root cause of the hack was the lack of input validation on the user’s parameter within a critical function inside the token-locking contracts, which helped the attacker gain access to unauthorized tokens. This token approval vulnerability was created in the ClaimCampaigns Contract (in the line 192).

::github{repo=“hedgey-finance/Locked_VestingTokenPlans”}

The attacker started by taking a flash loan and created a new campaign using the createLockedCampaign() Function. The creation of tokenLocker granted the exploiter’s contract approval to interact with the token vested under the Hedgey’s contract. In the same transaction, the cancelCampaign() function withdraws tokens from the tokenLocker, but it fails to revoke the granted token allowance, although it revoked the claim approval. With the approval still there, the attacker can transfer other unauthorized tokens.

The Attack

Transaction 1: Preparation

1. The attacker receives $1.3M USDC in flash loan from Balancer for the exploit contract.
2. Attacker creates campaign with locking $1.3M USDC via the createLockedCampaign() function.
3. Attacker cancels campaign via the cancelCampaign() function, exploit contract receives the locked $1.3M USDC back and returns it to the Balancer.

Transaction 2: Draining Funds

1. The cancelCampaign() function does give back the funds but doesn’t revoke the allowance for using transferFrom on the USDC token contract.
2. The attacker used this door to drain $1.3M USDC from the ClaimCampaigns contract using transferFrom on the USDC token contract.
3. In addition to USDC, a large number of NOBL Tokens were stolen from the ClaimCampaigns contract valued at $0.8M at that time. Also, adding to it, $20K MASA tokens were stolen.

1. The attacker also utilized the Arbitrum network to exploit the same vulnerability to abscond with more than 77.74M BONUS tokens valued at around $42M at the time of the exploit. On Arbitrum,

Exploiter’s address: 0xc7241e27ee4b8d32b59a10e848b48530047a8c5b

Attack Contract: 0xbb52f1723ddf2c84ba2668f4e04712f572cbf780

Exploited Contract: 0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511

Total Loss

Since the liquid backing of the token is essential to determine the actual value of the tokens stolen, the real loss is much less than the loss reported by multiple reports. The attacker’s wallet still has a balance of 76.8M BONUS tokens. A further 200k tokens were transferred to a Bybit account, and ~900k tokens remain in additional wallets. So, the total loss is around $600K on Arbitrum and $2.1M on Ethereum, totaling $2.7M.

The flow of Funds

Too complex to explain, I know, and that too in writing. Very difficult. Hopefully, you will understand what took place from the above flow diagram.

Aftermath

Following the hack, the Hedgey team went on X to inform its users about the hack and advise users to cancel their active claims to mitigate any additional impact. Hopefully, it mitigated some potential loss.

Lessons Learned

A reminder of the importance of robust security measures in decentralized finance (DeFi) protocols.

• Input validation and parameter verification are fundamental safeguards against exploitation.
• Auditing is essential and helps remove vulnerabilities pre-hack.
• This incident also highlights the limitations of audits and the importance of real-time transaction security measures. As mentioned before, the detection by Cyvers.
• Business logic maintenance is crucial in any project’s development and design process.
• The flaw was solved as quickly as adding and deleting a line of code.

These crypto exploits are a constant reminder of the importance of security in this field. This line of code cost Hedgey around $3M, which is expensive. The question remains: can Hedgey reclaim the trust it has lost?

A Precompile for secp256r1 Curve Support

If you see the original proposal RIP-7212 (formerly EIP-7212), it says,

This proposal creates a precompiled contract that performs signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, r and s components of the signature, x and y coordinates of the public key. So that, any EVM chain - principally Ethereum rollups - will be able to integrate this precompiled contract easily.

after reading this, if you are like me, you would say, “What the heck is this?”. This needs a lot of foundation to understand the whole scope of problems it solves and the innovation that can be built on top of that.

First up is Externally owned accounts.

Externally owned accounts

Externally owned accounts are accounts controlled by anyone with private keys. The basic idea is to create a pair of cryptographic keypairs, one public, and one private key. It can be done using a regular Diffie Hellman algorithm (the discrete logarithm method), which seems much more straightforward than the Elliptic curve digital signature method. So why an elliptic curve?

Elliptic Curves

Elliptic curves are more computationally efficient and use shorter keys, which saves transaction fees compared to other algorithms at work. Let’s understand it a little.

This might look very complex on the surface level, but mathematically, it’s easy. If you want to explore this further, you can read this: https://www.math.brown.edu/johsilve/Presentations/WyomingEllipticCurve.pdf, as I will not dive deep into this.

In simple terms, the curve below is used to get random points on the curve by creating and reflecting lines. Those points can be used to develop keypairs.

The elliptic curve is defined by following mathematical equation,

by varying a and b, we can have multiple equations and their pair curves.

secp256k1 vs secp256r1

In mathematics, the two most common elliptic curves defined in SEC 2 are secp256k1 and secp256r1. Note the “r” in the penultimate position rather than a “k.” The “k” in secp256k1 stands for Koblitz, and the “r” in secp256r1 stands for random.

For secp256k1, we have

a = 0
b = 7

and for secp256r1 (also called NIST P-256), we have

a = FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFC
b = 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B

Random seems more secure, but the fun fact is that Bitcoin started with secp256k1, aka the Koblitz curve. The reason comes from the conspiracy of the NSA controlling NIST, who might have created a backdoor using the random number generator in secp256r1 for a & b. Given the fact that the curve r1 is pseudo-randomized, thus such weak curves could be used under the attack. As a result, Satoshi decided to use a pre-defined pure Koblitz curve for Bitcoin. Not to mention, the Koblitz curve is more efficient, comparatively.

Now, using the secp256k1 elliptic curve, a user can create a signature for a transaction using a private key, which anyone can use to verify if a particular transaction was signed by a public address or not. To understand this practically, there is this fantastic website that you can use: https://andersbrownworth.com/blockchain/public-privatfantasticys/signatures.

Why even care about secp256r1?

Curious? Why is there so much effort in using secp256r1? Even when both curves have almost the exact cost of combined attacks and security conditions. One of the most essential functions is that this curve is widely used and supported in many modern devices, such as Apple’s Secure Enclave, Webauthn, and Android Keychain, which improves user adoption. It solves the challenge web3 currently faces, “cumbersome user experience (UX).”

For example, the Apple secure enclave only works with secp256r1 as it is a hardware-based key manager isolated from the main processor, meaning you can’t change how the signature is produced but can verify it. And if the protocol is just using secp256k1, we can’t have FaceID-integrated web3 mobile applications.

We need to know more about account abstraction to know what RIP-7212 brings to the table.

EIP-4337: Account abstraction

The idea was first tossed in 2017 with the proposal of EIP-86 by Vitalik Butrin. However, the notion of account abstraction existed only with the proposal of EIP-4337, as it avoided making changes to the consensus-layer protocol.

Instead of changing the bottom-layer transaction type and adding new protocol features, this proposal introduced a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation into a separate mempool using a bundler to set the objects into a transaction while making a handleOps call to a special contract, and that transaction then gets included in a block using an entrypoint.

The key goal achieved was to allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account.

Users can now send UserOperation, which contains all the same parameters as the transaction, like “sender,” “to,” “calldata,” “maxFeePerGas,” “nonce,” “maxPriorityFee,” and “signature.” Apart from this, it also has the Signatature field is not defined by the protocol but by each account implementation.

This means you can use any signature algorithm adhering to your needs for the application from secp256r1 to Ed25519. Lost? Why is there a need for RIP-7212? What else must be done if EIP-4337 created the support to use secp256r1?

Precompiled Contracts

Higher gas cost. Unfortunately, using a non-native Ethereum curve generates a higher computational cost (gas). Compared to the native curve, it is around 50 times more. Because precompiled contracts support the native curve. What are precompiled contracts?

Precompiled contracts are special kinds of contracts bundled with the EVM at a fixed address and can be called with a determined gas cost, which is far lower than calling non-precompiled smart contracts.

0x01 is the ECRECOVER precompiled address is a function to get the public address from a signature for the secp256k1 curve. RIP-7212 proposes a new precomplied contract for secp256r1, P256VERIFY , similar in function to the prior but for the secp256r1 curve.

In summary,

RIP-7217 proposes to create a precompiled contract for the secp256r1 curve.

Hopefully, you might get the picture that I wanted to paint in your mind.

Bonus. Still don’t know the reason for it being RIP, not EIP? So, other willing rollups can use this to complete implementation around the standardization created with RIP.

Resources:

::link{url=“https://eips.ethereum.org/EIPS/eip-7212”} ::link{url=“https://ethereum-magicians.org/t/eip-7212-precompiled-for-secp256r1-curve-support/14789”} ::link{url=“https://www.johndcook.com/blog/2018/08/21/a-tale-of-two-elliptic-curves/”} ::link{url=“https://eips.ethereum.org/EIPS/eip-4337”} ::link{url=“https://eprint.iacr.org/2023/939.pdf”} ::link{url=“https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave”} ::link{url=“https://www.odaily.news/en/post/5188615”} ::link{url=“https://dappworks.com/why-did-satoshi-decide-to-use-secp256k1-instead-of-secp256r1/”}

A Smart Contract Language on the rise

“Move,” a language that has been rising recently with the development of emerging blockchains like Aptos and Sui. Now, we can watch the steady development in Solana.

Move programming language is a safe and flexible language built for the blockchain giving you power for programable resources.

Let’s begin by deep-diving into Move to understand it better,

Why Move?

It was originally built by Facebook’s Libra/Diem Blockchain — a payment network. The language came into existence with the native support for ownership/assets which other languages were lacking. The design of Move defines custom resource types forcing a resource can’t be copied or implicitly discarded, only moved between program storage locations. Basically, the safety is implemented by Move’s type system.

In layman’s terms, Move is statically typed and designed around modules giving it a fundamental advantage compared to other languages.

Move was designed while keeping four key goals in mind: first-class resources(assets), flexibility, safety, and verifiability.

First-class resources: Let users write programs that directly interact with the digital assets while using the type system guaranteeing safety.

Flexibility: Move adds flexibility via transaction scripts. A transaction script is a single procedure that contains an arbitrary Move code, which allows customizable transactions.

Safety: Move rejects any program that does not satisfy key properties, such as resource safety, type safety, and memory safety. It is ensured by the on-chain bytecode verifier and after verification, it is directly executed by the bytecode interpreter.

Verifiability: Security and computational cost go hand in hand, we have to carefully weigh both. Move balances the two by using lightweight on-chain verification and advanced off-chain static verification tools.

The key difference is Solidity’s storage is address-based whereas Move’s storage is object-based.

But how it is different from Solana?

I assume you have familiarity with Solana’s Programming model or else you can give a read to this.

The biggest difference is that Move doesn’t require account checks. Which is very tricky to implement on Solana and also a reason for some biggest exploits (account substitution attacks). Solana has to run checks such as account ownership, type, instance, and signature checks.

So how Move is handling this? In the Move runtime, some of the checks are transparently run and the rest of them are verified statically at the compile time. Even the type system design allows Move to skip some of the checks often required in Solana.

For example, due to checks and other declarations, the “Mint Authority” code in Solana and Move (Sui) has a distinct gap in size.

Apart from the checks, Solana stores the addresses of other accounts in the form of pointers and doesn’t store the actual data. To access the accounts, they need to be passed every time and manually checked. On the other hand, in Move, we can directly access them using structs indefinitely without running any checks.

This is the reason, “Move becomes a lot safer and faster option to code due to its global typed system and natural design.”

An example of Move from the Move book:

module 0x42::test {
    struct Example has copy, drop { i: u64 }

    use std::debug;
    friend 0x42::another_test;

    const ONE: u64 = 1;

    public fun print(x: u64) {
        let sum = x + ONE;
        let example = Example { i: sum };
        debug::print(&sum)
    }
}

If you want to explore coding in Move you can check out this curated list. Also, this Move tutorial is a good place to get started.

::github{repo=“MystenLabs/awesome-move”} ::github{repo=“move-language/move”}

All this was a technical overview of the “Why Move?”. But do we have a community of developers who are interested in this?

Move community

Even Aptos and Sui (Move-based blockchains) are fairly new blockchains, they have a much greater number of developers compared to blockchains Algorand and Stacks who use their programming languages.

To make this read more interesting I figured why not get to know the behind-the-scenes of the project Move on Solana. It’s a good way to give your brain a headache, at least to mine, lol.

Move on Solana

Before getting into all the heavy stuff, knowing how Move works is convenient to understand.

How Move Works?

Move is built on Rust with ownership in mind and is strongly focused on simplicity, correctness, and verifiability. It doesn’t support dynamic dispatch which makes it faster, efficient, and allows early detection of type errors.

First, the Move code is compiled into Move bytecode, which runs in the Move VM for the Bytecode validation. The traditional architecture of the Move virtual machine:

There are three ways we can get Move on Solana:

1. Compile Move to SBF (like Solang): To implement this we might have to skip the Move Bytecode verification part, making it useless as we are not able to utilize all the advantages attached to Move.
2. Add the Move VM as a native loader (alongside the SBF VM): This is a nice intuitive idea, but maintaining two different loaders in the runtime is not ideal for security (as it increases the attack surface by twice).
3. Run the Move VM as a program: Out of all the options, this becomes inevitably the most reliable way to implement Move as it has already been carried out for running EVM on Solana (Neon).

To approach the implementation of running the Move VM as a program, we would need to create a Move-LLVM compiler, this will become clear as we proceed forward in the article.

LLVM Backend for Move

So, LLVM? LLVM (Low-Level Virtual Machine) is a set of compilers and toolchains, used to create the front end of any programming language or backed for any instruction set architecture.

I know, LLVM can be intimidating to code. So why even try to do it? Because Solana runtime uses it.

First, The compiler breaks down the rust source code into lexemes, and then it verifies the correctness and validates the logic. In the second stage, the compiler generates the intermediate representation (IR) code. Now, the LLVM optimizer comes into play, which complies IR into optimized IR code (LLVM bytecode). In the end, the optimized IR code is translated into Solana Binary Format (SBF, a Solanaized eBPF).

It makes sense to replace the Rust source code with the Move source code and generate IR code.

In Rust, we have a few options to interface to LLVM:

• llvm-sys — raw unsafe bindings to the LLVM C API
• inkwell — idiomatic Rust bindings to llvm-sys
• llvm-ir — another high-level Rust binding

“llvm-sys”, llvm’s Rust C bindings stands out as the best option and it was used to develop the current Move-LLVM backend.

::github{repo=“anza-xyz/move”}

Challenges of Porting Move

The Move language and the Move VM are tightly integrated. The Move bytecode must be validated on the Move VM before running as any other platform that doesn’t interpret the bytecode will lack the security and guarantee that comes with Move.

As all blockchains have a strong process boundary between any two programs, it’s very hard to see Move coming into the picture with SBF. This causes a barrier to run Move on Solana. Meaning that just converting the Move source code to IR is not enough. Even after compiling it to LLVM, the Move code doesn’t have access to services provided by Move VM.

The Move VM is a stack machine, and LLVM is a register machine, so how to translate one to the other is not immediately obvious. This could have become a technical challenge but we have, Move Stackless Bytecode. Move stackless bytecode is a transformation of the Move bytecode to a register machine model while utilizing the Move theorem prover.

Another technical problem that arises is how to deal with missing LLVM APIs. While LLVM C APIs have almost every feature, usually, developer needs to add their little library to expose the C++ APIs.

Future?

Now you might all agree that Move is an amazing piece of technology. And I believe having Move on Solana in the long run is worth it.

There will be more problems to be solved as the project moves forward. But when the project Move is concluded, I will be back with “Coding Move on Solana”.

Looking into the new lookup table

Solana is fast; I mean, it allows hyper-parallelized processing of transactions, in turn enabling a high TPS. But there’s a catch. For even higher TPS, the transaction size is limited to the IPv6 MTU standard, which is 1280 bytes, after accounting for headers, leaving 1232 bytes for serialized transactions.

One common workaround was to store the state temporarily on-chain and consume that state in later transactions. But it doesn’t work with more composition of on-chain programs where more account inputs are needed, each of which takes up 32 bytes. In summary, the problem is to increase the number of accounts that can be processed in a single transaction. The solution was proposed: why not just decrease the size of the addresses from 32 to one byte?

This is where the new Versioned transaction (or transaction v0) comes into the picture. The versioned transaction is an update to Solana runtime, introducing a new transaction format.

This article will explore exactly how everything works under the hood and how you can set up and use it on the go. In the first part of the article, we will describe how legacy transaction works to get the foundation right.

Legacy Transaction

The legacy transaction is comprised of a compact array of signatures (64 bytes for each signature) and a message. The Legacy Message has four elements of data, which are,

• Header (3 bytes)
• A compact array of account addresses (32 bytes for each account)
• Recent Blockhash (32 bytes)
• Compact Array of Instructions

If you don’t know what a compact array is, “The compact array is an array serialized to have the number of items (special multi-byte encoding, compact-u16) and then all the items.”

The first component is the header, which has the number of required signatures, the number of read-only addresses that require signatures, and the number of read-only addresses that don’t require signatures. Each takes the space of a byte (u8), making it a total of three bytes.

Moving on to the compact array of instructions, each instruction has a program ID index (a byte, u8), a compact array of account address indexes, and opaque 8-bit data.

The next one is the compact array of account addresses, and here it contains the account address classified into requiring signature or not and further into read-only or read/write request. This is where the issues arise.

1. The max. transaction size is 1232 bytes.
2. One account address is 32 bytes.
3. If we take into account some headers, signatures, and other metadata, we are left with space only for a maximum of 35 accounts.

This doesn’t look good for a blockchain such as Solana, where you can only transact with 35 accounts simultaneously.

In fact, it is possible for an Ethereum account to send to multiple addresses within a single transaction. However, the block gas limit limits the number of addresses. The block gas limit that is currently in place is 12,500,000 gas. In a transaction that sends money to 100 addresses, almost 21,000 gas will be used. Consequently, it would mean that an Ethereum account can send to around 595 different addresses in one transaction.

The solution comes with the update to the legacy transaction in the versioned transaction (transaction v0). So, what’s comes with Transaction v0?

• Introduces a new program that manages on-chain Address lookup tables (LUTs).
• New Transaction format, which makes use of LUTs.

Now, let’s delve into the idea of Address Lookup tables,

Address Lookup Tables (ALTs or LUTs)

ALTs stores address in an on-chain array(table-like). After addresses are stored on-chain in an address lookup table account, they may be succinctly referenced in a transaction using a 1-byte u8 index rather than a full 32-byte address. As indices take u8 memory value, we can have a maximum of 256 accounts (2⁸).

So, if we need to accommodate 5 addresses in a legacy transaction, it takes 160 bytes, as in transaction v0, it will only take 37 bytes (after including the ALT’s address, which takes 32 bytes + 4 bytes for four accounts).

ALTs need to be rent-free when initialized and after new addresses are appended each time. Addresses can added to the table using the on-chain buffer or by directly appending them to the table using the Extension instruction. (ALTs can also store associated metadata followed by the compact array of accounts).

Before versioning was introduced, all the transactions left an unused upper bit in the first byte of their message headers, which can now be used to declare our transactions’ version. Now, if the first bit is set, the other seven bits will encode a version number. In this case, “version 0” means you can use LUTs. If not, it will fall back to “legacy”.

pub enum VersionedMessage {
   Legacy(Message),
   V0(v0::Message),
}

MessageV0, What changed?

1. Message Header: Unchanged
2. Compact array of Accounts: Unchanged
3. Recent Blockhash: Unchanged
4. Compact array of instructions: Change from Legacy
5. Compact array of ALTs: Introduced in V0

The Compact array of ALTs is now compromised of the number of address lookup tables (in compact-u16 encoding) and an array of all address lookup tables.

Each Address lookup table in the array has three components →

1. Account Key (u8)
2. Writable Indexes: Compact array of writable account address indexes
3. Read-Only Indexes: Compact array of read-only account address indexes

If we talk about changes in the compact array of instructions, the structure remains unchanged, but how it’s processed becomes a little different.

To remind the structure of a compact array of instructions, we have,

1. Program ID index
2. A compact array of account address indexes
3. A compact array of opaque 8-bit data

Only the compact array of accounts stored in the message is used in legacy transactions. But in v0, both the compact array of accounts stored in the message and indexes from the lookup table are used. Check here for the new transaction format.

Enough theory behind the versioned transaction. From a developer’s point of view, we should look into what changes have been made in RPC and overall coding.

RPC Changes

Some methods that got updated are:

1. getTransaction
2. getBlock

The methods will require the following parameter to indicate which transaction structure needs to be followed for the deserialization:

maxSupportedTransactionVersion: 0

If this is specified, it will account for it as a versioned transaction or fall back to a legacy transaction. Any block utilizing the versioned transaction will give an error in the case of the legacy transaction request.

It’s also important to note that versioned transactions allow users to create and use another set of account keys loaded from on-chain address lookup tables, so it’s recommended to use “jsonParsed” encoding.

"encoding": "jsonParsed"

Example of a JSON request to the RPC:

curl <http://localhost:8899> -X POST -H "Content-Type: application/json" -d \\
'{"jsonrpc": "2.0", "id":1, "method": "getBlock", "params": [430, {
  "encoding":"jsonParsed",
  "maxSupportedTransactionVersion":0,
  "transactionDetails":"full",
  "rewards":false
}]}'

Now, let’s talk about how you can send a versioned transaction request,

Sending a Versioned Transaction

Initially, if you wanted to send the legacy transaction, the code would have looked like this,

const {
  context: { slot: minContextSlot },
  value: { blockhash, lastValidBlockHeight },
} = await connection.getLatestBlockhashAndContext();
const transaction = new Transaction({
  feePayer: publickey,
  recentBlockhash: blockhash,
})
transaction.add(
  new TransactionInstruction ({
    data: Buffer.from( 'Hello, Solana!'),
    keys: [],
    programId: new PublicKey('MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr'),
  })
);
const signature = await sendTransaction(transaction, connection, { minContextSlot });
await connection.confirmTransaction({ blockhash, lastValidBlockHeight, signature });

Developers now have to use a new class, VersionedTransaction instead of Transaction. So, while building the versioned transaction, it’s similar to a legacy transaction except for the new VersionedTransaction Class.

// create array of instructions (here, transfer instruction)
const instructions = [  SystemProgram.transfer({
    fromPubkey: publicKey,
    toPubkey: publicKey,
    lamports: 10,
  }),
];
// create v0 compatible message
const messageV0 = new TransactionMessage({
  payerKey: publicKey,
  recentBlockhash: blockhash,
  instructions,
}).compileToV0Message();
// make a versioned transaction
const transactionV0 = new VersionedTransaction(messageV0);

Once the instruction is set, the transaction can be signed and sent using the signAndSendTransaction method to the desired provider,

const provider = getProvider();
const network = "<NETWORK_URL>";
const connection = new Connection(network);
const versionedTransaction = new VersionedTransaction();
const { signature } = await provider.signAndSendTransaction(versionedTransaction);
await connection.getSignatureStatus(signature);

Forging an Address Lookup table

We can use the AddressLookupTableProgram inside@solana/web3.js to construct the lookup table effectively. Use the createLookupTable function to build the table, then create a transaction, sign it, and send it to create a lookup table on-chain.

// create an Address Lookup Table
const [lookupTableInst, lookupTableAddress] = AddressLookupTableProgram.createLookupTable({
  authority: publicKey,
  payer: publicKey,
  recentSlot: slot,
});
// to create the Address Lookup Table on chain
const lookupMessage = new TransactionMessage({
  payerKey: publicKey,
  recentBlockhash: blockhash,
  instructions: [lookupTableInst],
}).compileToV0Message();
const lookupTransaction = new VersionedTransaction(lookupMessage);
const lookupSignature = await signAndSendTransaction(provider, lookupTransaction);

We created a Lookup table on-chain and got the address, but we need to extend the table, i.e., appending some account addresses to it.

Easy, just use the extendLookupTable method. Here is how it goes…

// add addresses to the Lookup Table Address via an `extend` instruction
const extendInstruction = AddressLookupTableProgram.extendLookupTable({
  payer: publicKey,
  authority: publicKey,
  lookupTable: lookupTableAddress,
  addresses: [    publicKey,
    SystemProgram.programId,
    // more `publicKey` addresses can be listed here
  ],
});
// send the transaction to update the data on-chain
const extensionMessageV0 = new TransactionMessage({
  payerKey: publicKey,
  recentBlockhash: blockhash,
  instructions: [extendInstruction],
}).compileToV0Message();
const extensionTransactionV0 = new VersionedTransaction(extensionMessageV0);
const extensionSignature = await signAndSendTransaction(provider, extensionTransactionV0);

Awesome! We created the lookup table, but how about we use them now?

Utilizing the Address Lookup table

First, fetch the accounts of the Address lookup table we created and read all the addresses.

// get the Lookup table
const lookupTableAccount = await connection.getAddressLookupTable(lookupTableAddress).then((res) => res.value);
console.log('Table address:', lookupTableAccount.key.toBase58());
// read all the address stored in the table
for (let i = 0; i < lookupTableAccount.state.addresses.length; i++) {
  const address = lookupTableAccount.state.addresses[i];
  console.log(i, address.toBase58());
}

Next, use the addresses with any desired instruction.

// create an your desired `instructions` (here, transfer instruction)
const instructions = [  SystemProgram.transfer({
    fromPubkey: publicKey,
    toPubkey: publicKey,
    lamports: minRent,
  }),
https://github.com/satyvm/solana-versioned];
// create v0 compatible message
const messageV0 = new TransactionMessage({
  payerKey: publicKey,
  recentBlockhash: blockhash,
  instructions,
}).compileToV0Message([lookupTableAccount]);
// make a versioned transaction
const transactionV0 = new VersionedTransaction(messageV0);
const signature = await signAndSendTransaction(provider, transactionV0);

But you might be thinking now, I want to try out, here you go…

Get your hand dirty

Let’s get on with this! Clone a repo using the following command,

::github{repo=“satyvm/solana-versioned”}

git clone https://github.com/satyvm/solana-versioned

Then, install all the required libraries using

yarn

Pop into the createTable.ts file and put your private key in the 9th line of code. Also, remember to put some Solana Devnet Faucet to the account are using. Afterward, run the following command to create a lookup table. (For example, mine was like this)

yarn ts-node createTable.ts

Get your Lookup table address from the terminal. It will look something like this (here the lookup table address is 4iSg5upfgCrLAmcfBRaDxcqwKbvjTZti9bDjyqhmJrq6)

Open the app.ts file and put your private key and lookup table address in their places (lines 9 & 15). Lastly, run the file using,

yarn ts-node app.ts

Your terminal will look something like this,

Congratulations! 🎉 You’ve successfully run the code. If you observe, you will see the transaction size is hugely reduced. That’s how much the lookup table is effective.

This was a very deep dive into the inner workings of the new versioned transaction Solana introduced.