Currently, cainome parser generates an intermediate representation of the ABI tokens.

This list of token can then be lowered in any language, example of rust done in the rs crate.

This issue can track the effort of typescript lowering for a contract bindings.

To ease the abigen use without depending on rust directly, having a binary for cainome can be great. The idea here is to provide a cainomeup script for quick and easy install.

Features:

1. Generate binding for a given backend from a Sierra class file JSON file.
2. Generate binding for a given backend from a contract address and a rpc url, to have cainome binary fetching the ABI from the chain to generate the bindings.
3. Specify the backend (only rust is available for now).

Examples (arbitrary names that can be changed):

cainome gen --sierra my_contract.contract_class.json --rust /tmp/my_contract.rs
cainome gen --address 0x1234 --rpc-url https://sepolia... --typescript /tmp/my_contract.ts

Cairo 0 still very present in term of on-chain contract already deployed on mainnet.

The main difference between cairo 1 and cairo 0 for abigen are those three:

1. Arrays: serialized array in cairo 1 always have the length of the array as the first felt. In cairo 0, the len is always passed as a separate argument. Hence, the serialization/deserialization of cairo 0 array must behave differently.
2. The output of a function in cairo 1 is always 0 or 1 output. In cairo 0, we can have a tuple. This must be handled.
3. Finally, the events are different in the ABI for Cairo 0. This is something that must be considered.

To add the cairo 0 support to cainome, some work from archived abigen repo could be done here:

1. a new macro abigen_legacy! can be used
2. The parser must parse a legacy ABI with old types, example of how the types were used in the archived repos is here.
3. Finally, the built-in array serialization must be adjusted in the rs crate. In the archived repo, we used a new type CairoArray as the implementation of CairoSerde for Vec is already done with cairo 1 logic.

To ease the deployment of a contract instance, the generated Contract type may expose a deploy function.

abigen!(MyContract, "/path/sierra.json");

fn main() {
    // init provider and account

    let contract_address = MyContract::deploy(...args).await?;
}

The deploy arguments are automatically generated based on the constructor of the contract.

To deploy, we need the class hash. It can be computed compiling the Sierra class, or by taking the Casm class as optional argument.

The deployment is done by the UDC (we may name this function deploy_udc actually), and the parameters of the UDC may be exposed.

The fees must be configurable. We also want to check if the class hash is already declared. If not, we can skip the deploy with an error.

In the code, this is located in the rs crate here where a new file may be added for this, to be expanded in the contract type here.

To ease the declaration of a class, the generated Contract type may expose a declare function.

abigen!(MyContract, "/path/sierra.json");

fn main() {
    // init provider and account

    let class_hash = MyContract::declare(...args).await?;
}

There are two possible strategies:

1. Taking only the Sierra class as input, but this enforce to re-compile the CASM class to compute the class hash (simpler interface).
2. We can accept the CASM class as optional parameter, to have the hash out of the box (faster).

Example for the declare can be taken here on Starkli.

The fees must be configurable. We also may want to check if the class is not already declared, to accelerate the process in the case it is.

In the code, this is located in the rs crate here where a new file may be added for this, to be expanded in the contract type here.