nethermindeth / starknet.go

Golang Library for StarkNet/Cairo

Get the gopher Starkpilled

⚠️ starknet.go is currently under active development and is experiencing a rearchitecture. It will undergo breaking changes.

starknet.go will get your golang backends and WASM frontends to Starknet easily. With simple abstractions for the Starknet RPC, account management and common operations on the wallets. The package has excellent documentation for a smooth 0 to 1 experience.

🌟 Features

• Seamless interaction with the Starknet RPC
• Tight integration with Juno
• Account management: Deploy accounts easily
• Good concurrency support

Getting Started

• library documentation available at pkg.go.dev.
• simple call example to make a contract call to a mainnet contract
• deploy account example to deploy a new account contract on testnet.
• invoke transaction example to add a new invoke transaction on testnet.

Run Examples

starknet simpleCall

cd examples/simpleCall
go mod tidy
go run main.go

Check here for more details

starknet deployAccount

cd examples/deployAccount
go mod tidy
go run main.go

Check here for more details

starknet invokeTransaction

cd examples/simpleInvoke
go mod tidy
go run main.go

Check here for more details

RPC

starknet.go RPC implements the Starknet RPC v0.7.0 spec

Method	Implemented (*)
starknet_getBlockWithReceipts	✔️
starknet_getBlockWithTxHashes	✔️
starknet_getBlockWithTxs	✔️
starknet_getStateUpdate	✔️
starknet_getStorageAt	✔️
starknet_getTransactionByHash	✔️
starknet_getTransactionByBlockIdAndIndex	✔️
starknet_getTransactionReceipt	✔️
starknet_getTransactionStatus	✔️
starknet_getClass	✔️
starknet_getClassHashAt	✔️
starknet_getClassAt	✔️
starknet_getBlockTransactionCount	✔️
starknet_call	✔️
starknet_estimateFee	✔️
starknet_estimateMessageFee	✔️
starknet_blockNumber	✔️
starknet_blockHashAndNumber	✔️
starknet_chainId	✔️
starknet_syncing	✔️
starknet_getEvents	✔️
starknet_getNonce	✔️
starknet_addInvokeTransaction	✔️
starknet_addDeclareTransaction	✔️
starknet_addDeployAccountTransaction	✔️
starknet_traceTransaction	✔️
starknet_simulateTransaction	✔️
starknet_specVersion	✔️
starknet_traceBlockTransactions	✔️

Run Tests

go test -v ./...

Run RPC Tests

go test -v ./rpc -env [mainnet|devnet|testnet|mock]

Run Benchmarks

go test -bench=.

Compatibility and stability

🤝 Contribute

We're always looking for passionate developers to join our community and contribute to starknet.go. Check out our contributing guide for more information on how to get started.

📖 License

This project is licensed under the MIT license.

See LICENSE for more information.

Happy coding! 🎉

Contributors ✨

Thanks goes to these wonderful people (emoji key):

drspacemn 💻	Gregory Guillou 💻	Tarrence van As 💻	Alex Sumner 💻	Yun 💻	Zoraiz Mahmood 💻	Lucas @ StarkWare 💻
Coburn 💻	Larko 💻	oxlime 💻	Blaž Hrastnik 💻	Florian 💻	greged93 💻	Jean-Sébastien Ney 💻
Kristijan Rebernisak 💻	Rian Hughes 💻	Carmen Irene Cabrera Rodríguez 💻	Josh Klopfenstein 💻	Antonio Quental 📖	Jelilat Anofiu 💻	Jorik Schellekens 📖
Akashneelesh 💡	Fico 💻	Bitcoinnoobie 💻	stranger80 💻	omahs 📖

This project follows the all-contributors specification. Contributions of any kind welcome!

starknet.go's Issues

add support for Universal Deployer Contract (UDC)

