okx/go-wallet-sdk

Multi-chain golang signature sdk, supports bitcoin, ethereum, aptos, cosmos, etc.

go-wallet-sdk

This is a Go language wallet solution that supports offline transactions. We currently support various mainstream public blockchains, and will gradually release the source codes for each blockchain.

Supported chains

	Account Generation	Transaction Creation	Transaction Signing
BTC	✅	✅	✅
Ethereum	✅	✅	✅
EOS	✅	✅	✅
Filecoin	✅	✅	✅
Polkadot	✅	✅	✅
Starknet	✅	✅	✅
Aptos	✅	✅	✅
Near	✅	✅	✅
Solana	✅	✅	✅
Stacks	✅	✅	✅
SUI	✅	✅	✅
Tron	✅	✅	✅
Cosmos	✅	✅	✅
Axelar	✅	✅	✅
Cronos	✅	✅	✅
Evmos	✅	✅	✅
Iris	✅	✅	✅
Juno	✅	✅	✅
Kava	✅	✅	✅
Kujira	✅	✅	✅
Okc	✅	✅	✅
Osmosis	✅	✅	✅
Secret	✅	✅	✅
Sei	✅	✅	✅
Stargaze	✅	✅	✅
Terra	✅	✅	✅
Tia	✅	✅	✅
Avax	✅	✅	✅
Elrond	✅	✅	✅
Flow	✅	✅	✅
Harmony	✅	✅	✅
Helium	✅	✅	✅
Kaspa	✅	✅	✅
Nervos	✅	✅	✅
Oasis	✅	✅	✅
Tezos	✅	✅	✅
Waves	✅	✅	✅
Zil	✅	✅	✅
Zkspace	✅	✅	✅
Zksync	✅	✅	✅

*BTC: Supports Supports BRC20-related functions, including inscription creation, BRC20 buying and selling.

Main modules

• coins: Implements transaction creation and signature in each coin type.
• crypto: Handles general security and signature algorithms.
• util: Provides various utility class methods.

Example

For specific usage examples of each coin type, please refer to the corresponding test files. Remember to replace the placeholder private key with your own private key, which is generally in hex format.

Feedback

You can provide feedback directly in GitHub Issues, and we will respond promptly.

License

Most packages or folder are MIT licensed, see package or folder for the respective license.

go-wallet-sdk's Issues

The ConvertBigInt function under the brc20 package does not need to be exported from uti

Hello, I found several problems in the tx_taproot.go file when using brc20. This is because in the ConvertToBigInt function, it calls util.go in the current package directory. Instead of the one under the imported util package.

Solana decode raw transaction error

When decode raw transaction that created by Dapp, it looks like the accountTableLookups field is lost.

Demo:

rawStr := `AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAQADEO4Ti7ELpNlheK34aS1nU9SyOahrxNVhKc+HBUZ8Ok9+/r1cmarYUU2+uQ6Xfw2GeW+S3hbe7NhNes+gkeBjrDQGm4hX/quBhPtof2NGGMA12sQ53BrrO1WYoPAAAAAAAfWyieNQagqfYXHrGOZaCpVC7WHqfbyrZqba4MvDz3bR8M3vtrj9zOXD1v/fLYpG1Hu3oBu2o5UGbt1uv1R5/KDG+nrzvtutOj1l82qryXQxsbvkwtL24OR8pgIDRS9dYd6TBhiVE97EIUaTDBrSmxNiGFrvvaYVTVujoW1sUpU8W23FfY/TovEu0rqX0rE58cUzVl3A1cbBz//toyNr6uhssz2cjVCgS1WL7Q3b0kRCvws2k57E2iO7OUxnRHCpgzeZjMvy0EWLYVy8xrGjZ8R0np/vcwZiLhsbWJEBILyaUWe8Ce5CtE6sos2GtueIi2BEN2LGrxhcdoXf9Mkkob/ZbqMZ2O42JQfrfuwWxFdU4EE4tU9AOkF71ZDxKyf2ls2sAwhan+XTRRltrXJYuOBut94oEC91I0gF3n8u42ebAwZGb+UhFzL/7K26csOb57yM5bvF9xJrLEObOkAAAAAMwoDLa+MZLFA4OAHPRDAYD54/hmMiOsgBBpcQ2/fVB0FXsFgPMcX85EpiWC28+deO51lDoISjk7NQNo0iiZMIe0wTdioaHkfxqWFhqLW7pmeEA+i/4pO2PYD7PtMaZHIFDQAJA1z6DQAAAAAADQAFAtZyAgAOBgABAhAREgkFQEIPAAAAAAAOKRATERIAAQMUBAIFBg8GBgYHCAYGBgYGBhQDBQkKDwoKCgsMCgoKCgoKEQBAQg8AAAAAAAaKAQAAAAAADgYAAQAQERIBBgEZjx9MOkUiY9QTss0X68vBoOWIc2TmJhoSqBeS6hZaPgAFAgcAAw4=`
	tx := base.Transaction{}
	err := tx.UnmarshalBase64(rawStr)
	if err != nil {
		panic(err)
	}

	j, _ := json.Marshal(tx)
	println(string(j))

