Wie Sie 2026 ein Entwicklungsunternehmen für Avalanche auswählen

Wenn eine Kapitalverwaltungsgesellschaft plant, tokenisierte Anteile auf Avalanche zu emittieren, kann ihr Risikoausschuss etwas fragen, das das technische Team nicht immer bedacht hat: Wer validiert die Transaktionen der Anleger und wo verbleiben ihre Daten? Auf der C-Chain, dem öffentlichen EVM-kompatiblen Netzwerk von Avalanche, lautet die Antwort: die Validatoren des Netzwerks selbst. Auf einer eigenenL1bestimmt der Emittent die Antwort und übernimmt damit den Betrieb dieses Netzwerks.

Von dieser Antwort hängt ab, wen man beauftragt. Eine Emission erfordert keine eigene L1; die L1 ist gerechtfertigt, wenn der Emittent entscheiden muss, wer validiert, wer teilnimmt oder wo die Daten liegen, und in diesem Fall ist der entscheidende Anbieter derjenige, der den Betrieb mit schriftlichen Zusagen übernimmt, nicht nur derjenige, der sie konfiguriert. Dieser Leitfaden hilft, die beiden Aufträge zu trennen (die Anwendung des Emittenten und, falls nötig, das dedizierte Netzwerk), erklärt, welche Kriterien ein solides Angebot auszeichnen und welche Demonstration Sie zusammen mit dem Angebot verlangen sollten. Herausgeber ist Metlabs, das Entwicklungsleistungen auf Avalanche anbietet und daher ein direktes kommerzielles Interesse an der Beauftragung hat; die Angaben stammen aus der Dokumentation von Avalanche und AvaCloud, abgerufen am 8. November 2026.

C-Chain oder eigene L1: Wie viel Kontrolle welche Option bietet

Ein Vorschlag zurTokenisierungbeginnt mit dem Recht, das derTokenverkörpert, dem verantwortlichen Emittenten und den Bedingungen für seine Übertragung oder Rücknahme. Die Transaktion registriert einen Vorgang; der rechtliche Vertrag und die Prozesse des Emittenten bestimmen die Beziehung zumBasiswert. Nichts davon zwingt zur Wahl eines bestimmten Netzwerks: Die Entscheidung zwischen C-Chain und L1 hängt davon ab, was der Emittent sonst noch kontrollieren muss.

Eine L1 ist ein Netzwerk mit eigenem Validatorensatz; so heißen die früheren Subnets seit dem UpdateAvalanche9000. DieACP-77, die Teil davon ist, hat deren Wirtschaftlichkeit verändert: Die Validatoren einer L1 müssen nicht mehr zusätzlich das Primary Network von Avalanche validieren und auch nicht die Anforderung von 2.000 AVAX im Staking erfüllen, die für Subnet-Validatoren galt. Im Gegenzug zahlen sie eine laufende Gebühr in AVAX. Der Aufbau einer L1 bindet heute weniger Kapital, bedeutet aber weiterhin Validatoren, die jemand betreibt, Guthaben, die jemand überwacht, und Updates, die jemand einspielt.

Diese Updates kommen mit festem Termin. Die VersionAvalancheGo v1.15.0setzte Helicon im Mainnet für den 22. September 2026 an, mit Änderungen wie der asynchronen Ausführung der C-Chain und strengeren Verfügbarkeitsanforderungen an die Validatoren, und war für alle Mainnet-Nodes verpflichtend. Wer auf der C-Chain emittiert, überlässt diese Arbeit dem Netzwerk; wer eine L1 betreibt, muss sie in den eigenen Zeitplan aufnehmen. DieAvalanche-Profilerläutert die Architektur im Detail.

Woran Sie ein gutes Entwicklungsangebot für Avalanche erkennen

Bei der Anwendung des Emittenten liegt die schwierige Arbeit außerhalb des Smart Contracts. Die Zahlung eines Anlegers kann per Banküberweisung eingehen, die Identität wird in einem anderen System geprüft, und die Emission des Tokens muss mit beidem verknüpft sein, ohne doppelt ausgelöst zu werden, wenn eine Benachrichtigung zweimal eintrifft. Ein solides Angebot beschreibt diesen Ablauf, legt fest, was in Smart Contracts programmiert wird und was ein externes System validiert, und weist jedem Operator seine Berechtigungen zu. Ein schwaches Angebot kalkuliert den Token und verschiebt den Abgleich in die Integrationsphase, wo sich dann die Verzögerungen einstellen.