Deploying a contract has changed and now require we go through UDC and AddInvokeTransaction. The conversation on starknet shamans details it. In addition, the UDC implementation is available on openzeppelin Cairo contracts. We should:

• deploy a test contract through UDC on devnet
• add the associated tests on rpc02
• add a utility to manage those with the account

add support and test for `devnet` with the RPC API

Objectives

devnet can be used as a local configuration to speed-up tests. From its documentation, it supports the RPC API. The objectives of this issue are to populate the set of tests for the rpc directory so that they work with devnet. If the exact same configuration cannot be used because devnet is empty when starting, adapt the tests so that every rpc method are tested.

Acceptance criteria

• every API call from the rpc directory should be implemented on devnet, except for those that are not supported yet

Additional Notes

We would need #78 to be implemented before

Calling `account.EstimateFee` with the gateway API + TX version 1 fails on testnet

Gateway returns 500: StarkErrorCode.MALFORMED_REQUEST Transaction of version 1 is expected to contain the 'type' field.

Code looks like this:

 // create new account
account, err := caigo.NewGatewayAccount(privKey, sender.String(), &txm.client.Gw.Gateway, caigo.AccountVersion1)
if err != nil {
	return txhash, errors.Errorf("failed to create new account: %s", err)
}

// get fee for txm
feeEstimate, err := account.EstimateFee(ctx, txs, caigotypes.ExecuteDetails{})
if err != nil {
	return txhash, errors.Errorf("failed to estimate fee: %s", err)
}

Same call succeeds on starknet-devnet.

Potential bug on the payload sent by the gateway

Hello, I'm facing a strange behaviour with the gateway.Deploy function and I think that it might be a bug.
Caigo version : v0.3.1-0.20220810165710-06e091c57d1c
Cairo version : 0.9.1

Context

I have to deploy an account and an ERC20 contract. The account is an OpenZeppelin account and the erc20 has been created with OpenZeppelin wizard for cairo. See the reproduce section to find the files.

All following instructions have been made with devnet.

Contract

The ERC20 contract has the following constructor.

@constructor
func constructor{
        syscall_ptr: felt*,
        pedersen_ptr: HashBuiltin*,
        range_check_ptr
    }(owner: felt, init_val: Uint256):
    ERC20.initializer('MyToken', 'MTK', 18)
    Ownable.initializer(owner)
    ERC20._mint(owner, init_val)
    return ()
end

The code to deploy the contract is the following:

erc20Response, err := gw.Deploy(context.Background(), compiledERC20Contract, types.DeployRequest{
		Type:                gateway.DEPLOY,
		ContractAddressSalt: "0x30a9f5025c1321d78b4027cf28d02014a0319eddcffc7e63319e3ac0b1f0bb1",
		ConstructorCalldata: []string{
			caigo.HexToBN("0x57ecd15c8010362e71eff8ac7d3db6213478e7b1701662321f1409eeaf4720c").String(), // owner
			"2000", // initial supply
			"0",    // Uint256 additionnal parameter
		},
	})

The bug

When I execute the code and retrieve the transaction status , the following error occur

{
    "tx_failure_reason": {
        "code": "TRANSACTION_FAILED",
        "error_message": "/usr/local/lib/python3.9/site-packages/starkware/starknet/common/storage.cairo:14:5: Error at pc=0:123:\nGot an exception while executing a hint.\nCairo traceback (most recent call last):\nerc20_custom.cairo:13:6: (pc=0:1212)\nerc20_custom.cairo:20:5: (pc=0:1200)\n/usr/local/lib/python3.9/site-packages/openzeppelin/token/erc20/library.cairo:243:34: (pc=0:885)\nautogen/starknet/storage_var/ERC20_balances/impl.cairo:17:30: (pc=0:602)\n        let (storage_addr) = addr(account)\n                             ^***********^\nautogen/starknet/storage_var/ERC20_balances/impl.cairo:10:21: (pc=0:593)\n        let (res) = normalize_address(addr=res)\n                    ^*************************^\n\nTraceback (most recent call last):\n  File \"/usr/local/lib/python3.9/site-packages/starkware/starknet/common/storage.cairo\", line 19, in <module>\nAssertionError: normalize_address() cannot be used with the current constants."
    },
    "tx_status": "REJECTED"
}