This transaction is created by Raydium, when decode transaction by nodejs or gagliardetto/solana-go, it has accountTableLookups, when use okx/go-wallet-sdk/, it does not have accountTableLookups.

mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)

I tried to run test cases for BTC trading, but I always get this error after replacing it with my own parameters.

🫣🫶🙋👍🤑👦👔👑👍💋

feat: support estimate gas function for cosmos-based chain

Can we add new functions to simulate or estimate the gas used for a given cosmos-based chain transaction😀

Add support for other tokens, and/or coinType 459 when generating wallet keys for Kava network (Cosmos/IBC side)

sorry, mistaken

aptos签名问题

链上正常交易signature 是128个的字节,如下

"signature": {
        "public_key": "0x251fd4510d9e36d99e19a07c857ecee24a13d596afa6382660649eab5b44362e",
        "signature": "0xec02833c4096e6c5eb4467abaf8969798f57dfb9c7044b2b79a7d8b7c22aa23158840f027a60daf2c0e08c293e378b5cabca03f8eb5e6e7e93eed0baa451e708",
        "type": "ed25519_signature"
      }

但使用Transfer的签名返回的data

ffb6fac50e85d7c6ae1b13347fac94c819bf68b1b45ae612a5d51e264e0a27fe12000000000000000200000000000000000000000000000000000000000000000000000000000000010d6170746f735f6163636f756e74087472616e73666572000220d6d64011d498462e065d0c85648cb357e2f1c9df37d9179755ddf89c1e830c7708e803000000000000102700000000000064000000000000007e684466000000000200201e1ec33d978305d669d3b35dc0db56525335ec3b35791a44ad130987133c971e40db196b84333bcf3eecec5ea5e7ced8e5f5231a6ea88e2f4274fb79c098b0b04c608ff8a1cebc55c87d9c830e7bc52ee39f1301ca2c8925ab6a1ba548aeeec400

Solana Chain Derivation Path

Hi OKX Team,

By following https://www.okx.com/web3/build/docs/build-dapp/private-key-wallet-go-sdk#supported-coins, the Solana chain derivation path should be m/44'/501'/0'/0/0, but during my test, using the same 12-word recovery phrase, the actual OKX wallet generated key is different from the key generated using the mentioned derivation path (https://github.com/okx/go-wallet-sdk/blob/main/crypto/bip32/bip32.go#L43 is used), also from https://www.exodus.com/support/article/1795-derivation-paths-in-exodus#other-derivation-paths mentions m/44'/501'/0'/0' is the derivation path, I tried it with no luck as well.

Could you please help update the documentation with the correct derivation path used for the Solana chain?

Thank you.

BItcoin Brc20 sendrawtransaction Error: -26 non-mandatory-script-verify-flag (Witness program hash mismatch)

I'm trying using this sdk to transfer inscriptions. When I try to use bitcoin-core cli to broadcast the generated tx data, an error is returned.

Net: Bitcoin Test Net

MyTxData:
01000000000101dff84afd95cd2b7e79b6296d40d758a3db9852374ff21c4677718e9d8cc5323b0100000000ffffffff022202000000000000225120977afe0a8654c13bdf7a33383d643c8f47809edb27f11d2520e697b3a8b5b902d586070000000000225120cac2695acccce6e39677275888d8e3f30d06ffcc983c6c044b5b359f8ffc847403405b6e9dd0a1110b74e05deb2c66861c379460f049c784f886bfedb82353bfef237548dd97c1ee3afb32134f95e250cc8e1250351641dabc48224491de80dad4267d20af2d240e6e2686473825bc9f455f2ecfa31da07d7129382693b94ca6f3d2f903ac0063036f7264010118746578742f706c61696e3b636861727365743d7574662d3800377b2270223a226272632d3230222c226f70223a227472616e73666572222c227469636b223a2273617473222c22616d74223a223130227d6821c1af2d240e6e2686473825bc9f455f2ecfa31da07d7129382693b94ca6f3d2f90300000000