Empfiehlt ein Anbieter eine L1, muss er begründen, warum diese Architektur und keine andere: Welche Anforderung des Emittenten macht die Auswahl der Validatoren nötig, welches Framework schlägt er vor, welche Software liefert er, wie werden die verpflichtenden Updates getestet und wie stimmt er sich mit dem Team ab, das die Anwendung baut. Ebenso wichtig ist, was unter der Kontrolle des Kunden bleibt. Legt das Angebot weder Verfügbarkeit noch Reaktionszeiten bei Vorfällen noch Exit-Bedingungen fest, kauft der Emittent ein Deployment und kein betriebenes Netzwerk. Dieser Unterschied zeigt sich spätestens, wenn einem Validator zum ersten Mal das Guthaben ausgeht oder ein Update mit festem Termin ansteht.

Auch die Nachweise werden getrennt angefordert. Für die Anwendung ein reproduzierbarer Ablauf mit einer korrekten Emission und einer, die einen Eingriff erfordert; für das Netzwerk schriftliche Servicezusagen und Referenzen, die der Kunde selbst überprüfen kann. Eine Fallstudie auf der Website eines Anbieters bleibt eine Werbeaussage, bis jemand aus dem Projekt sie bestätigt.

Metlabs: die Anwendung des Emittenten, auf der C-Chain oder auf einer L1

Metlabs ist ein Blockchain-Entwicklungsstudio mit Büros in A Coruña und Madrid. Wir entwickeln die Anwendung des Emittenten (Zeichnung, Zahlungen, Emission, Verwaltung und Smart Contracts in Solidity) für Unternehmen, die Vermögenswerte auf Avalanche tokenisieren, auf der C-Chain oder auf einer L1, die ein anderer Anbieter betreibt. Unsereigenes technisches Teamverbindet Produktdefinition, Architektur, Smart Contracts, Backend und Oberfläche; das Angebot benennt die Komponenten, Personen und Verantwortlichkeiten, die das gewählte Netzwerk erfordert.

Bei tokenisierten Emissionen in Spanien haben wir die Kooperationsvereinbarungen mitOnyzefür die Integration vonVerwahrungund mitUrsus-3 Capitalfür die Abstimmung mit dem Wertpapierregister veröffentlicht. Die Vereinbarungen erläutern, wie unsere Softwarearbeit mit den übrigen Funktionen einer Emission verbunden ist. Die Verantwortlichen und Dienstleister, die Ihr Projekt benötigt, werden in dessen eigenem Leistungsumfang festgelegt.

Produktentscheidungen und Umfang der Integration

Unser Ansatz fürBlockchain-Entwicklungverbindet die Regeln des Vermögenswerts mit der Nutzererfahrung der Anleger und der Arbeit des Emittenten. Das Angebot legt fest, was in Smart Contracts programmiert wird, was ein externes System validiert und was jeder Operator autorisieren darf. Das Admin-Panel macht diese Unterschiede sichtbar, damit jeder Vorfall einen klar benennbaren Verantwortlichen hat.

Eine hypothetische Kapitalverwaltungsgesellschaft öffnet die Zeichnung eines tokenisierten Fonds, und die Zahlung jedes Anlegers geht per Banküberweisung ein, also off-chain. Die Plattform ordnet diesen Zahlungseingang vor der Emission einer Order zu und unterscheidet eine beantragte Token-Übertragung von einer autorisierten; trifft die Benachrichtigung der Bank zweimal ein, darf sie keine zwei Emissionen auslösen. Die Demonstration dieses Ablaufs prüft neben dem Smart Contract auch Integration und Abgleich und ist auf der C-Chain dieselbe wie auf einer L1.

Umfasst das Projekt eine eigene L1, trennen wir die Entwicklung der Anwendung von Deployment und Betrieb des Netzwerks: Validatoren, Zugang zu Diensten, Updates und Wiederherstellung erfordern einen ausdrücklich definierten operativen Leistungsumfang und einen Anbieter, der ihn übernimmt. Die Bewertung von Metlabs stützt sich auf den reproduzierbaren Ablauf, die Dokumentation der Berechtigungen und die Nachweise zum eingesetzten Team.

Was das Angebot von Metlabs enthalten sollte

• Scope-Dokument, das die Wahl des Netzwerks begründet und die Anwendung des Emittenten von den Leistungen trennt, die für den Betrieb einer dedizierten L1 nötig sind.
• Zeichnungsablauf, bei dem Identität, Dokumentation, Zahlung und Emission mit demselben Auftrag verknüpft sind.
• Administrationspanel mit rollenbasierten Berechtigungen und Abstimmung von Zahlungen, Emissionen und Übertragungsanträgen.
• Tests für doppelte Benachrichtigungen und die Wiederherstellung von Vorgängen, zusammen mit dem Verfahren für Bereitstellung und Wartung.

Die Arbeit folgt den Phasen, die wir in unseremService für Blockchain-Entwicklungerläutern: Discovery, Architektur und Design, iterative Entwicklung und Validierung vor der Produktivsetzung. Zu Projektbeginn vereinbaren wir die erste zu bauende User Journey und ihre Abnahmekriterien, um den Fortschritt anhand einer funktionsfähigen Lieferung zu prüfen. Externe Audits, spezialisierte Integrationen und der anschließende Support werden im Angebot abgegrenzt.

