The Ledger of Things Now Supports Ethereum Smart Contracts

The Ledger of Things (LoT) has taken a major step forward: it is now EVM compatible. This means developers can run unmodified Ethereum smart contracts — written in Solidity — directly on LoT, bringing together the strengths of Ethereum’s smart contract ecosystem and LoT’s powerful objects authentication feature (3DPRC2 standard).

What Does EVM Compatibility Mean?

EVM stands for Ethereum Virtual Machine, the runtime environment that executes Solidity smart contracts on Ethereum. By integrating a customized EVM layer using the Frontier, LoT now allows developers to:

• Deploy and run Ethereum-native contracts on LoT
• Interact with LoT’s native tokens and assets through familiar Solidity code
• Use Ethereum tools like MetaMask to access and interact with the LoT blockchain

This new capability unlocks LoT for Ethereum developers without the need to learn or rewrite code in Rust. It is designed to closely emulate the functionality of executing contracts on the Ethereum mainnet within LoT.

Custom precompiled contracts

LoT’s EVM environment goes beyond simple compatibility. It features a unique set of custom precompiled contractsthat act as bridges between Ethereum and LoT’s native runtime. These allow Solidity contracts to interact with features traditionally exclusive to Substrate based LoT runtime modules, such as:

• balances-erc20 — P3D (native) token access via ERC-20 interface
• assets-erc20 — Local asset support via ERC-20 interfaces
• Batching and proxy modules for advanced logic

📦 P3D Token Interaction (via balances-erc20)

LoT’s native token, P3D, exists in the native runtime — but it can be used like an ERC-20 token in Solidity thanks to the balances-erc20 precompile.

• P3D precompile contract address:
  0x0000000000000000000000000000000000000802
• Developers can use the standard IERC20 interface: IERC20 p3d = IERC20(0x0000000000000000000000000000000000000802); p3d.transfer(recipient, amount);
• No deployment is needed — just point your Solidity contract to that address.

🪙 Interacting with Local Assets (via assets-erc20)

Local assets created via the poscanAssets module — such as 3DPRC2 share tokens — can also be treated like ERC-20 tokens in Solidity.

LoT precompile addresses for each asset, using the following formula:

Let’s say we’ve created an asset called COW with assetID = 16 (decimal = 10 hex).
Then, the EVM address is:

Precompile Address = 0xFBFBFBFA + assetID (in hex)

Example:
Let’s say we’ve created an asset called COW with assetID = 16 (16 decimal = 10 hex).
Then, the EVM address is:

0xFBFBFBFA00000000000000000000000000000010

You can use the IERC20 interface on this address in Solidity just like any Ethereum token:

IERC20 cow = IERC20(0xFBFBFBFA00000000000000000000000000000010);
cow.transfer(user, 1000);

This approach was first introduced by Moonbeam, which gives full Solidity-level control over assets that are not even issued inside the EVM.

🔐 Address & Key Mapping: Bridging H256 and H160

One of the challenges of combining Ethereum and Substrate ecosystems is address compatibility. Ethereum uses shorter H160 addresses, while Substrate’s native format isH256.

Mapping Native (H256) to EVM (H160)

The logic here is straightforward: the system derives the EVM-compatible address by truncating the 32-byte native public key to the last 20 bytes. This means a user with a native LoT address can also control the corresponding EVM address.

Example:

• Native account H256:
  0xc6006fea43ccce14f9432f8e6b9403113c935cc17160cd438af2e7a02624124c
• Mapped EVM address H160:
  0xc6006fea43ccce14f9432f8e6b9403113c935cc1

This allows users to manage both native and EVM accounts from the same key pair.

Mapping EVM (H160) to Native (H256)

Since H160 addresses are shorter, we can't reverse the truncation. Instead, LoT uses a deterministic blake2b hash-based method to create a synthetic native H256 account that acts as a system proxy for the EVM user.

• This native proxy account receives tokens and signs transactions on behalf of the EVM address.
• However, the EVM user does not own the private key for this native address — it only exists for routing and system access.

Example:

• EVM H160 address:
  0xc6006fea43ccce14f9432f8e6b9403113c935cc1
• Mapped native H256:
  0xceb75620b9f3bc3a039b8e78efed58fa3c7422d18c97f1fd44abf3f2499d0760
• Mapped SS58 (LoT format):
  d1GvktUdvKdghY7LB2zW2XDp1Wzio9ZPGGFcyaYhp2Nasy5LS

The mapping enables:

• Receiving native P3D or assets from the LoT chain into MetaMask
• Using EVM accounts to trigger native runtime logic through precompiles

🧪 Transferring Between Native & EVM Accounts

A quick overview on cross-platform transfers flow would be as follows:

• Connect Metamask to The Ledger of Things using the following credentials. Add a custom network, if necessary.

Name: 3dpass - The Ledger of Things
Chain id: 1333
RPC: https://rpc-http.3dpass.org

• Send P3D or Assets to any EVM account, using the 3DPass wallet (to be received on Metamask):

• Receive funds from any EVM account (e.g. from Metamask), using the “EVM withdraw” option:

• Submit the “EVM withdraw” transaction to withdraw P3D from EVM (required for P3D only).

🟢 Smart contract deployment

Smart contract deployment procedure is as simple as usual. Use familiar tools (Truffle, Hardhat, Remix) in a brand-new environment.

🔗 Summary: Native + EVM in One Chain

• EVM Compatibility — Run Solidity contracts directly on LoT
• MetaMask Support — Connect using Chain ID 1333
• P3D as ERC-20 — Interact via 0x...0802
• Assets as ERC-20 — Interact via dynamic 0xFBFBFBFA... address
• Cross-Platform Transfers — Move tokens between native and EVM layers
• Address Mapping — H256 ↔ H160 via truncation + blake2b hashing

Reference:

1. 3dpass LoT Node on github: https://github.com/3Dpass/3DP
2. How to deals with smart contracts: https://3dpass.org/assets#smart-contracts-solidity
3. Metamask interaction guidelines: https://3dpass.org/mainnet#metamask