The error is thrown because of the ERC20._mint(owner, init_val) line.

I have succeed to deploy the contract with the starknet cli with the following command:

starknet deploy --contract ./erc20_custom_compiled.json --inputs 3050685483626767347100669678201776352238010600176252122452604515121233812834 2000 0 --gateway_url http://localhost:5050 --feeder_gateway_url http://localhost:5050 --no_wallet

So it seems that it is only with the gateway.Deploy function that this error occur.

Note

I have tried to remove the ERC20._mint(owner, init_val) line and to mint after the deployment. The contract deployment has succeeded BUT the same error was thrown on the mint function call.

Payloads

I have intercepted both payloads (CLI and caigo) and I found some differences:
Caigo miss those fields

• empty inputs
• some data fields
• empty keys fields
• empty outputs fields
• contract version

Content-type of requests are different too
Caigo : application/json; charset=utf
CLI : text/plain; charset=utf-8

Reproduce the bug

You can find the complete example and all files at FlorianRichardSMT/caigo-bug

Support for RPC v0.2

I tried using v0.1 but starknet-devnet only implements v0.2. The biggest difference seems to be starknet_getNonce and a couple other methods now also take an additional block_id parameter.

starkware-libs/starknet-specs@v0.1.0...v0.2.1

feat: SN v0.9.0 support

• fee estimate
• fee paying
• 'declare' support
• contract class/contract class hash

GetSelectorFromName called twice

account.go Execute function calls GetSelectorFromName on entry point selector and sends tx to invoke in starknet.go which does the same.

feat: take ctx for network requests

we should consider taking a context as parameters to network requests so the caller can manage its lifetime

capture RPC API payload and better track changes

Objectives

A challenge with the current status of the API is that it might change without notice. With this issue what we propose is:

• create a mecanism to capture the payload for RPC events and keep them in the repository. Think snapshot testing with UI as described in the jest documentation
• provide a simple tool to DeepCompare, for instance with reflect, snapshot and new payload. This way, we could detect when changes happening,

Acceptance Criterias

We should have a set of test to cover every call on testnet with JSON RPC. Once done, we should:

• be able to capture the API calls and store them in the repository
• be able to remove some data from the capture and payload, like the Nonce and Signature on Invoke
• be able to replay a test and compare the payload with the one captured
• be able to fail the CI if some change happens that would break the contract

Additional Notes

To be implemented, we would need #78 to be implemented so that we have a reliable set of tests

Add support for RPC v0.2 addInvokeTransaction

The API definition for addInvokeTransaction has changed between RPC v0.1 and v0.2 as seen in the latest specification. We should:

• add support for the new definition in rpcv02
• add a test with devnet
• integrate rpcv02 with the account
• add test with the account on the devnet

TestLocalStarkNet 403: unknown_error_format

I'm observing that local starknet tests fail. Is it possible there are additional setup instructions needed in the README?

=== RUN   TestLocalStarkNet
    starknet_test.go:86: Could not deploy contract: 403: unknown_error_format
    starknet_test.go:91: Could not get tx: 403: unknown_error_format
    starknet_test.go:96: Could not get tx receipt: 403: unknown_error_format
    starknet_test.go:101: Could not get block by hash: 403: unknown_error_format
    starknet_test.go:106: Could not get storage: 403: unknown_error_format
--- FAIL: TestLocalStarkNet (1.55s)

overflow for the value of key in (Gateway) `get_storage_at`

https://github.com/oxlime has made some tests on the gateway and reported an error in the type for key in the implementation of get_storage_at in the gateway. key is a uint64, yet, the value in the API can be larger than 64bits, see this line in gateway/storage.go