Umden Umfang mit Metlabs zu prüfen, teilen Sie uns den Vermögenswert oder Prozess, seine Nutzer, die bestehenden Systeme und die Vorgänge mit, die die erste Version ermöglichen muss. Mit diesen Informationen können wir Abhängigkeiten identifizieren und ein Angebot vorbereiten, das Sie mit denen anderer Kandidaten vergleichen können.

AvaCloud: Ökosystem-Infrastruktur für den Betrieb einer L1

AvaCloudist die Plattform von Ava Labs, um dedizierte Avalanche-L1s zu starten und zu betreiben. Sie bietet drei Modelle: das Netzwerk in der eigenen Cloud des Kunden (AWS, Azure oder GCP), auf kundeneigener Hardware für Märkte, in denen die Cloud-Nutzung eingeschränkt ist, oder von AvaCloud verwaltet auf Basis eines Service Level Agreements. Sie veröffentlicht konkrete Zusagen, etwa eine Verfügbarkeit von 99,95 % für Netzwerke, deren Validatoren sie verwaltet, undSupport-Stufenmit Reaktionszeiten bei kritischen Vorfällen von 2 Stunden bis 30 Minuten je nach Tarif, und gibt an, dass A-LIGN Prüfungen nach SOC 1 Type II und SOC 2 Type II durchgeführt hat. Sie ist die Referenz für alle, die den Betrieb des Netzwerks an einen Dienstleister abgeben müssen.

Auf ihrer Website nennt sie Progmat als Referenz, dessen Plattform für Security Tokens in Japan auf einer von AvaCloud verwalteten L1 läuft; das ist eine Aussage des Anbieters, die Sie mit eigenen Referenzen überprüfen sollten. Beim Vergleich des Angebots empfiehlt es sich, Plattform, Support, Integration und Anwendung getrennt zu betrachten, da sich der Leistungsumfang auf das Netzwerk und seine Anbindung an die Systeme des Kunden konzentriert. Fordern Sie außerdem Zugriffsbeschränkungen, das Change-Verfahren und die Exit-Bedingungen an: wie der Kunde seine Konfiguration und seine Daten behält und wer handeln kann, wenn der Dienst ausfällt.

Blockchain-Entwicklungsunternehmen für Avalanche wählen: Eine L1 rechtfertigt sich durch Kontrolle und braucht einen Betreiber

Die Anwendung des Emittenten und das dedizierte Netzwerk sind getrennte Aufträge: Den ersten übernimmt ein Entwicklungsteam, den zweiten ein Betreiber mit veröffentlichten Zusagen, sei es der Kunde selbst, ein Infrastrukturanbieter wie AvaCloud oder beide. Ausgangspunkt ist die Frage, ob der Emittent etwas kontrollieren muss, was ihm die C-Chain nicht bietet, etwa welche Stellen validieren, wer sich mit dem Netzwerk verbinden darf, wo die Daten physisch liegen oder mit welchem Token das Gas bezahlt wird. Ist das nicht der Fall, erspart eine Emission auf der C-Chain mit Übertragungsbeschränkungen im Smart Contract den Betrieb eines eigenen Netzwerks.

Ist es der Fall, erfüllt die L1 eine reale Anforderung, verlagert aber einen dauerhaften Betrieb auf den Emittenten: Validatoren mit Guthaben, verpflichtende Updates mit festem Termin und Reaktion auf Vorfälle. Deshalb zählt bei einem Angebot für ein dediziertes Netzwerk auf Avalanche die schriftliche Betriebszusage (Verfügbarkeit, Reaktionszeiten, Exit) mehr als die Geschwindigkeit, mit der das Netzwerk aufgesetzt wird.

Die Demonstration, die Sie zusammen mit dem Angebot anfordern sollten

Die Angebote werden anhand derselben Emission und ihres anschließenden Lebenszyklus verglichen, mit festgelegtem Zahlungsweg, einem korrekten Vorgang und einem, der einen Eingriff erfordert. Zur Beurteilung der Leistungsfähigkeit jedes Teams dient dieallgemeiner Leitfaden zu Blockchain-Entwicklungsunternehmen.

• Emission: Zahlungsreferenz, Freigabe und Schutz vor wiederholten Benachrichtigungen.
• Übertragung: Voraussetzungen des Empfängers, Ablehnung und Protokollierung der Entscheidung.
• Rückzahlung: Genehmigung, Bewegung des Tokens und Abstimmung des Geldabflusses.
• Dediziertes Netzwerk, falls erforderlich: Validatoren und ihre Guthaben, Updates, Support, zugesagte Verfügbarkeit und Betriebskosten getrennt von der Entwicklung.

Auf Avalanche beginnt ein brauchbares Angebot mit der Begründung, warum das Produkt ein eigenes Netzwerk braucht oder nicht.