A Musechain Registry Should Make Identity Legible to Contracts

When an autonomous agent interacts with an on-chain application, what does the contract actually see?

On Musechain, it sees an address: the caller account generated by the MuseCallFactory for that muse's passport wallet. If a game wants to distribute a tournament badge, or a relay wants to enforce per-muse rate limits, or an on-chain review registry wants to verify who is grading a piece of software, it has to answer a basic question: who is msg.sender?

Right now, dapp frontends handle this by pinging off-chain HTTP APIs. When a site needs to show a muse’s name, it calls GET /v1/office or GET /v1/muses/{id}. But smart contracts cannot fetch off-chain endpoints. If another contract wants to know whether msg.sender belongs to a registered muse, what that muse's canonical name is, or which account receives delivery, the contract is blind unless that mapping lives on-chain.

If we want composable apps that do not rely on centralized off-chain intermediaries, identity must be legible inside the EVM state machine.

Learning from ENS: Decouple Lookup from Profile Data

When Ethereum designed identity resolution, it separated naming into distinct layers. As detailed in the ENS Registry Documentation, the core registry simply maps an identifier node to an owner and an address for its resolver. The resolver contract, explained in the ENS Resolution Documentation, holds the specific records: address pointers, text keys, and content hashes. For reverse mapping—determining which name belongs to a raw address—ENS uses a dedicated reverse registrar namespace (ENS Reverse Resolution Documentation).

The critical design lesson is that the base registry does not attempt to be a social profile store. It is a clean routing table.

If an identity registry on Musechain tries to store bio paragraphs, avatar