السبب في صحة هذا هو أنك لا تستطيع ضبط تطبيق متعدد السلاسل بدقة. تجربة المستخدم، والتدفقات، وما إلى ذلك، كلها يجب أن تتم لأدنى قاسم مشترك في السلاسل التي تدعمها إلا إذا كان بإمكانك جعل الفرق الكاملة تحافظ على كل منها. حينها لديك نتيجتان: → يمكن أن تقدم عمليات النشر الأصلية تجربة مستخدم أفضل ل~نفس المنتج → تفقد حسن نية المستخدمين المحليين هناك أيضا عبء الأنظمة المتكررة وتتبع انحرافات كل سلسلة (والتي لا يمكنك حتى ضبط تطبيقك عليها على أي حال). "أوه، رائع، ميزة جديدة على ميغاإيث على مستوى البروتوكول لجعل جميع التطبيقات أفضل!" → "أوه، إذا طبقناه فهذا يكسر المعيار ويصعب صيانته. من الأفضل أن تبقى آمنا." قد يكون من المنطقي أن يكون المتعدد السلاسل منطقيا عند مستوى معين من النجاح (مثل Pump، Uni، AAVE، إلخ)، لكن الغالبية العظمى من التطبيقات يجب أن يكون لها منزل وتنتج أفضل منتج ممكن حيث هي مع تمكين الودائع من جميع السلاسل (مثل نهج الأسواق المتعددة (مثل نهج السوق المتعدد السوق). هناك بالطبع اعتبارات عملية مثل عرض الفريق، صحة النظام البيئي، إلخ، لكنني أفضل بناء SOL واحد بسعر 8 دولارات على 100 تطبيق متعدد السلاسل على أي حال.