MPS-0015: Midnight Agent Identity Standard

[mzf11125]

Hey everyone. I have been working on a proposal called MAIS, the Midnight Agent Identity Standard. The idea is to define four Compact contracts that let AI agents on Midnight register their identity, build reputation, get validated by third parties, and control disclosure at Midnight's three privacy tiers. The DevRel team has already escalated this to engineering for a deep review which is great.

There are two PRs open right now.

The MPS (#113) describes the problem. Right now every team building agents on Midnight invents its own identity scheme. We need a shared standard before ten incompatible ones emerge. The MIP (#110) is the full spec with all four registries, the dual mode identity model, tiered validators with staking and slashing, and an optional ERC-8004 bridge.

I would love community feedback on a few things. Should we ship both public and private identity modes in v1 or start public only? Is a public reputation score with private evidence the right balance? Are the validator stake amounts reasonable? And for the ecosystem builders reading this, what is the smallest set of features you would need to adopt it?

Links below. All feedback welcome, either here or on the PRs.

MPS: #113
MIP: #110
Forum RFC: https://forum.midnight.network/t/rfc-mip-midnight-agent-identity-standard-mais/1231

[nstanford5]

MPS has been merged: https://github.com/midnightntwrk/midnight-improvement-proposals/blob/main/mps/mps-0015-agent-identity.md

[Zolldyk]

Builder perspective on your question about the smallest feature set for adoption.
I’ve built autonomous agents on Solana. One of them is an ElizaOS-based DeFi agent that trades within a permission policy and writes every action to an on-chain audit trail. Another is a tool that gives agents their own wallets. If I were bringing either to Midnight, my minimum for v1 would be:

1. Identity registration in contract address mode only. Public discoverability is what a counterparty needs first. Private mode can follow as long as both share the same interface (as the MPS goals already state).
2. A way to bind an agent’s identity to its operator and its permission scope. For an agent like one of the ones I've built, the most useful thing an identity can carry is a verifiable statement of what the agent is allowed to do instead of just a reputation score.
3. One SDK call to register and one to query. If registration takes more than that, builders will roll their own. That's part of the fragmentation I think this MPS is trying to prevent.

Some things I’d defer include validator staking and slashing. It’s the hardest part to get right, and nothing in the minimum set depends on it. The point raised in MIP-0029 about registration cost as a Sybil deterrent seems worth testing first.

One gap I’d flag is that the MIP-0029’s threat model covers a compromised operator key, but it only recommends rotation through the wallet SDK. It doesn’t say whether an agent’s identity and reputation carry over to a new key. Deactivation is also irreversible. From my understanding, that means a stolen key can permanently wipe out an agent’s accumulated reputation. Personally, I think that will be a real loss for the operator even if the attacker gains nothing. Agents who hold their own keys will run into this early.