The reported issue is the following:

1. get_storage_var_address("erc20_crystal_address") is 475322019845212235330707245667153666023074534120350221048512561271566416926 which is obviously >64 bits
2. the following query succeed:

curl https://alpha4.starknet.io/feeder_gateway/get_storage_at?contractAddress=0x035401b96dc690eda2716068d3b03732d7c18af7c0327787660179108789d84f&key=475322019845212235330707245667153666023074534120350221048512561271566416926&blockNumber=281263

# "0x14a7a59e3e2d058d4c7c868e05907b2b49e324cc5b6af71182f008feb939e91"

Should we simply provide the key for now (i.e. base10 number as a string) or should we provide some abstraction as part of the API?

Plans for adding support for signTypedData/signMessage

👋 I'm David from ImmutableX, while we are planning to support StarkNet for ImmutableX's multi-rollup Orderbook, we noticed that off-chain signing & verification is a hard dependency.
Although these features are already supported in other languages like JS & Cairo I see that Caigo seems to only support the basic Account.Sign() as of now.

Do you have any plans to support this in the near future? This seems to be a need for many other projects as well since this is a frequently used functionality.

Also, does anyone know any case or example/implementation of signTypedData or signMessage in Golang?

Add support RPC v0.2.x addDeclareTransaction

Declaring a class is now changed with fees and the RPC v0.2 write specification now include those changes. We should implement this new requirements

add mock tests for the whole JSON RPC API

Objectives

The JSON RPC API is well implemented. However, not all the routes have their dedicated tests. Make sure we implement those tests with a mock to ease the test process.

Acceptance criteria

• every API call from the rpc directory should be implemented with a mock

Additional Notes

#78 should be addressed first to make sure we correctly capture the payload

Bug: RPC Account WaitForTransaction never ends if transaction fails due to missing fees

I attempted to submit a transaction in the following two scenarios:

1. Fee added to execute payload but not enough balance -> Resulted in WaitForTransaction never-ending
2. No fee added to execute payload -> Resulted in WaitForTransaction never-ending

I was only able to figure out this was the issue as Starkscan shows when a TX is rejected due to no fee https://testnet.starkscan.co/tx/0x0018390ddc369f8c5bf66d94aa665df38e750f9b44c394e27e10a4a02e917715#overview

Voyager doesn't present this information.

If Starkscan is able to programmatically catch this scenario, then I'm sure there must be modifications we can make to Caigo to do the same.

build better tests with RPC API on mainnet

There are several reason why tests on mainnet are limited for now:

• addInvokeTransaction requires a account that is charged
• Only whitelisted contracts can be registered with addDeclareTransaction and addDeployTransaction

Figure out a way to test on mainnet without loosing funds amd make sure we know what contracts/class we can use to test the deployment of contracts.

code generator that would work like ethereum `abigen` for starknet

it would be really useful to support generating typed bindings similar to go-ethereums abigen. take a contract abi and generated a typed interface for calling it

Gateway Declare return StarkErrorCode.MALFORMED_REQUEST 'version'

I tried declare starknet contract .

func TestSync(t *testing.T) {
	gw := gateway.NewClient(gateway.WithChain(gateway.GOERLI_ID))

	ctx := context.Background()
	var contractClass types.ContractClass

	compiledContract, err := os.ReadFile("/Users/mohaijiang/tmp/my-starkware-erc20-1/cairo-project/ERC20.cairo.starknet.output.json")

	err = json.Unmarshal(compiledContract, &contractClass)

	if err != nil {
		assert.NoError(t, err)
		return
	}

	declare, err := gw.Declare(ctx, contractClass, gateway.DeclareRequest{})
	if err != nil {
		assert.NoError(t, err)
		return
	}

	fmt.Println("declare.TransactionHash: ", declare.TransactionHash)
	fmt.Println("declare.ClassHash: ", declare.ClassHash)

	_, receipt, err := gw.WaitForTransaction(ctx, declare.TransactionHash, 3, 10)
	if err != nil {
		assert.NoError(t, err)
		return
	}

	fmt.Println(receipt)
}

