eye.tread

Transparent read namespace for standard contract calls

The .tread namespace provides standard (non-encrypted) contract read operations using eth_call. Use this for public queries where privacy is not required.


Overview

When you call contract.tread.functionName(...), the SDK:

  1. Encodes your function call using the contract ABI

  2. Constructs a standard eth_call request

  3. Executes the call against the node's state

  4. Returns the raw result

No encryption is applied — calldata and results are visible to anyone observing the request.


Usage Pattern

result = contract.tread.functionName(arg1, arg2, ...)
  • Sync: Returns HexBytes immediately

  • Async: Returns HexBytes (must await)


Parameters

Function Arguments

Pass function arguments as positional parameters:

No Transaction Options

Unlike .read, .tread does not accept keyword arguments like value, gas, or security.

The call uses default parameters:

  • No value transfer

  • Reasonable gas limit (set by node)

  • No special security parameters


Examples

Sync Usage

Async Usage

Reading with Arguments

Multiple Return Values

Array and Struct Returns


Return Value

Returns HexBytes containing the raw ABI-encoded result.

Decoding Results

Results are raw ABI-encoded bytes. Use eth_abi to decode:


Key Limitation: No msg.sender

Standard eth_call does not prove your identity. The contract sees msg.sender as 0x0000000000000000000000000000000000000000.

Problem Example

With transparent read (.tread):

With signed read (.read):

When .tread Works

Use .tread when the contract function:

  • Does not check msg.sender

  • Is purely computational (no authentication)

  • Returns public data

Examples:

When .tread Fails

Use .read when the contract function:

  • Checks msg.sender for permissions

  • Returns caller-specific data

  • Has any access control

Examples:


Privacy Implications

What's Visible

Everything is visible:

  • Your IP address (to the node you're querying)

  • Contract address (what contract you're reading)

  • Function selector (which function you're calling)

  • All function arguments

  • The result returned

Example

The node (and anyone monitoring) can see:

  • You're checking the balance of 0x1234...

  • Which contract you're querying

  • The result (the balance amount)


When to Use .tread

Good Use Cases

  • Public data queries — Total supply, token name, public balances

  • No authentication needed — Function doesn't check msg.sender

  • Cost optimization — Free (no gas cost, no encryption overhead)

  • Public explorers — Block explorers, analytics, public dashboards

  • Testing — Quick tests where privacy doesn't matter

Examples


When NOT to Use .tread

Use .read Instead When

  • Function checks msg.sender

  • Caller-specific data is needed

  • Privacy is required

  • Access control is involved

Examples (Use .read for these)


Comparison with Other Namespaces

Namespace
Encryption
Proves Identity
Gas Cost
Use Case

.read

Encrypted

Yes (msg.sender is your address)

None

Access-controlled reads

.tread

No encryption

No (msg.sender is 0x0)

None

Public reads


Error Handling


Best Practices

When to Choose .tread

Checklist:

When to Choose .read

Checklist:

Common Mistakes

Mistake: Using .tread for caller-specific functions

Fix: Use .read to prove your identity


Async Patterns

Concurrent Reads

Read with Timeout


Standard Web3.py Behavior

The .tread namespace uses standard eth_call under the hood. All web3.py call features work:

Block Number

You can specify a block number (though not directly via .tread):


Low-Level Alternative

Direct eth_call:

The .tread namespace is more convenient as it handles ABI encoding automatically.


Performance

.tread is the fastest read method:

  • No encryption overhead

  • No signature computation

  • Direct eth_call to node

  • Can be cached/memoized easily

Use it for:

  • Public data that changes infrequently

  • High-frequency queries (price feeds, balances)

  • Analytics and dashboards


See Also

Last updated