Smart contract

A smart contract is code that lives at a blockchain address and runs

when a transaction invokes it. On EVM chains the code runs in the Ethereum

Virtual Machine. On solana the equivalent is a

program, running in the Solana VM. On sui and

aptos contracts are Move modules. The general idea is the

same: deterministic, on-chain code triggered by signed transactions.

Deployed bytecode vs source

What actually lives at a contract address is bytecode, the

chain-specific machine code the VM executes. Source code (Solidity, Vyper,

Rust, Move, and others) is not stored on-chain by default. To make a

contract auditable, developers verify the source against the deployed

bytecode using a block explorer.

• On EVM chains, explorers such as the ones tx.taxi routes to for

ethereum, base, and

arbitrum one provide a "verify and publish"

workflow. The developer submits Solidity source, compiler settings, and

constructor arguments; the explorer compiles them and confirms that the

resulting bytecode matches the on-chain bytes.

• A verified contract page shows the source, the ABI, the compiler

version, and a "read" / "write" tab for interacting with functions

directly.

• An unverified contract still works on-chain. It just shows raw bytecode

on the explorer, which is far harder to inspect.

Read and write functions

Most contract function calls fall into two categories at the tooling level:

• Read functions (view or pure in Solidity) do not change state.

Explorers and wallets can call them locally against a node, with no

signature and no fee. They simply return computed values from current

state.

• Write functions are state-changing. Calling them requires a signed

transaction with a gas fee, and the result is a

transaction receipt that records status,

emitted events, and gas used.

Calls to a contract identify the function by a 4-byte selector

(keccak256("functionName(types)") >> 224 on EVM), followed by ABI-encoded

arguments. The explorer decodes both the input and the emitted events when

the ABI is available, which is why verification matters for

human-readable transaction pages.

The ABI

The ABI (Application Binary Interface) is a JSON schema describing a

contract's functions, events, and types. It lets clients encode calls and

decode responses without seeing the source. When a contract is verified,

the explorer publishes its ABI alongside the source. Tools, indexers, and

front-ends consume the ABI to make calls.

Contract addresses

A contract address is the same format as any other

wallet address on its chain. There is no

on-chain bit that labels an address as a contract; explorers detect it by

checking whether the address has deployed code. EVM contract addresses are

typically rendered using EIP-55 checksum

casing.

The address is determined deterministically at deployment time. On EVM

chains, a CREATE deployment computes the new address as

keccak256(rlp([sender, nonce])) truncated to 20 bytes; CREATE2 uses

keccak256(0xff || sender || salt || keccak256(initcode)).

Common gotchas

• A contract can be self-destructed or upgraded via proxies, so an address

showing one bytecode today may show different bytecode tomorrow. Always

check timestamps when auditing.

• Verifying source on one chain does not propagate to others. The same

bytecode redeployed on optimism must be verified

again on that chain's explorer.

• Reading a function on an unverified contract is still possible if you

know its 4-byte selector, but you lose the readable name and decoded

arguments.