1. Introduction & Motivation

Background

The EQTY platform relies on a dual-layer architecture:

• A private layer for managing verifiable event chains (e.g. Ownables, messages)
• A public anchoring layer to timestamp and verify those event chains on an immutable blockchain
  

Historically, this public layer was provided by LTO Network Layer 1, a dedicated Proof-of-Stake blockchain optimized for anchoring.

However, the operating context has changed significantly.

Why LTO Layer 1 must be deprecated

1. Economic security has collapsed

• LTO currently has a market cap under $5M, with only ~20% of tokens staked.
• This means the effective security budget (i.e. total value securing consensus) is < $1M.
• At these levels, it is financially viable for a malicious actor to compromise consensus, censor anchoring transactions, or rewrite history.
• For a platform like EQTY — which anchors legally enforceable asset records — this is unacceptable.

2. Validator centralization and low incentives

• Community nodes are no longer economically viable.
• Nodes ending service could lead to a small set of nodes holding disproportionate control over consensus.
• This undermines the decentralization guarantees that anchoring is meant to provide.

3. Adoption friction

• It is increasingly difficult to justify LTO as a secure anchoring layer in sales or audit conversations.
• Clients and partners expect EQTY to anchor on widely adopted and credible public networks (e.g. Ethereum, Base).
• The perception of “anchoring to a $5M Layer 1” weakens trust in EQTY’s core infrastructure.

4. Infrastructure fragility

• If even a few key validators go offline, LTO becomes unstable or halts entirely.
• Continued maintenance (explorers, indexers, node infra) adds overhead with diminishing value.

Why Base is the right anchoring layer

Base offers:

• Full EVM compatibility
• Economic and technical security inherited from Ethereum
• Broad tooling support (MetaMask, WalletConnect, The Graph, etc.)
• Near-zero fees with fast finality
• Close alignment with EQTY's asset and liquidity layer, which also lives on Base
  

Anchoring to Base removes the burden of maintaining a custom Layer 1 while increasing auditability, composability, and trust.

Strategic motivation

• EQTY's value is not in consensus — it's in its private layer, asset model, and compliance architecture.
• Maintaining a Layer 1 offers little strategic advantage at high cost.
• Moving to Base allows EQTY to focus entirely on product adoption, legal integration, and asset tokenization, without being dragged down by Layer 1 infrastructure.

2. New $EQTY ERC-20 Token

The EQTY platform will introduce a new ERC-20 token, $EQTY, deployed on the Base network. This token replaces the LTO token and serves as the native currency for protocol operations, including anchoring and governance.

The token contract begins with zero supply. $EQTY is minted on demand when users swap their LTO tokens during a limited migration period. This window is enforced on-chain: after a predefined block height, the mint function becomes permanently disabled. Any LTO tokens not converted before this cutoff are excluded from the EQTY ecosystem, and the final $EQTY supply will be lower than the original LTO supply.

The token contract is deliberately minimal. It follows the standard ERC-20 interface, with no special transfer logic, airdrop features, or vesting schedules.

The $EQTY token will be used to pay anchoring fees, participate in protocol governance, and potentially support additional utility roles as the platform evolves. Utility requires tokens to be burned, reducing the overall supply.

3. Anchor Contract on Base

Anchoring will be performed via a lightweight smart contract deployed on the Base network. This contract emits events that publicly record the hash of event chains or messages, without storing any on-chain state.

Each anchor maps a key to a value, where:

• For event chains: key = stateHash, value = eventHash
• For messages: key = messageHash, value = 0x0

Interface

struct Anchor {

bytes32 key;

bytes32 value;

}

function anchor(Anchor[] calldata anchors) external;

event Anchored(

bytes32 indexed key,

bytes32 value,

address indexed sender,

uint64 timestamp

);

Behavior

• The contract emits one Anchored event per (key, value) pair.
• The current block.timestamp is included in the event as a separate field for convenience and auditability.
• No state is stored in the contract. All anchoring data is recorded through logs only.
• The contract is permissionless — anyone can anchor.
  

These events are designed to be indexable and accessible by:

• Internal components, such as the oBridge indexer and the EQTY platform
• External services, including The Graph, Infura, or custom verifiers
  

