Here are the definitions of these two types:

// big.Int
type Int struct {
    neg bool // sign
    abs nat  // absolute value of the integer

// hexutil.Big
type Big big.Int

This is my test code:

package main

import (


type TransactionData struct {
    Value  *hexutil.Big
    Vaule2 *big.Int

func main() {
    OneBig := (*hexutil.Big)(big.NewInt(1))

    data := TransactionData{
        Value:  OneBig,
        Vaule2: big.NewInt(2),

    encodedData, err := rlp.EncodeToBytes(data)
    if err != nil {
        fmt.Println("Failed to encode data:", err)

    decodedData := TransactionData{}
    err = rlp.DecodeBytes(encodedData, &decodedData)
    if err != nil {
        fmt.Println("Failed to decode data:", err)

    fmt.Println("equal:", reflect.DeepEqual(data, decodedData))
    fmt.Printf("expected: %+v\n", data)
    fmt.Printf("decoded: %+v\n", decodedData)


This is the output after executing the code:

equal: false
expected: {Value:0x1 Vaule2:+2}
decoded: {Value:0x0 Vaule2:+2}

  • I found that hexutil.Big is identified as a struct during encoding.
    – meta
    Jun 30, 2023 at 18:26

1 Answer 1


When executing rlp.EncodeToBytes, the big.Int and hexutil.Big have different processing logic:

  • For big.Int: it has a direct process logic, so it is encoded.
  • For hexutil.Big: it doesn't have a direct process logic. Instead, it is regarded as a struct that has neg and abs fields. However, it was found that neg and abs are not exported fields. As a result, these two fields are ignored during the encoding process.


The key point of the problem is that hexutil.Big is not treated as a big.Int that has direct processing logic, but rather as a struct with two non-exported fields that are ignored when attempting to encode them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.