Solana-Entwicklungsunternehmen auswählen: Leitfaden 2026

Ein Solana-Projekt kann ein neues Programm erfordern, ein bestehendes integrieren oder die Anwendung umfassen, die der Kunde nutzen wird. Für die Wahl des Unternehmens müssen Sie wissen, welchen Teil des Systems das Team liefern soll und wie es nachweist, dass er funktioniert. Ein Angebot, das sich nur auf dasTokenkonzentriert, kann die Account-Verwaltung, die Signaturen und die Wiederherstellung von Transaktionen auslassen, die das Produkt benötigt.

Aussagekräftig ist der Vergleich von Solana-Teams dort, wo es darum geht, wie sie das Produkt in das Account-Modell des Netzwerks übersetzen und ob sie mit den Werkzeugen von 2026 arbeiten, nicht bei der Zahl der angegebenen Programmiersprachen. Metlabs, Herausgeber dieses Leitfadens, bietet Solana-Entwicklung an und hat ein kommerzielles Interesse an der Beauftragung. Deshalb bewertet der Leitfaden keine Agenturen: Er beschreibt den Stand des Netzwerks, was ein Angebot enthalten muss, und unser eigenes Angebot nach denselben Kriterien. Die technischen Angaben stammen aus der Solana-Dokumentation, dem Anchor-Repository und dem Agave-Client, abgerufen am 8. November 2026.

Solana im November 2026: Anchor 1.x und ein Konsens im Übergang

Die Änderung mit den größten Folgen für ein neues Angebot betrifft Anchor, das Solana-Framework, das den Code zum Lesen und Prüfen der Accounts eines Programms generiert. Die erste stabile Major-Version, 1.0.0, erschien am 2. April 2026; die neueste Version zum 8. November ist1.2.2 vom 28. Oktober. Laut denVersionshinweisen zu 1.0 wurde das TypeScript-Paket umbenannt, das Framework zielt auf Solana 3.x, und Tests werden standardmäßig mit LiteSVM erzeugt, ohne einen lokalen Validator zu starten. Ein Angebot, das nach älteren Anleitungen erstellt wurde, kalkuliert womöglich Werkzeuge und Schritte ein, die nicht mehr empfohlen werden. Fragen Sie daher nach, mit welcher Version das Programm kompiliert wird.

Die Version ist auch für die Sicherheit relevant. Seit 1.0 lehnt Anchor standardmäßig ab, dass derselbe Account in einer Instruktion zweimal als beschreibbar auftaucht, ein Fehler, dessen Vermeidung früher davon abhing, dass der Entwickler die Prüfung von Hand schrieb. Unser Tutorial zuRust und Anchor auf Solanabehandelt diesen Fall. Hinzu kommt ein Compute-Limit: Laut den Konstanten desAgave-Clients stehen jeder Instruktion standardmäßig 200.000 Compute Units zur Verfügung, und eine Transaktion kann höchstens 1.400.000 anfordern. Ein Produkt, das mehrere Vorgänge in einer einzigen Transaktion verkettet, muss innerhalb dieses Budgets konzipiert werden.

Der Konsens befindet sich im Übergang. DieAlpenglow-Vorschlagersetzt den auf Proof of History und TowerBFT basierenden Mechanismus, dessen Finalität rund 12,8 Sekunden dauert, und die Validatoren haben sieim September 2025 angenommen. Annahme und Aktivierung im Mainnet sind unterschiedliche Meilensteine. Hängt die Nutzererfahrung des Produkts davon ab, wann ein Vorgang als abgeschlossen gilt, muss das Angebot festhalten, welches Bestätigungskriterium heute gilt und was bei einer Änderung des Konsenses überprüft wird.

Welche Solana-Erfahrung zu prüfen ist

DieSolana-Dokumentation zu Accountserläutert, wie der von den Programmen genutzte Zustand organisiert ist und welches Programm seine Daten verändern darf. Bei der Beauftragung einer Entwicklung wird diese Struktur zu einer praktischen Frage: Welche Accounts erwartet jede Operation, wer muss signieren und welche Validierungen verhindern die Verwendung eines falschen Accounts?

DieTechnisches Profil von Solanavertieft das Modell des Netzwerks. Bei der Teamauswahl sollte geprüft werden, wie das Team dieses Modell auf einen Geschäftsfall anwendet. Kenntnisse inRustkann für die Programmentwicklung relevant sein, das Angebot muss aber auch die Interaktionen mit derWallet, dem Backend und den Diensten für den Netzwerkzugang abdecken.

Bitten Sie den Kandidaten, eine vollständige Operation einschließlich ihrer Fehlerbedingungen zu erklären. Das ist ein aussagekräftigerer Nachweis als eine Liste von Programmiersprachen: Sie sehen, wie er Berechtigungen, Abhängigkeiten und den Teil des Produkts abgrenzt, der in der Verantwortung des Kunden bleibt.

Metlabs: Programm, Anwendung und Geschäftsregeln

Metlabs ist ein Blockchain-Entwicklungsstudio mit Büros in A Coruña und Madrid. Wir entwickeln Solana-Programme zusammen mit der Anwendung, dem Backend und den Integrationen, die sie nutzen, für Unternehmen, die ein betriebsfähiges Produkt benötigen und nicht nur das Programm. Unsereigenes technisches Teamverbindet Produktdefinition, Architektur, Programme, Backend und Benutzeroberfläche; das Angebot benennt die Komponenten, Personen und Verantwortlichkeiten, die das Projekt erfordert.