But fail.
The test result is

=== RUN   TestSync
    contract_test.go:63: 
        	Error Trace:	/Users/mohaijiang/IdeaProjects/blockchain/a-line/pkg/service/contract_test.go:63
        	Error:      	Received unexpected error:
        	            	500: StarkErrorCode.MALFORMED_REQUEST 'version'
        	Test:       	TestSync
--- FAIL: TestSync (5.39s)

I use github.com/dontpanicdao/caigo v0.4.1

How can I declare success？

Remove v0 account contracts from the repository

We should remove contract that are not compatible with starknet anymore

Deploy account under example folder is inapplicable on main branch

Multiple problems after Starknet upgrade

After the recent upgrade, multiple functionalities seem to be broken.

• Fee estimation always throws an exception.
• Transactions that are sent with non-upgraded wallets are rejected.
• When I try to send a tx with a upgraded wallet, I always get entrypoint not found error on wallet contract itself(not the target contract).

Code was working a week ago. Only thing changed is starknet itself. I can help to investigate if needed.

Implement tests for the whole Gateway API on testnet

Objectives

The Gateway API is fully implemented. However, not all the routes have their dedicated tests. Make sure we implement those tests with on testnet and it is added to the CI

Acceptance criteria

• every API call from the gateway directory should be implemented on testnet

You should be able to test it from your laptop/desktop and it would pass the CI. To do it, run:

cd gateway
go test -v -env testnet .

Additional Notes

add support for AddDeployAccountTransaction with RPC v0.2.x

Deploying an account contract has changed and requires fees. the RPC v0.2 write specification now include those changes. We should implement this new requirements and:

• provide the associated implementation with rpc v0.2
• add a test for demontration
• extend the account API to allow those deployment
• add a test

organize the RELEASE note

Improve the development process so that it becomes easy to build a release note:

• we might want to rely on PR templates
• we could see if the GH release note generator could help
• we might also come with goreleaser especially if we plan to provide an artifact to generate code (i.e. abigen)
• we could consider using a squash and merge strategy to have a clean commit history (there are cons but it make things more readable and, assuming we remain on GH, we can still find the commits)
• we might build a project board with milestones and have a 15 min meeting every 2 weeks for instance

500: StarknetErrorCode.ENTRY_POINT_NOT_FOUND_IN_CONTRACT Entry point 0x1ac47721ee58ba2813c2a816bca188512839a00d3970f67c05eab986b14006d not found in contract

Your help is appreciated. Thanks.

Add support for plugin account

We should support the v1 plugin account with RPC v0.2.x and Gateway as part of caigo

Add starknet v0.10.2 support with the Gateway provider

The Gateway provider should now support the same features as the RPC providers, i.e:

• declare a contract with fees
• deploy a contract with UDC
• deploy an account with the DeployAccount syscall
• declare v1 transactions with the nonce from the protocol

We should provide the associated implementation in the Gateway provider, add the associated tests and implement the provider as part of the account and utilities

Should Field `ChainId` in `Domain` be `*big.Int` or `string` instead of `int`?

Hello, everyone. I am building a TypedData in order to call GetMessageHash and generate a hash based on this data and an account address.

However, the field ChainId in Domain is an int:

type Domain struct {
	Name    string
	Version string
	ChainId int
}

Shouldn't it be *big.Int?

The reason is that the currently Starknet/Starkware values for the Mainnet/Testnet are as follows:

• Testnet (SN_GOERLI): 1536727068981429685321 or 0x534e5f474f45524c49
• Mainnet (SN_MAIN): 23448594291968334 or 0x534e5f4d41494e