Decode Transaction

{
    "addresses": [
        "tb1petpxjkkvennw89nhyavg3k8r7vxsdl7vnq7xcpzttv6elrlus36q2s72kp",
        "tb1pjaa0uz5x2nqnhhm6xvur6epu3arcp8kmylc36ffqu6tm8294hypq4dt2rl"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 369,
    "hash": "b49889343ce43f7958059ab3718649784b4741ac441d42933b48a75530304d61",
    "inputs": [
        {
            "addresses": [
                "tb1petpxjkkvennw89nhyavg3k8r7vxsdl7vnq7xcpzttv6elrlus36q2s72kp"
            ],
            "age": 2576585,
            "output_index": 1,
            "output_value": 494184,
            "prev_hash": "3b32c58c9d8e7177461cf24f375298dba358d7406d29b6797e2bcd95fd4af8df",
            "script_type": "pay-to-taproot",
            "sequence": 4294967295,
            "witness": [
                "5b6e9dd0a1110b74e05deb2c66861c379460f049c784f886bfedb82353bfef237548dd97c1ee3afb32134f95e250cc8e1250351641dabc48224491de80dad426",
                "20af2d240e6e2686473825bc9f455f2ecfa31da07d7129382693b94ca6f3d2f903ac0063036f7264010118746578742f706c61696e3b636861727365743d7574662d3800377b2270223a226272632d3230222c226f70223a227472616e73666572222c227469636b223a2273617473222c22616d74223a223130227d68",
                "c1af2d240e6e2686473825bc9f455f2ecfa31da07d7129382693b94ca6f3d2f903"
            ]
        }
    ],
    "outputs": [
        {
            "addresses": [
                "tb1pjaa0uz5x2nqnhhm6xvur6epu3arcp8kmylc36ffqu6tm8294hypq4dt2rl"
            ],
            "script": "5120977afe0a8654c13bdf7a33383d643c8f47809edb27f11d2520e697b3a8b5b902",
            "script_type": "pay-to-taproot",
            "value": 546
        },
        {
            "addresses": [
                "tb1petpxjkkvennw89nhyavg3k8r7vxsdl7vnq7xcpzttv6elrlus36q2s72kp"
            ],
            "script": "5120cac2695acccce6e39677275888d8e3f30d06ffcc983c6c044b5b359f8ffc8474",
            "script_type": "pay-to-taproot",
            "value": 493269
        }
    ],
    "preference": "low",
    "received": "2024-02-05T08:04:54.373936891Z",
    "relayed_by": "3.236.147.57",
    "size": 365,
    "total": 493815,
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 2,
    "vsize": 194
}

Error :
non-mandatory-script-verify-flag (Witness program hash mismatch) (code -26)

I hope I can get help to resolve this error :)

Bitcoin PSBT GenerateSignedBuyingTx Error: Invalid Schnorr signature

Got the following error return from RPC node after sending generated singed buying tx:

failed to parse tx hash, sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Invalid Schnorr signature)"}: max hash string length is 64 bytes

What I implemented different between psbt_tx_test.go is that I can not get the real seller's input (the privatekey part), so replaced the SellerSignatureIndex input to a fake one (also it should be replaced by the actual one from seller psbt). And it works for finalize and get raw transaction but get "Invalid Schnorr signature" error~

Anything I missed or misused？

Connect to wallets via chrome extension

Hello, I am implementing a Google plugin blockchain game that requires integration with the OKX wallet. I have reviewed a lot of materials, but I have not found a solution that can be implemented

Mld

请问什么时候开源Avalanche的相关签名代码呢

Inscribing BRC-20 Tokens in JavaScript

I am currently working on a project that involves integrating BRC-20 tokens into our platform using JavaScript. I am seeking assistance on how to inscribe BRC-20 tokens in JavaScript.

Could you please provide guidance or resources on how to inscribe BRC-20 tokens using JavaScript? Any code examples or documentation would be greatly appreciated.

Thank you for your time and support. I look forward to your response.

为什么不导出go-wallet-sdk/blob/main/coins/tron/tron.go newTransfer 等函数呢

请问这样做的用意是什么？

example doesn't work

