Introducing Stele Routes: Named Endpoints for Stele

A Stele name gives you a permanent identity on Ethereum.

Instead of sharing:

0x742d...

you can use:

alice@pay

But one identity may need more than one endpoint.

You might have a personal account, a business account and a treasury. You might receive funds across different networks. A protocol may have a treasury, router, vault and other contracts.

That's what Stele Routes is for.

What are Stele Routes?

Stele Routes lets you publish named sub-paths under your Stele name, much like paths on a website:

label@namespace/routeLabel

Each route points to something different: another EVM address, a Bitcoin or Solana address, a link, or a ready-made transaction. The owner of the Stele name decides what each route points to. For example:

alice@pay/personal  → 0xdf2…3e7     (EVM address)
alice@pay/business  → 0xabc…901     (another EVM address)
alice@pay/bitcoin   → bc1q…         (Bitcoin address)
alice@pay/solana    → 7Ec…          (Solana public key)
alice@pay/pay-rent  → 0xa9059cbb…   (ready-made transaction)
alice@pay/docs      → ipfs://bafy…  (link)

A Stele name owner can create as many routes as they like, for free. The only cost is gas.

Lookups go one way only: from a route to its endpoint. There's no reverse lookup, as several routes can point to the same endpoint, for example alice@pay/payments and alice@pay/usdc could both point to the same address.

A generic endpoint layer

Each Stele Route stores two fundamental values:

bytes target;
uint32 routeType;

target contains the endpoint data. For example:

• Ethereum address: 0x742d...
• Bitcoin address: bc1qxy2kg...
• IPFS link: ipfs://bafybeibw...

routeType tells applications how that data should be interpreted. For example:

• 0 – Ethereum address
• 1 – Bitcoin address
• 2 – Solana pubkey
• 3 – EVM calldata
• 4 – URI (e.g., ipfs://…)

The meaning of each routeType value is an off-chain convention, documented in routeTypes/. The contract doesn't enforce it; applications decide how to interpret each target.

That's what keeps Routes flexible. New route types, including formats that don't exist today, can be added without changing the contract.

Multiple payment endpoints

Payments are an obvious use case.

Imagine Alice uses alice@pay as her payment identity.

She could configure:

alice@pay/personal
alice@pay/business
alice@pay/savings
alice@pay/bitcoin

Instead of maintaining several unrelated identifiers, Alice can publish multiple payment destinations underneath one recognizable identity.

A compatible payment application resolves the requested route, reads its routeType and interprets the returned target accordingly.

Protocol endpoints

Routes aren't limited to individuals.

A protocol can publish canonical endpoints underneath its Stele identity.

For example, if Aave owned aave@defi, it could publish a route for each of its v3 contracts:

aave@defi/v3-pool
aave@defi/v3-pool-configurator
aave@defi/v3-pool-addresses-provider
aave@defi/v3-oracle
aave@defi/v3-treasury

Hence, instead of distributing raw contract addresses across websites, documentation and configuration files, Aave could simply share its routes and applications would resolve the named endpoints via the Stele Routes registry.

Beyond addresses: actions

A route doesn't have to point to a destination. It can also describe an action.

Routes can be used with URL-style parameters:

usdt@action/transfer-usdt?to=0x1234…abcd&amount=100

The parameters are not part of the on-chain route. An application strips the ?… part, resolves usdt@action/transfer-usdt, and passes the parameters to the endpoint.

With a route builder route type, that endpoint is a contract that turns the parameters into a ready-to-sign transaction. The user sees a readable action instead of raw calldata, and the logic behind it is published under the owner's Stele identity.

Routes can be updated — until they are frozen

Endpoints may change.

Newly created routes are therefore mutable by default.

The Stele name owner can update a route's target and routeType while the route remains unfrozen.

When an endpoint is final, the owner freezes the route.

Once frozen:

target      → permanently fixed
routeType   → permanently fixed

Freezing is irreversible.

Freezing is also what makes a route resolvable. The resolver only returns frozen routes, which gives applications a simple guarantee:

Once an application relies on a route, its endpoint can never be swapped.

Unfrozen routes are effectively drafts. Their records can still be read and inspected, but they are not returned by resolution.

Active and inactive routes

Permanence and operational status are separate concepts.

Every route has an isActive state.

A Stele owner can deactivate a route, even a frozen one.

For example:

alice@pay/old-wallet
target     → unchanged
isFrozen   → unchanged
isActive   → false

Resolution only returns active routes, so a deactivated frozen route stops resolving immediately.

The route can later be activated again.

A route can therefore have a permanently fixed endpoint while still being temporarily or permanently taken out of active use.

Routes that can never be switched off

There are use cases where a route should be frozen and also impossible to deactivate. Take a route sponsored for someone else:

gifts@sponsor/alice

A sponsor publishes a route pointing to Alice's address. Freezing guarantees the endpoint can never be swapped, but the sponsor could still switch the route off at any time. For Alice to rely on it, deactivation must be ruled out too.

The solution is to just let a smart contract own the sponsor's Stele name.

Stele names are non-transferable, so only that contract can ever manage the routes under its name. If the contract can only create frozen routes, and has no way to update or deactivate them, every route it publishes resolves permanently. The guarantee is enforced by code anyone can inspect.

For those that want to use this, the repository includes an example contract, SponsoredRoutes that allows its owner to add frozen routes that cannot be switched off.

Closing the route book

Freezing a route determines whether that particular endpoint can change.

Closing the route book determines whether new routes can be added.

A Stele owner can permanently close the route book associated with their name.

Once closed, no additional routes can ever be created under that Stele name.

Existing routes remain unchanged.

For example:

alice@pay
/personal   → frozen
/business   → frozen
/bitcoin    → mutable
Route book  → closed

No new routes can ever be added to alice@pay.

But /bitcoin can still be updated because it was never frozen. Until it is frozen, it also won't resolve.

This creates two independent guarantees:

Freeze a route when its endpoint should become permanent.

Close the route book when the set of available routes should become permanent.

Simple ownership

If you control the Stele name, you control its routes.

There are no route NFTs and no separate route owners. Routes simply belong to the Stele name they were created under.

Conclusion

Stele Routes introduces a small, generic primitive:

label@namespace/routeLabel → typed endpoint

Applications can use it to look up addresses, links and transactions by name, instead of copying raw data around.

Stele provides the permanent identity.

Stele Routes gives that identity named endpoints.

One identity. Many destinations.

Get started

• Contract, docs and examples: github.com/Walodja1987/xns-routes
• Route type conventions: routeTypes/