These values overflow an int. Testnet and Mainnet are 71 bits and 55 bits long respectively. How can I build a well-formed TypedData.Domain with the proper values for ChainId ?

I can't complete the transfer, the deployment of the ERC20 contract will fail

position: examples/deploy/main.go
1.Deploy an OpenZeppelin account
2.Deploy an ERC20 contract
3.Mint the ERC20 contract
4.Transfer tokens from the deployed account to a third-party account

I only completed the first step, all others failed.
Hope someone can provide a demo that can run the transfer successfully

issue with Uint256 type and/or SplitFactStr

I'm using Uint256 for ERC721 with Starknet and there is no direct support for that type in caigo. I do not know if that is something I should/could add, considering I'm also an adept of less is better. Uint256 is actually defined in the abi, maybe having an abigen as referenced in #1 would work better.

In the meantime, I am using SplitFactStr to convert the Uint256 into 2 Felt. I would like for the function to work even when the strings are shorter than 32-bytes. I've written a PR with the test that with the current code and succeed with the change. Can you review the PR and provide some feedback?

Thank you for the project!

add tests for `estimateFee` and `addInvokeTransaction` on testnet

So far, those 2 methods do not have tests for the testnet. Make sure you can add tests for each one of them.

fix the public key computation to improve signatures

A PR has been provide to secure signature. However, it breaks the public key computation. We should fix that PR

How to convert Ethereum private key to stark private key？

The path for `pedersen_params.json` is broken.

https://github.com/dontpanicdao/caigo/blob/9b016d75d4eb4dbe98a1a124edb4396daa693979/curve.go#L111

The correct path should be:

https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/crypto/signature/pedersen_params.json

encodeProgram returns a different value from the official starkware implementation

this json file

{
    "a": "b"
}

when compressed with encodeProgram:
H4sIAAAAAAAA/8orzckBBAAA//9P/MslBAAAAA==

When compressed with https://github.com/starkware-libs/cairo-lang/blob/13cef109cd811474de114925ee61fd5ac84a25eb/src/starkware/starknet/services/api/gateway/transaction_utils.py#L10
H4sIAHlM9mIC/6tWSlSyUlBKUqoFADkMCakKAAAA

add mock tests for the whole Gateway API

Objectives

The Gateway API is fully implemented. However, not all the routes have their dedicated tests. Make sure we implement those tests with a mock to ease the test process.

Acceptance criteria

• every API call from the gateway directory should be implemented with a mock

Additional Notes

#77 should be addressed first to make sure we correctly capture the payload

Unmarshalling compiled Cairo code into `ContractClass` fails

Hey team. ContractClass expects a type string, but compiled Cairo Code outputs the "program" as an object. I need to do this because I want to deploy a contract using the JSON RPC

type ContractClass struct {
	// Program A base64 representation of the compressed program code
	Program string `json:"program"`

	EntryPointsByType EntryPointsByType `json:"entry_points_by_type"`

	Abi *ABI `json:"abi,omitempty"`
}

This means when I try to do something like this:

	compiledFile, err := os.Open(compiledERC20Path)
	assert.NoError(t, err)
	parser := json.NewDecoder(compiledFile)
	contractClass := caigorpctypes.ContractClass{}
	err = parser.Decode(&contractClass)
	assert.NoError(t, err)

It fails with the JSON object as in this pastebin, which is the compilation result of a minimal Cairo program of simply %lang starknet : https://pastebin.com/UmmxGMze .

The "program" part is an object, not a string and hence fails to Unmarshal. It fails with the error:

json: cannot unmarshal object into Go struct field ContractClass.program of type string

Any tips on resolving this would be great

run nightly tests with mainnet, testnet and devnet

A nightly test should now be scheduled:

• check it is the case
• provide the necessary components so that the project can run nightly on those 3 environments mainnet, testnet and devnet
• make sure we get notified when the tests fails. For instance we could notify the caigo discord channel