eth.go example doesn't work

The pubkey obtained after converting the Solana private key exported from the OKX web3 wallet into a keypair is different from what is displayed in the web3 wallet

let main_keypair = Keypair::from_base58_string("exported from okx web3 wallet solana private key");
println!("pubkey:{}",main_keypair.pubkey().to_string()) // Different from the web3 wallet.
println!("priv_base58:{}", main_keypair.to_base58_string()) //Same as the web3 wallet.

TestReveal builder args question

Hi, I found in the TestReveal
The privatekey: 1790962db820729606cd7b255ace1ac5ebb129ac8e9b2d8534d022194ab25b37
And turn the privatekey into address is not same as following "tb1pmwus5lpxnnet6wcyqtevls07y7u8h5wun7q7p9jglk707y2czfnsdlqqjw"

Is there any relationship between the privatekey tb1pmwus5lpxnnet6wcyqtevls07y7u8h5wun7q7p9jglk707y2czfnsdlqqjw
And address argument?
tb1pmwus5lpxnnet6wcyqtevls07y7u8h5wun7q7p9jglk707y2czfnsdlqqjw

builder.AddInput("9f9ff5acc7b3966ccfc6acc77027209d62aab34e563a09180c58ef7296fca74b",
		1,
		"1790962db820729606cd7b255ace1ac5ebb129ac8e9b2d8534d022194ab25b37",
                  // not same as privatekey made by 1790962db820729606cd7b255ace1ac5ebb129ac8e9b2d8534d022194ab25b37
		"tb1pmwus5lpxnnet6wcyqtevls07y7u8h5wun7q7p9jglk707y2czfnsdlqqjw", 
		"1600",
		inscription,
	)

Update Tron.proto to the latest version

this proto go file is heavily outdated, some methods are deprecated or missing like FreezeBalanceV2
https://github.com/okx/go-wallet-sdk/blob/main/coins/tron/pb/Tron.pb.go

I am going to update it

cant find crypto.ra

C:\Users\Administrator\go\go1.21.10\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/Program Files/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lzks-crypto: No such file or directory
collect2.exe: error: ld returned 1 exit status

describe：but F:\Hy\go-wallet-sdk\coins\zksync\libs\libzks-crypto.a it in my libs

gcc：gcc.exe (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r5) 13.2.0
go: go 1.21.1

How do I get the appropriate feerate dynamically

inscribe_test, the estimatesmartfee command can get feerate, Do it need to be converted ?

request := &InscriptionRequest{
CommitTxPrevOutputList: commitTxPrevOutputList,
CommitFeeRate: 2,
RevealFeeRate: 2,
RevealOutValue: 546,
InscriptionDataList: inscriptionDataList,
ChangeAddress: "tb1pklh8lqax5l7m2ycypptv2emc4gata2dy28svnwcp9u32wlkenvsspcvhsr",
}

solana issue

在使用PrivateKeyFromBase58方法时，对传入私钥格式并没有进行检验，所以随意传入参数都可以进行base58进行解码。

Issue with Display of Decimal Token Approval Amounts in OKX Wallet

Issue Description:

When utilizing the OKX Wallet for token approval within transactions on the Goerli test network, I encountered an issue related to the display of decimal token approval amounts. Here's a detailed description of the problem:

Scenario:

I attempted to approve fractional token amounts (e.g., 1.3, 6.8, 10.4) for transactions using the wallet's approval functionality.
### Expected Behavior:
The wallet should accurately display the approved token amount, including both the whole number and fractional parts of the value.

Actual Behavior:

The wallet only displays the whole number portion of the decimal value (e.g., 1, 7, 11), omitting the fractional part.
This issue is specific to the token approval functionality within the wallet and arises only when approving tokens for another user via a smart contract. For instance, when dealing with decimal values like 1.1, the wallet displays the value as 1.

Steps to Reproduce:

Open the OKX Wallet.
Navigate to the token approval section.
Attempt to approve fractional token amounts (e.g., 1.3, 6.8, 10.4) for transactions using smart contract.
Observe that the wallet displays only the whole number portion of the value.

Expected Outcome:

The wallet should consistently display both whole numbers and decimal fractions in the approved token amounts for transactions, regardless of the input value.

Impact:
This issue disrupts the user experience when trying to approve fractional token amounts accurately for transactions. While there is a workaround involving manual customization, I believe the wallet's behavior should be consistent and intuitive, even when dealing with decimals.

test