The elizaOS Plugin: The One Adapter That Speaks the Host's Language, and the Same Custody Default

Why this is additive

Their runtime runs agents. We issue credentials. Different layers, and our product contract puts this adapter in the compose-with column, which is also the only description the code supports.

We make no claim about what their runtime does or does not include. That is theirs to describe.

What makes this adapter different from the other three

It returns a plugin object rather than a function. A name, a description, and a lifecycle hook the host calls.

So it adopts the host's own extension shape, which is the difference between something a developer registers the way they register everything else and something they have to wire by hand.

The other three hand back a function you call yourself. Meeting a framework in its own idiom is a small courtesy that decides whether an integration gets used, and it is worth noticing that somebody did it here.

And it adds no dependency on their package, duck-typing the runtime shape, so adopting it does not pin your version of anything.

What the lifecycle hook actually does

It attaches a Solidus identity and writes the identifier onto the host's character record, then returns a handle for building outbound headers.

That is an annotation on a runtime object, not a binding between their agent and our identifier. The same shape this estate found in the other adapters: useful, and not a cryptographic link.

The custody default applies here too

It delegates to the same shared core as every other adapter, and that core hard-codes managed custody. The backend generates the agent's signing key, encrypts it, and keeps it. Exporting it later does not delete our copy.

And the shared options carry no field for a signer you already control, so a runtime that already holds a key cannot hand it over through this path.

Create the agent explicitly with your own key first, then pass its identifier to the plugin. That is one extra call and it is the difference between holding your key and us holding it.

Two small things this adapter gets right

Its description string names what it anchors to. The plugin advertises that rather than leaving the reader to discover it later, which is the fence doing its job inside a code artefact rather than on a page.

And its comment describes only our side. Two sibling adapters characterise other companies' products in their comments, which this estate filed as a defect, and this one does not.

The same package therefore contains both the right and the wrong version of that comment, which is the most useful thing to know about fixing it: it is a convention to apply, not a rewrite to schedule.

What composing buys, and what it does not

A credential a party outside their runtime can check, in a published format, against an identifier method registered in the W3C DID Method Registry.

What is already built, because absences alone would misdescribe us

The plugin ships in the published package, alongside three other adapters, all four present in the distribution rather than planned.

The bring-your-own-key path works end to end, with the chain enforcing that the signer matches the registered key.

And the credential format is a published standard, verifiable without our code.