Creating Boilerplate Transaction Messages/Data

Using One Simple Flag:

—generate-only`

Transaction templates form the foundation of blockchain development and automation in SHE. Through the --generate-only flag and Foundry’s cast tool, developers can craft, analyze, and debug transactions across both native Cosmos and EVM environments. Understanding these tools opens up powerful possibilities for building sophisticated applications and development workflows.

Native Transaction Templates

The --generate-only flag transforms any SHE CLI transaction command into a template generator, creating complete transaction structures without broadcasting them. These templates serve as building blocks for applications, frontends, and automation tools.

Basic Usage Pattern

The general pattern follows this structure:


shed tx <module> <action> <parameters> --from <key> --generate-only

For example, a token transfer template:


shed tx bank send \
  $(shed keys show sender -a) \
  $(shed keys show recipient -a) \
  1000000ushe \
  --from sender \
  --generate-only | jq

EVM Transaction Analysis

SHE’s EVM compatibility introduces additional complexity when working with transactions. Let’s explore how to generate and analyze EVM transactions using both SHE’s native tools and Foundry’s cast command.

Generating EVM Transaction Templates

To generate an EVM transaction template, use the evm module with --generate-only. Here’s an example registering an EVM pointer:


shed tx evm register-evm-pointer NATIVE \
  factory/she1ep3f207kt7julz9tjwxp2x8kluj0y9l6u0fume/gptw \
  --gas-fee-cap=100000000000 \
  --gas-limit=2500000 \
  --evm-rpc=https://localhost:8545 \
  --from tf \
  --generate-only

This command returns a transaction hash that you can analyze further using Foundry’s cast tool.

Analyzing EVM Transactions with Cast

Once you have a transaction hash, you can use Foundry’s cast command to inspect the transaction details:


cast tx 0x5010e6600e67f04a9bc3d3b670a7c2de380b180713d9a014a5dbd76b7e2190f1 \
  --rpc-url=https://localhost:8545

This provides detailed transaction information:


blockHash            0x4696d63a9a9ae88b03bcc94ccbd87f407e994b309d1dff9c0626de51ac57b76e
blockNumber          130076639
from                 0xAa55a16dD4E73c48C968928983c2bcC98d913d96
transactionIndex     7
effectiveGasPrice    100000000000
accessList           []
chainId              1329
gasLimit             2500000
hash                 0x5010e6600e67f04a9bc3d3b670a7c2de380b180713d9a014a5dbd76b7e2190f1
input                0xc31d960f0000...
maxFeePerGas         100000000000
maxPriorityFeePerGas 100000000000
nonce                3
r                    0x92313277d1ffad9a18260303081671a2d40035016ac83740486dee916c964db7
s                    0x158de03cac836b1fad26770274cffdb06b0809961811eb0b66aebfff95186417
to                   0x000000000000000000000000000000000000100b
type                 2
value                0
yParity              1

Understanding EVM Transaction Components

Let’s break down the key components of an EVM transaction:

input: The encoded function call data
maxFeePerGas: Maximum total fee per gas unit
maxPriorityFeePerGas: Maximum priority fee per gas unit
gasLimit: Maximum gas allowed for the transaction
to: Target contract address
type: Transaction type (2 indicates EIP-1559 transaction)

Practical Applications

Development Workflow

When developing applications that interact with both native and EVM functionality:


async function analyzeTransaction(txHash) {
  // First, get the native transaction details
  const nativeTx = await fetch(`${sheRestEndpoint}/cosmos/tx/v1beta1/txs/${txHash}`).then((res) => res.json());
 
  // If it's an EVM transaction, get EVM details
  if (nativeTx.tx.body.messages[0]['@type'].includes('evm')) {
    const evmTx = await fetch(`${evmRpcEndpoint}`, {
      method: 'POST',
      body: JSON.stringify({
        jsonrpc: '2.0',
        method: 'eth_getTransactionByHash',
        params: [txHash],
        id: 1
      })
    }).then((res) => res.json());
 
    return {
      native: nativeTx,
      evm: evmTx
    };
  }
 
  return { native: nativeTx };
}

Template Generation for Different Transaction Types

Generate templates for various transaction types:


# Native governance proposal
shed tx gov submit-proposal param-change proposal.json \
  --from validator \
  --generate-only > native_template.json
 
# EVM contract interaction
shed tx evm send-tx \
  --evm-rpc=http://localhost:8545 \
  --gas-limit=2500000 \
  --from=mykey \
  --generate-only > evm_template.json

Best Practices

Transaction Analysis

When analyzing transactions:

Always verify both native and EVM aspects of transactions
Use cast to decode input data when working with EVM transactions
Keep track of gas parameters across both layers
Monitor transaction status on both native and EVM layers

Error Handling

Handle potential issues across both layers:


try {
  // Check native transaction status
  const nativeStatus = await checkNativeStatus(txHash);
 
  // If native succeeded but EVM failed, investigate EVM layer
  if (nativeStatus.success) {
    const evmStatus = await checkEvmStatus(txHash);
    if (!evmStatus.success) {
      const evmError = await cast.call(['tx', txHash, '--rpc-url', evmRpcUrl]);
      console.error('EVM transaction failed:', evmError);
    }
  }
} catch (error) {
  console.error('Transaction analysis failed:', error);
}

Security

Keep private keys secure and never include them in templates
Use an .env file or other environment variable where possible when working with hard coded wallet keys or mnemonics