chore(solana): upgrade from web3.js to solana kit

[tomiiide]

Which Jira task is linked to this PR?

https://lifi.atlassian.net/browse/LF-13181

Why was it implemented this way?

Explain the reasoning behind the implementation. Were there alternative approaches? Why was this solution chosen?
The solana provider specifies a wallet interface to generalize use without depending on a specific wallet / adapter type as before (e.g SignerWalletAdapter from @solana/wallet-adapter-base )

All it requires is that the wallet can handle transactions types from @solana/kit

import type { Address, Transaction } from '@solana/kit'

export interface SolanaWallet {
  signTransaction(transaction: Transaction): Promise<Transaction>
  account: {
    address: Address
    publicKey: Uint8Array
  }
}

---

Type conversions

Since signTransaction only deals with Transaction types from the @solana/kit, if using web3.js, you have to convert to/from transactions and address types. The solana provider exports all utility functions needed for this.

An example of how do this is here: lifinance/widget#600

Visual showcase (Screenshots or Videos)

If applicable, attach screenshots, GIFs, or videos to showcase the functionality, UI changes, or bug fixes.

Checklist before requesting a review

• I have performed a self-review and testing of my code.
• This pull request is focused and addresses a single problem.
• If this PR modifies the SDK API or adds new features that require documentation, I have updated the documentation in the public-docs repository.

[chybisov]

@tomiiide could you please rebase and make the PR only about Solana Kit changes 🙏 It would be hard to review 273 files again 😅

[tomiiide]

@tomiiide could you please rebase and make the PR only about Solana Kit changes 🙏 It would be hard to review 273 files again 😅

@chybisov done!

[chybisov]

We didn't have a block height update here to reduce the number of requests to the RPC. I think it is fine to update it every second for both cases when we send a transaction below. Wdyt?

[tomiiide]

Hmm, I separated them to avoid race conditions as we are sharing blockheight between two loops.
The polling loop is updating the blockheight, while the sending loop is reading it.

Yes, we get 2x more rpc calls, but better code quality.

[tomiiide]

It does make sense to update once every second when resending, Since the worst case scenario is minimal during a race condition, it just feels dirty.

[chybisov]

By the time we get that race condition, it's probably already an expired transaction anyway. So I understand that it might be a bit cleaner from a code perspective, but I don't see a reason why we need an additional RPC call to get the same block height, so I'd stick with only one call. As a third option, it could be an additional promise for that.

[chybisov]

Is there any way to avoid having @solana/web3.js installed? What do we use it for?

Moving to Solana Kit was supposed to optimize bundle size 😅

[tomiiide]

yes, we can remove it 😁

[chybisov]

Please let's find a way to remove this dependency 🙏😄

[tomiiide]

you mean just @solana/web3.js right?

[tomiiide]

lifinance/widget#600 (comment)

Do we move the compat logic to the widget , and keep the sdk purely solana kit?

[chybisov]

We should not use @solana/web3.js as a dependency in v4 for both Widget and SDK, it's an outdated package.

[chybisov]

I think we should return the adapter like before from the widget, so no versioned txs conversion should happen there. Can we manage this in the SDK without depending on @solana/web3.js?

[tomiiide]

If we return the adapter like before then, the sdk would still need to convert txns to/from versioned txns as the adapters only handle versioned txn types.

We can switch the adapter types to wallet standard uiWallet type like it's done in the @solana/kit example. but that introduces the problem we had before where we have to manage currentWallet state as it's not done by wallet-standard/react.

There is an official library that does this, and the first version has been released, but we need this PR merged to be able to fully support it.

Therefore my suggestion is to have the transaction compatibility layer live on solana-widget-provider for now, and after framework-kit is mature, we can completely migrate solana wallet management to wallet-standard without issues.

[tomiiide]

@effie-ms ^^

[effie-ms]

I guess conversion in solana-widget-provider is fine for now, if there is no workaround yet.