Produktentscheidungen und Umfang der Integration

Bei Metlabs gehen wir dieBlockchain-Entwicklungvon der Funktionsweise des Produkts her an. Der Auftrag muss festlegen, welche Regeln on-chain ausgeführt werden müssen, welcher Zustand außerhalb bleibt und wie beide Teile miteinander verbunden sind. Umfasst der Leistungsumfang Solana-Programme, gehört die Definition von Accounts, Berechtigungen und Instruktionen zu dieser Architektur.

Ein Credential-Produkt macht das konkret. Das Ausstellen eines Nachweises ist nur eine Operation: Es muss auch vereinbart werden, wer zur Ausstellung berechtigt ist, wie ein Fehler korrigiert wird, was ein Dritter prüfen kann und welche personenbezogenen Daten off-chain bleiben müssen. Diese Regeln leiten das Programm und die Verwaltungsoberfläche; sie lassen sich nicht allein aus dem gewählten Token-Standard ableiten.

Die Abnahme des Projekts muss diese Aktionen aus der Anwendung heraus durchlaufen und abgelehnte Signaturen, unerwartete Accounts sowie die Wiederherstellung abdecken, wenn das Ergebnis einer Transaktion nicht bekannt ist. Ebenso ist zu vereinbaren, wer die Integrationen wartet und wer die Programme aktualisieren darf, sofern das Design dies zulässt.

Dieser Ansatz passt, wenn das Programm mit einem nutzbaren Produkt und dessen Geschäftssystemen koordiniert werden muss. Das Angebot muss Liefergegenstände, Verantwortliche, Zugang zum Code und Betriebsbedingungen benennen. Dieselben Kriterien sollten beim Vergleich von Metlabs mit anderen Teams gelten; eine spezifische Produktionserfahrung sollte nur zugeschrieben werden, wenn sie dokumentiert werden kann.

Was das Angebot von Metlabs enthalten sollte

• Definition von Accounts, Instruktionen und Berechtigungen, wenn eigene Programme zum Leistungsumfang gehören.
• Prototyp für Ausstellung und Verifizierung, der personenbezogene Daten, die nicht veröffentlicht werden dürfen, off-chain hält.
• Tests für abgelehnte Signaturen, unerwartete Accounts und Operationen, deren Ergebnis erneut abgefragt werden muss.
• Dokumentation von Deployment, Aktualisierungsbefugnissen und Wartung der beauftragten Programme und Integrationen.

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.

Was Sie zum Vergleich von Solana-Angeboten anfordern sollten

Bereiten Sie eine User Journey vor und bitten Sie die Kandidaten, sie in Liefergegenstände zu übersetzen. Hängt ein Teil von einem bereits deployten Programm oder einem externen Dienst ab, muss das Angebot diesen benennen und die Wartung dieser Integration zuweisen.

• Architektur: genutzte Programme, erforderliche Accounts, Signaturen und Aktualisierungsbefugnisse.
• Integration: Wallet, Backend, Netzwerkzugang und Darstellung ausstehender oder fehlgeschlagener Transaktionen.
• Verifizierung: Tests von Berechtigungen und fehlerhaften Eingaben, Code-Review und Behebung der Befunde.
• Versionen: Anchor, Solana-Crates und Testumgebung, mit denen das Programm kompiliert und validiert wird.
• Betrieb und Lieferung: Deployment, Monitoring, Repositories, Dokumentation und Übergabe an das verantwortliche Team.

Dieallgemeine Leitfaden zur Auswahl eines Blockchain-Entwicklungsunternehmensvertieft die Bewertung des Teams. Auf Solana muss ein vergleichbares Angebot zeigen, wie Account-Modell und Produktregeln zusammenhängen, von der Signatur des Nutzers bis zur Wartung des Systems.

Solana-Entwicklungsunternehmen: Entscheidend sind die beschriebenen Accounts, nicht die angegebene Sprache

Rust-Kenntnisse sind eine Eintrittsvoraussetzung, kein Vorteil: Jedes Team, das ein Angebot für Solana abgibt, wird sie angeben. Was ein Angebot unterscheidet, ist, ob es beschreibt, welche Accounts jede Operation erwartet, wer signiert und welche Prüfungen einen falschen Account ablehnen, denn bei Solana wählt der Client, welche Accounts er dem Programm übergibt. Ein Team, das diese Liste für eine reale Operation des Produkts erläutert, hat bereits einen Teil des Designs geleistet; eines, das nur Tools aufzählt, verschiebt diese Arbeit auf die Zeit nach der Vertragsunterzeichnung.

Der zweite Unterschied ist die Aktualität. Da Anchor 1.x seit April stabil ist und eine Änderung des Konsensmechanismus aussteht, bindet ein Angebot, das weder Versionen noch Bestätigungskriterien festlegt, den Kunden an Annahmen, die er nicht kennt. Kein Unternehmen kann versprechen, wann Alpenglow aktiviert wird; es kann aber festhalten, was es dann überprüft und wer das übernimmt. Diese Position im Angebot schützt das Produkt nach der Übergabe.