Move all the API to Felt

Objective

This issue is consists in migrating all the API (Gateway and RPC) AND the tests so that it relies on Felt

Acceptance Criteria

• the types (structs and function parameters/output)
• all the interfaces should be tested and passing the tests when implemented

Do bot hesitate to slice the issue in 2 (1) for the gateway and (1) for RPC. If that is the case, we will merge on a feature branch.

Additional Notes

A next issue will attempt to turn the Felt implementation, if possible, into an interface that can be shared with consensys/gnark-crypto.Felt

Remove RPC v0.1 and the associated tests

RPC v0.1 should not be used anymore as a result, we should:

• Label a version 0.5.0 with RPC v0.1
• Remove RPC v0.1 from the tests and implementation of the account
• Label a version 0.5.0 without RPC v0.1

feat: support user provided http.Client

currently caigo.NewGateway initialized a http.Client internally. it would be great to expose a way for the consumer to provide a client, since it is often desirable to configure the client

Uint256 Examples Ignores 'High' field

Not sure if Caigo maintainers here but the example given in Caigo for balanceOf ignores the 'high' result for Uint256. See https://github.com/dontpanicdao/caigo/tree/main/examples/deploy
This is not a good idea as the high field could have a value. In JS, Immutable X does it like this https://github.com/immutable/imx-cairo/blob/main/tests/utils/starknetUtils.ts#L31

I'll look into making a PR if I have a capacity.

Implement tests for the whole JSON RPC API on testnet

Objectives

The JSON RPC API is fully implemented. However, not all the routes have their dedicated tests. Make sure we implement those tests with on testnet and it is added to the CI

Acceptance criteria

• every API call from the rpc directory should be implemented on testnet

Additional Notes

Feature: Add Support for Devnet Mint and Mint Lite

The Shardlabs devnet allows for minting to an address using the local faucet -> https://github.com/Shard-Labs/starknet-devnet#mint-token---local-faucet

This is necessary when the deployed and funded accounts are not sufficient (e.g. wrong account contract).

It would be great to start adding support for devnet-specific functionality such as this.

Provision starknet v0.10.1 compatible account contracts

Account contracts v1 are required to work with the latest protocol. Those contracts require __validate_declare__ and __validate_deploy__ entrypoints. We should add those contract to the projects to allow to build new test-cases that allows to deploy contracts for testing

devnet returns HTTP-500 when there is no param in the RPC call

When running Caigo with devnet with calls that do not have parameters, like starknet_protocolVersion, the JSON RPC implementation of go-ethereum, send the following payload:

{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "starknet_protocolVersion"
}

That makes sense since there is no parameters, however, devnet and opposite to pathfinder fails with HTTP-500. We need to get the following payload:

{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "starknet_protocolVersion",
    "params": []
}

An ASSERT_EQ instruction failed

When I deploy account, the status is RECEIVED, and then changed to Rejected. The error shows
'Error at pc=0:103:
An ASSERT_EQ instruction failed: 10:0 != 10:1.'

deploy and rely on the OZ account on testnet

Objective

Provide an example that deploys the (1) Openzeppelin account; (2) a ERC20 contract ; (3) mint ERC20 and (4) perform the transfer of a token to a 3rd party account with an Invoke

Success Criteria

You might execute it with the Gateway API for now; you will need to be able:

• To deploy an account from Go (you should compile it first with the starknet CLI)
• To deploy an ERC20 contract from Go
• To document how to provide some ETH to the contract
• To mint the ERC20 from Go
• To Transfer some tokens to a separate account

Additional notes

If you prefer to use the JSON RPC api, you might. However, there might be some missing pieces still, including the starknet_getNonce.

organize and publish a better documentation

A first step would be to propose how to improve the documentation and where to publish it:

• obviously caigo being a SDK, we should focus on the godoc first
• we should propose a set of separated REAME-like to include the main subjects and feed them.