By keeping anchoring stateless and emitting complete events, this design ensures that anchoring is verifiable, efficient, and infrastructure-independent.

Fee mechanism

• The clients needs to call  approve() to on the ERC20 contract enable anchoring
• Each anchor incurs a burn of $EQTY, enforced in the anchor() function
• Fee amount is read from a separate governance-controlled config contract
• Anchoring will not use approve() but instead burn via eqtyToken.burnFrom(msg.sender, fee * n)

4. Fee Governance

To keep anchoring economically sustainable and fair over time, the fee paid in $EQTY per anchor must be adjustable. Rather than hardcoding a static fee or relying on price oracles, EQTY will use an on-chain governance model to control this parameter in a transparent and decentralized way.

A dedicated configuration contract will store the current anchoring fee. This value can only be updated by a governance contract — specifically, an instance of OpenZeppelin’s Governor tied to the $EQTY token. Votes will be cast based on $EQTY balances using standard ERC20Votes logic.

The anchoring contract reads the current fee from the configuration contract each time anchor() is called. It then burns the appropriate amount of $EQTY directly from the sender’s balance. This approach avoids the need for approve() transactions and ensures that the anchoring contract remains lightweight and stateless beyond fee enforcement.

The governance model enables the community to adjust fees over time in response to market conditions, token price fluctuations, or changes in anchoring demand — without relying on external data sources or centralized control.

5. New Private Layer Library

To support anchoring on Base and wallet-native signing, a new standalone TypeScript library will be created to handle the private layer logic — including event chains, event signing, anchoring, and relay message structures. This library replaces the LTO-specific @ltonetwork/lto-api.js for all EQTY use cases.

The new library is designed to be used in both browser environments (e.g. MetaMask, WalletConnect) and server-side tools.

Scope and contents

Only the relevant components of the LTO private layer will be included:

• events/ Includes Event, EventChain, MergeConflict, and related serialization logic.
• message/ Includes Message and Relay, used for encrypted off-chain communication.
• Supporting code Includes utility classes such as Binary.
  

The library will have no dependency on LTO Network:

• No LTO node API
• No transaction logic
• No keypair generation tools
• No LTO-specific address encoding
  

It will support anchoring via smart contracts on Base, and integrate cleanly with ethers.js for signing and submitting anchors.

Event signing model

The Event.signWith() method will be made asynchronous to support browser-based signing via MetaMask, WalletConnect, or any external signer, in addition to signing directly with ethers. It uses an abstract ISigner interface:

interface ISigner {

sign(data: Uint8Array): Promise<Uint8Array>;

}

The signed event no longer requires a public key; it only includes the signature and the derived address. This makes it compatible with Ethereum signing flows (personal_sign) and removes the need to extract public keys, which is not possible in most wallet environments.

Anchoring integration

The library includes a method to generate anchor maps:

const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();

Each anchor maps a stateHash (key) to a lastEventHash (value), ready to be submitted to the Base smart contract. For relay messages, the message hash itself is used as the anchor key, and the value is set to zero (0x0).

Anchoring can be performed by calling the smart contract directly via ethers.Contract.anchor(Anchor[]). This avoids dependency on any backend service or proprietary infrastructure.

Message signing

The library also includes Message and Relay classes for off-chain communication. Like events, messages are signed asynchronously using the ISigner interface. Signatures are over the message hash, and no public key is included — only the derived address is used for verification.

After signing, the message hash is anchored on-chain via the same Anchor contract. The format is:

• key = messageHash
• value = 0x0
  

This ensures that off-chain messages can be publicly timestamped and verified without revealing their contents. Anchoring can be done by the sender or relay service.

Deployment and usage

The library will be published as a separate NPM package. It is intended to be the shared core used by:

• The EQTY wallet (for event and message signing)
• The relay service (for hash calculation and message parsing)
• The Ownables SDK (for event construction and submission)
• Any third-party frontend or verifier

6. oBridge Indexing

The oBridge service will replace its current LTO-based indexing logic with a new indexer that processes Anchored events emitted by the Base anchoring contract.

