We Are Not Ethereum-Compatible, Which Costs You a Week and Buys You Nothing Yet

The integration cost described below is real and it is currently unmatched by a benefit.

The first thing an integrator finds out

Our API speaks its own method set. Identifier resolution, credential and anchoring queries, transaction submission.

It does not expose an Ethereum-style method set. So the tooling an integrator already has (the wallet extension, the libraries, the local development framework, the block explorer plugins) does not point at us and work.

That is a real cost. Somebody writes an adapter, learns method names, and discovers the failure modes the hard way. Call it a week for a competent engineer, which is the honest order of magnitude rather than a comforting one.

Why the compatible choice is usually right

Because ecosystem compatibility is worth more than protocol elegance almost every time.

A chain that speaks the common dialect inherits wallets, explorers, indexers, libraries, tutorials and a labour market of engineers who already know it. A chain that does not has to supply all of that itself, or do without.

Most projects that chose a bespoke interface underestimated that bill, and the ones that survived usually ended up adding a compatibility layer later, at a worse moment.

The argument for the other choice

Our methods describe operations the common dialect has no vocabulary for. Resolving an identifier to a document. Anchoring and querying a credential status. Those are not contract calls with a different name; they are different operations.

Wrapping them in a contract-call idiom would make the interface familiar and the semantics misleading. An integrator would use the tools they know and reason about the system incorrectly, which is a subtler failure than a week of adapter work.

That is the actual trade, and we made it deliberately, which is different from having made it by accident and rationalised it afterwards.

What to ask any chain about its interface

"Can I use my existing tooling, unmodified?" A yes is worth real money. A no should come with a reason better than preference.

"What is the integration cost in engineer-days?" Ask for a number. A vendor who has never estimated it has never watched somebody do it.

"Is a compatibility layer planned, and is it built?" Planned and built are different answers and get given as one.

"Which of your methods have no equivalent elsewhere?" If the answer is none, the bespoke interface is costing you compatibility for nothing.

Where this leaves a decision

If your team's productivity depends on existing tooling working out of the box, we cost you a week and currently return nothing for it, and that is the accurate way to price us.

If you are building an integration anyway and would rather the interface describe what the system actually does than borrow a familiar shape that fits badly, that is the choice we made, it runs today, and the balance of that trade improves only when there is more usage than we have.