Wie Sie 2026 ein Ethereum-Entwicklungsunternehmen auswählen

Bevor Sie ein Angebot für ein Ethereum-Produkt anfragen, stehen zwei Entscheidungen an, die den restlichen Auftrag bestimmen: ob die Smart Contracts auf dem Ethereum-Mainnet oder auf einemLayer 2laufen und wer nach dem Deployment die Befugnis behält, sie zu ändern. Die erste legt die Kosten pro Transaktion fest und das Netzwerk, auf dem die Tests gemessen werden; die zweite entscheidet, wie sehr der Nutzer dem Betreiber des Systems vertrauen muss. Ein Team, das Solidity beherrscht, kann ein Angebot vorlegen, ohne eine der beiden geklärt zu haben.

Deshalb vergleicht man ein Angebot für Ethereum danach, wie es diese beiden Entscheidungen beantwortet und ob es das Netzwerk auf dem Stand von November 2026 abbildet, nicht nach der Liste der Token-Standards, die es aufzählt. Metlabs gibt diesen Leitfaden heraus und erbringt Entwicklungsleistungen für Ethereum, hat also ein kommerzielles Interesse an der Beauftragung. Der Leitfaden erstellt kein Ranking von Unternehmen, sondern erklärt, was ein Angebot enthalten sollte, und stellt unseres nach denselben Kriterien vor. Die Netzwerkdaten stammen aus der Ethereum-Dokumentation, den Ankündigungen der Ethereum Foundation und den veröffentlichten Solidity-Versionen, abgerufen am 8. November 2026.

Ethereum im November 2026: Fusaka aktiv, Glamsterdam ohne Mainnet-Termin

Das letzte auf dem Mainnet aktive Upgrade ist Fusaka. Es wurde am 3. Dezember 2025 aktiviert und brachte PeerDAS, ein neues Verfahren zur Prüfung der Verfügbarkeit der Daten, die Layer-2-Netzwerke veröffentlichen. Laut derAnkündigung der Ethereum Foundationerhöhten zwei spätere Anpassungen die Kapazität auf ein Ziel von 14 Blobs pro Block, gültig seit dem 7. Januar 2026. Für ein auf einem Layer 2 deploytes Produkt ist diese Kapazität Teil der Kosten: Der Layer 2 veröffentlicht seine Daten auf Ethereum in Form von Blobs, und eine Schätzung mit den Parametern von 2024 bildet nicht mehr ab, was heute zu zahlen ist. Unser Artikel überEIP-4844 und Blobserklärt den Mechanismus.

Das nächste Upgrade, Glamsterdam, ist seit dem 6. Oktober 2026 im Testnetz Sepolia aktiv. Die Aktivierung in Hoodi, geplant für den 26. Oktober, istohne neuen Termin verschobenworden, damit geprüft werden kann, wie EIP-8037, das die Gaskosten für das Anlegen von State erhöht, mit Mainnet-Contracts interagiert. Einen Mainnet-Termin gibt es nicht. Wer ein Produkt in Auftrag gibt, das für jeden Nutzer einen Eintrag oder ein Guthaben anlegt, muss mit einer konkreten Folge rechnen: Die heute gemessenen Kosten dieser Operation können sich mit der Aktivierung von Glamsterdam ändern, und das Angebot muss angeben, auf welcher Netzwerkversion es sie berechnet hat.

Auch der Compiler entwickelt sich weiter. Seit derSolidity-Version 0.8.31vom Dezember 2025 ist osaka die Standard-EVM-Version, während jeder Layer 2 die Ethereum-Upgrades nach eigenem Zeitplan übernimmt. „EVM-kompatibel“ sagt nichts darüber, mit welcher Version, sodass sich ein mit Standardeinstellungen kompilierter Contract auf dem Mainnet und auf dem gewählten Layer 2 unterschiedlich verhalten kann. Der Artikel überDencun und die Änderungen an der EVMzeigt einen solchen Fall; für ein Angebot genügt es zu verlangen, dass es die Compiler-Version und die Ziel-EVM für jedes Netzwerk festlegt.

Was jedes Angebot zum Umfang klären muss

DieEthereum-DokumentationbeschreibtSmart Contractsals Programme, die Daten vorhalten und Funktionen im Netzwerk ausführen. Bei einer Beauftragung kommt es darauf an festzulegen, welche Geschäftsregeln sie ausführen sollen und welche Informationen sie aus externen Systemen erhalten. Eine Benutzeroberfläche und ein bereitgestellter Smart Contract klären dieses Zusammenspiel nicht von selbst.

Das Angebot muss außerdem das Zielnetzwerk benennen. Ein Projekt auf dem Ethereum-Mainnet hat einen anderen Ausführungskontext als eine Anwendung auf einemLayer 2. Wird eine Alternative vorgeschlagen, ist ihre Auswirkung auf die Integrationen, die Bewegungen von Vermögenswerten und den Betrieb zu erläutern. DerEthereum-Profilvertieft den technischen Kontext, ersetzt diese Entscheidung über den Umfang aber nicht.

Metlabs: Smart Contracts, die mit dem Produkt verbunden sind

Metlabs ist ein Blockchain-Entwicklungsstudio mit Büros in A Coruña und Madrid. Wir entwickeln Smart Contracts in Solidity, die mit der Anwendung, dem Backend und den Geschäftssystemen verbunden sind, für Unternehmen, die ein Produkt auf Ethereum oder einem Layer 2 einführen. 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.

Produktentscheidungen und Umfang der Integration

