It's just surprising that the number's that large.

My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

Kinda weird, but kinda simple.

Thanks for taking the time to reply to this.

Now that I have the context, I find what you're doing super interesting, and well thought out. And greatly value the passion you're building it with as well.

I want to clarify, my message wasn't intended as a dig at what you are doing - especially since I didn't actually look into it at all before writing my reply.

By definition, and especially when explained with enough detail, anything that we do couldn't be done with a different tool, in the sense it'd have to be done differently.

What my comment was meant to address was the original comment's question regarding the value of doing something "on-chain". Mainly because it's something that I've been thinking about a lot, being a founder as well in a similarly-hyped vertical.

At it's core, blockchains are a database, and so any high level goal - beyond the composability/interoperability of on-chain primitives through tokens and shared state - can be achieved without a blockchain.

However, there are many reasons to leverage the position of a blockchain project beyond the technical _need_ for a DLT.

The VC environment might be attractive to some -leveraging the network effects of a sufficiently decentralized network, tapping into ecosystem incentives and growth programs, personal alignment with the moral values typically associated with decentralization, personal connections in the industry/vertical, etc.

All that to say; no one asks why you're using a relational database or a graph database with as much suspicion or caution as they do why you're putting your stuff on-chain, and while that makes sense because of the... unique circumstances of DLTs, there's a lot more nuance to it from a business perspective than just asking yourself the "is it a grift?" question.

Understanding the limitations is a complicated thing in tech. You can finnangle most systems into doing mostly anything, as inefficient as that may prove to be.

The question then becomes up to what point is it "a reasonably better than most others" solution. And that's a question of an understanding of a field, not a space in the field.

Blockchain has taken a weird path. It started with Bitcoin offering something genuinely new - a Byzantine fault-tolerant mechanism for decentralized value exchange without trusted intermediaries. But the industry has drifted toward "web3" hype where the technology often isn't necessary.

Companies pick tech stacks for all sorts of reasons beyond technical merit - vendor relationships, development velocity, legacy system compatibility, and UX considerations all factor into these decisions.

Truth is, most blockchain companies today are solving problems that could be handled just fine with traditional databases and APIs. The industry is shifting toward abstraction layers that hide the consensus mechanisms anyway, focusing on user experience instead.

The project mentioned probably doesn't actually need a blockchain backend for what it's doing, except maybe for tradable collectibles on an ERC standard.