Encoding, signing, and submission
Clients submit an Intelligent Contract request through an Ethereum-compatible transaction. The outer transaction uses standard EVM signing and serialization; its calldata contains the GenLayer-specific deployment or method call and fee configuration.
Submission layers
- The client encodes the Intelligent Contract method and arguments in the GenLayer call format.
- It packages that data and the protocol fee configuration into a call to the Ghost or consensus contracts.
- The caller signs the outer EVM transaction with its account key.
- The client serializes and sends the signed transaction through
eth_sendRawTransaction. - When the EVM call is included, the consensus contracts create the GenLayer transaction and emit its ID.
The SDK and CLI perform these steps for normal application code. Use their high-level deployment and write methods instead of constructing consensus calldata by hand.
Two identifiers and two receipts
The outer EVM transaction has an EVM transaction hash and receipt. The created Intelligent Contract transaction has a protocol transaction ID and consensus receipt. Do not assume that the two identifiers or their success fields are interchangeable.
- The EVM receipt tells you whether the submission call executed on GenLayer Chain.
- The GenLayer receipt tells you how Intelligent Contract consensus progressed and which execution result finalized.
Signing safety
Signing proves authorization for the EVM transaction, including its destination, value, calldata, nonce, gas settings, and chain ID. Before asking a wallet to sign, a client should show the network, recipient, value, and expected action. Never transmit or log the caller's private key.
For current code, use GenLayerJS write calls, Intelligent Contract deployment, and the node RPC reference.