We talked to Arman Mamyan, ecosystem and technology professional at Animoca Brands, about the challenges of building scalable digital ecosystems and why identity, interoperability and trust are becoming fundamental architectural questions rather than isolated technical features.
As Web3 infrastructure evolves, connecting systems is becoming less about simply exchanging data and more about creating shared standards around ownership, permissions, verification and accountability. Large ecosystems require architectures that can support multiple independent participants while maintaining reliability, security and trust.
In a conversation with MetaTalks, Arman shared his perspective on why interoperability failures are often caused by mismatched assumptions rather than technical limitations, when identity becomes a foundation for system design, and why the next generation of ecosystems will depend on reducing — not eliminating — the need for trust.
MT: At what point does identity stop being a component you integrate and become a constraint that defines system architecture?
Identity stops being another integration the moment multiple systems begin making decisions based on it independently. At that point, identity is no longer authentication. It becomes the foundation for authorization, trust, compliance, user experience, recovery and interoperability. Every architectural decision starts inheriting assumptions from the identity layer.
If you change identity, you change the behavior of the entire ecosystem. That is when identity stops being a feature and becomes architecture.
MT: Where does interoperability most often fail in practice — data exchange, system behavior, or trust assumptions?
Most people assume interoperability is about moving data. In reality, exchanging data is usually the easy part. The failures happen when two systems interpret the same data differently or rely on different trust assumptions.
One system may assume identity has already been verified. Another may assume signatures automatically imply authorization. Another may expect revocation to happen instantly. The interfaces can be compatible, but the assumptions are not.
This is where interoperability becomes less about APIs and more about shared semantics.
MT: When does scaling integrations stop being an engineering problem and become a system design problem?
Once every new partner introduces another variation of identity, compliance, permissions, recovery and business logic, you are no longer just connecting systems. You are managing complexity.
At scale, the challenge is not writing another connector. It is designing abstractions that allow hundreds of connectors to behave predictably without creating exponential operational overhead.
The real problem becomes creating a system where complexity can grow without making the entire ecosystem harder to operate.
MT: How do you define what must remain inside a trust boundary versus what can be externalized?
I would start with one simple question: if this dependency disappears tomorrow, what breaks?
Anything that determines ownership, authorization, security or accountability belongs inside the trust boundary. Everything else — computation, messaging, storage, indexing, analytics and even parts of identity — can often be externalized, provided the outcome remains independently verifiable.
The goal should be minimizing the amount of trust you need to place in your dependencies rather than trying to remove dependencies completely.
MT: What failure modes only become visible once systems are running in production at scale?
Scale exposes failures that architecture diagrams never show: identity collisions, race conditions between independent systems, permission drift, retry storms, recovery edge cases and operational assumptions that nobody documented because they “always worked.”
The interesting thing is that these are rarely algorithmic failures. They are coordination failures between systems that individually behave correctly but do not always interact correctly.
MT: When does traditional system design stop being enough and ecosystem design become necessary?
The moment your platform becomes infrastructure for partners, institutions, developers and regulators, your responsibility changes.
You are no longer designing products. You are designing incentives, governance, standards, upgrade paths, compatibility and trust relationships.
At that point, ecosystem design becomes more important than software design because the challenge is no longer only how systems function, but how independent participants can operate together over time.
MT: How do you decide what is cryptographically verifiable versus what relies on inter-system trust?
A common mistake is trying to replace trust with cryptography. Cryptography should answer questions that have objective answers: who signed something, who owns something and when something happened.
Everything involving intent, policy, reputation, regulation or business context usually requires trust beyond cryptographic verification.
The goal of a system should not be to eliminate trust completely. It should be to reduce the amount of trust required and make the remaining trust explicit, transparent and manageable.
MT: What is the most underestimated bottleneck in identity and interoperability infrastructure today?
Most infrastructure problems today are not technical limitations. We already know how to exchange credentials, verify signatures and connect APIs.
The difficult part is getting independent organizations to agree on what those credentials actually mean, when they are valid, who is accountable for them and how trust evolves over time.
Technology scales much faster than shared trust. Building that trust layer is one of the biggest challenges for the next generation of digital ecosystems.