This indexer listens for anchoring logs on Base and maintains a local database of the most recent anchor per key, which may represent either an event chain state or a relay message hash. Each entry includes:

• key: the anchored state or message hash
• value: the corresponding event hash or 0x0
• txHash, blockNumber, logIndex, and sender
  

These records are exposed through a public HTTP API. The structure and behavior of this API will remain compatible with the existing LTO anchoring indexer, including the GET /hash/verify endpoint, allowing existing EQTY components to transition with minimal changes.

The oBridge indexer serves two roles:

1. As an internal dependency for the relay service, which must verify that messages have been anchored before releasing them.
2. As a public verification service for external clients and wallets that wish to check anchoring status without querying Base directly.
   

All data remains verifiable on-chain, and clients may bypass oBridge if desired by using eth_getLogs or their own indexer.

7. Relay Service

The relay service handles secure delivery of encrypted messages between parties. To ensure messages are authentic, timestamped, and access-controlled, the service will be updated to support both on-chain anchoring validation and modern, wallet-native authentication using Sign-In with Ethereum (SIWE).

Message Authentication with SIWE

Instead of relying on HTTP message signatures or custom challenges, the relay will implement the SIWE standard (EIP-4361). This approach allows users to authenticate by signing a standard text message with their Ethereum wallet, producing a recoverable signature that binds them to a session.

Login flow:

1. Client requests a SIWE message from the relay backend: GET /auth/siwe-message?address=0x...
   
2. Server returns a standard SIWE message including:

• Domain (e.g. relay.eqty.network)
• Nonce
• Expiration timestamp
• Optional resources field limited to /messages?to=...
• Statement: e.g. “Sign in to access your EQTY messages.”
  

1. Client signs the message using personal_sign
   
2. Client submits the signed message and signature to POST /auth/verify
   
3. Server verifies the signature and issues:

• A JWT access token (short-lived, e.g. 15 minutes)
• A refresh token (longer-lived, e.g. 24 hours)
  

All subsequent message retrieval requests (GET /messages?to=...) must include the access token in the Authorization header.

When the token expires, the client can use the refresh token to obtain a new access token without re-signing.

This model is fully compatible with MetaMask, WalletConnect, and other EIP-1193 wallets, and follows widely adopted security patterns. No custom logic or infrastructure is required beyond existing SIWE libraries.

Message Anchoring and Verification

In addition to authentication, the relay service will validate that each message has been anchored on-chain before delivering it. Anchoring provides immutability, timestamping, and prevents spam or replay attacks.

The relay maintains its own lightweight indexer for the anchoring contract on Base. It listens for Anchored events and records:

• key = messageHash
• value = 0x0
• sender
• blockNumber, txHash, timestamp
  

To verify a message before delivery, the relay checks that:

• An Anchored event exists with key = messageHash
• The value is exactly 0x0 (i.e. not an event chain anchor)
• The sender matches the message signer (i.e. from address)
  

Only after successful anchoring is the message released to the recipient. This ensures all messages are publicly verifiable, timestamped on Base, and anchored by the correct identity.

The relay performs this verification using its own internal indexer and does not rely on oBridge.

8. Ownable Contract Changes (CosmWasm)

With the migration away from LTO Layer 1 and the deprecation of public key–based event signing, the Ownable contracts must be updated to support address-based authorization using standard Ethereum addresses.

Address-based authorization

Previously, ownership verification relied on recovering and comparing public keys extracted from signed events. Since Ethereum wallets do not expose public keys, and signatures now use personal_sign (recoverable to an address), the verification model must shift to comparing addresses directly.

The updated contract logic uses info.sender — the address that signed and submitted the event — as the authoritative identity.

This affects all entry points where authorization is required:

• try_transfer: sender must match current owner address
• try_release: sender must match prior locked owner address
• try_register_lock: verifies that the event’s owner field matches the signer
  

Instead of converting public keys to LTO addresses, the contract simply stores and compares Addr values (e.g. 0xabc123...).

CAIP-2 and network matching

The contract continues to validate the origin of cross-chain events using the CAIP-2 network identifier. For Ethereum-based messages, the namespace is eip155:<chainId>. The contract verifies that:

• The event.network matches the expected network
• The owner field in the event matches the signer (info.sender) under the given CAIP namespace
  

The conversion functions address_lto() and address_eip155() can be removed, as no translation to or from LTO addresses is needed anymore.

Impact

This change makes the Ownable contract:

• Fully compatible with Ethereum-native signing and identity
• Independent of LTO key infrastructure
• Compatible with any chain that supports address-based recovery (e.g., EVM)
  

Existing Ownables, which rely on LTO-specific signing and anchoring, will become unverifiable under the new model and must be reissued (see Section 11).

9. Ownables SDK Update

The Ownables SDK must be updated to reflect the shift from LTO-based public key signing to Ethereum-style address-based authorization and Base anchoring.

Key updates

1. Event signing

• Update event creation to use the new private layer library (@eqty-core/events)
• Use ISigner implementations compatible with MetaMask, WalletConnect, or ethers-based signers
• Ensure signWith() no longer relies on a public key; only the recoverable address is used
  

1. Anchoring

• Replace LTO node anchoring logic with smart contract submission on Base
• Use getAnchorMap() to collect (key, value) pairs and submit them via ethers.Contract.anchor()
• Ensure message anchoring uses (key = messageHash, value = 0x0)
  

1. Verification

• Update verification logic to use the oBridge-compatible /hash/verify API or a direct log query
• Confirm that the anchor value matches the expected event hash and that the sender matches the Ethereum address of the signer
  

1. Address usage

• Replace any logic that compares or generates LTO addresses
• Use plain Ethereum addresses (0x...) throughout event and message flows

Compatibility

The updated SDK remains structurally similar but is no longer tied to the @ltonetwork/lto-api.js library or LTO node services. It is compatible with the new private layer library and Base anchoring, and will interoperate with the updated Ownable contracts and relay service.

10. Universal Wallet Update

The universal wallet must be updated to reflect the migration to Base and the new EQTY architecture. It no longer interacts with LTO nodes.

Core updates

1. Wallet connection

• Replace LTO keypair handling with Ethereum-compatible library (ethers.js)
• Use EIP-1193 provider interfaces to enable signing and address retrieval
  

1. Token support

• Add support for displaying and managing balances of the new $EQTY ERC-20 token on Base
• Include token metadata, history, and balance tracking via public RPC endpoints
  

1. Event and message signing

• Integrate the new private layer library to allow users to create and sign event chains and messages
• Use personal_sign via the connected wallet; public keys are no longer required
  

1. Anchoring

• Submit anchor maps directly to the Base anchor contract using ethers.js
• Handle on-chain submission, confirmation, and optional UI feedback for anchoring cost in $EQTY
  

1. Relay integration

• Authenticate via SIWE (Sign-In with Ethereum)
• Store and refresh access tokens as needed
• Use authenticated requests to fetch encrypted messages from the relay service

Features removed

• LTO leasing UI
• Node selection and chain view
• On-chain identity management tied to LTO

11. Migration Plan

With the deprecation of LTO Layer 1 and the introduction of a new anchoring system on Base, all core components of the protocol must migrate. Legacy data tied to LTO infrastructure — including anchors, event chains, and messages — will no longer be valid.

What becomes invalid

• Event chains signed using LTO key pairs cannot be verified, since the public key is no longer extractable from Ethereum-based signatures.
• Anchors recorded on LTO L1 cannot be trusted or queried going forward.
• Ownables tied to LTO-based identities or anchored chains must be replaced.
• Messages not anchored on Base will be rejected by the relay service.

Required actions

1. Token migration Users must manually swap their LTO tokens for $EQTY using the bridge. Minting is only possible up to a specific block height on Base. After this block, the bridge will be shut down and the mint function permanently disabled. Unswapped LTO tokens become worthless.
   
2. Reissue Ownables Asset. Ownable issuers must issue new ownables tied to the BASE network. Instructions will follow on how to swap legacy Ownables to new Ownables
   
3. Wallet transition Users will need to update Universal Wallet.

No snapshot

There will be no snapshot, automatic migration, or backward compatibility layer. Each component (events, messages, token balances) must be re-established on Base through the proper interfaces. The new protocol is clean by design and does not preserve ties to LTO L1.