Bei Metlabs planen wir dieBlockchain-Entwicklungausgehend von den Aktionen, die jeder Beteiligte ausführen muss. Der Umfang verbindet Geschäftsregeln, Smart Contracts, Benutzeroberfläche und bestehende Systeme. Für Ethereum muss schriftlich festgehalten sein, wer jede Transaktion signiert, welche Befugnisse die Administration behält und wie geprüft wird, dass das Produkt seine Regeln nach dem Deployment einhält.

Ein Dienst, der Zahlungen bei Erreichen eines Meilensteins freigibt, macht den Auftrag konkret. Zu vereinbaren ist, wer diesen Meilenstein bestätigt, was bei Uneinigkeit beider Parteien geschieht und wie ein ausstehender Vorgang dargestellt wird. Hängt die Bedingung von externen Daten ab, muss das Angebot deren Quelle benennen und festlegen, was geschieht, wenn sie nicht verfügbar sind. Das ist ein Designbeispiel, kein Ergebnis, das sich automatisch dem Netzwerk zuschreiben lässt.

Die Validierung muss diese Bedingungen aus Anwendung und Smart Contract heraus abdecken. Ebenso sind Zugriff auf das Repository, Deployment-Verfahren und Kontrolle der Administratorrechte zu vereinbaren. Gibt es eine externe Sicherheitsprüfung, wird ihre Version abgegrenzt und die Behebung der Befunde zugewiesen; Code zu veröffentlichen und ein Audit zu beauftragen sind unterschiedliche Leistungen.

Dieser Ansatz passt zu Teams, die eine Anwendung und ihre Geschäftsintegrationen koordinieren müssen. Für einen Eingriff in ein Protokoll oder in Node-Software werden Umfang und Engineering-Profil gesondert bewertet. Das Angebot von Metlabs ist an denselben Abnahme- und Wartungsbedingungen zu messen, die auch von anderen Kandidaten verlangt werden.

Was das Angebot von Metlabs enthalten sollte

• Spezifikation von Smart Contracts, Rollen und Bedingungen für Freigabe, Ablehnung oder Rückabwicklung einer Transaktion.
• Prototyp der Anwendung, verbunden mit Wallets und mit den Systemen, die externe Informationen liefern.
• Tests von Berechtigungen, Zuständen und Integrationsfehlern, mit identifizierter Version der Smart Contracts für die Prüfung.
• Übergabe von Repository, Deployment-Dokumentation und Kontrolle der Administratorschlüssel gemäß dem vereinbarten Umfang.

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 soll. Mit diesen Informationen können wir Abhängigkeiten erkennen und ein Angebot erstellen, das Sie mit denen anderer Anbieter vergleichen können.

Team, Kostenvoranschlag und Lieferung bewerten

Geben Sie allen Kandidaten dasselbe Lastenheft und verlangen Sie überprüfbare Meilensteine. Produktionsreferenzen müssen der beschriebenen Arbeit und dem beschriebenen Team entsprechen, mit Erlaubnis zur Einsichtnahme. Ein bekannter Name im Ökosystem ersetzt nicht die Prüfung, wer den Auftrag tatsächlich ausführt.

• Architektur: Zielnetzwerk, in Smart Contracts ausgeführte Regeln und Off-Chain-Abhängigkeiten.
• Berechtigungen: Signaturen, Administration, Schlüsselverwahrung und, sofern vorhanden, Upgrade-Befugnisse.
• Verifizierung: Tests der Nutzerabläufe, Fehlerszenarien und Umfang externer Prüfungen.
• Versionen: Compiler, Ziel-EVM und Testnetz, auf dem Tests und Gaskosten gemessen wurden.
• Lieferung und Betrieb: Repositories, Deployment, Incident-Tracking, Wartung und Übergabe.

Dieallgemeine Leitfaden zur Auswahl eines Blockchain-Entwicklungsunternehmenserweitert die Kriterien für die Bewertung des Teams. Bei Ethereum geht der Vergleich von einer konkreten Verantwortung aus: eine Anwendung liefern, Infrastruktur entwickeln oder am Protokoll arbeiten. Das Angebot lässt sich erst bewerten, wenn diese Abgrenzung feststeht.

Was bei der Wahl eines Ethereum-Entwicklungsunternehmens entscheidet: das Zielnetzwerk und wer die Smart Contracts ändern kann

Token-Standards und Entwicklungswerkzeuge sind jedem Team gemeinsam, das mit Solidity arbeitet, und eignen sich daher nicht, um ein Angebot vom anderen zu unterscheiden. Unterscheiden lassen sich Angebote vielmehr daran, ob sie das Zielnetzwerk mit seiner Version benennen und ob ihre Kosten datiert sind: Da Fusaka bereits aktiv ist und Glamsterdam noch aussteht, verlagert eine Schätzung ohne schriftlich festgehaltene Annahmen einen Prüfaufwand, der erst nach Vertragsunterzeichnung sichtbar wird, auf den Kunden.

Der zweite Unterschied liegt in der Verteilung der administrativen Befugnisse. Ein upgradefähiger Smart Contract erlaubt es, Fehler zu korrigieren, bündelt dafür aber Macht bei demjenigen, der das Upgrade signiert; ein unveränderlicher Smart Contract beseitigt dieses Risiko und erfordert für jede Änderung das Deployment eines neuen. Keine der beiden Optionen ist an sich besser. Ein gutes Angebot entscheidet sich für eine, begründet die Wahl und hält schriftlich fest, wer diese Schlüssel nach Abschluss der Entwicklung hält, denn diese Verantwortung besteht so lange wie das Produkt.