Solidity & Smart Contract Engineering
Für Auditoren geschrieben, nicht für die Demo.
Solidity Smart Contracts nach Schweizer Bankenstandard: Begleitend entwickelte Tests, formal dokumentierte Invarianten, zustandsbasiertes Foundry-Fuzzing und Slither-Prüfung bei jedem Commit. Bereit für externe Prüfungen durch führende Audit-Häuser.
N° 01Entwicklungsphilosophie
Contracts werden geschrieben, um geprüft zu werden
In vielen Web3-Projekten wird monatelang Code geschrieben und erst zwei Wochen vor dem geplanten Audit an Tests gedacht. Die Testsuite deckt dann nur die Pfade ab, an die der Autor ohnehin geglaubt hat, die Spezifikation wird nachträglich aus dem Code rekonstruiert, und das Audit-Team verbringt die ersten Tage damit, herauszufinden, was das System eigentlich tun sollte. Sie bezahlen diese Tage zu vollen Audit-Stundensätzen.
Wir entwickeln nach dem umgekehrten Prinzip. Tests und Invarianten entstehen parallel zum Code. Eine Funktion, die schwer zu testen ist, wird refakturiert, solange das Refactoring noch günstig ist. Invarianten werden bei der Entdeckung dokumentiert, nicht am Ende geraten. Slither und Solhint prüfen jeden Commit in der CI/CD-Pipeline, sodass statische Analysebefunde sofort bereinigt werden, statt kurz vor der Deadline zu Notfall-Umbauten zu führen.
Was wir übergeben, ist mehr als Solidity-Code: eine vollständige Spezifikation, eine Rollen- und Vertrauensmatrix, eine formal dokumentierte Invariantenliste mit Zuordnung zu den Tests, ein Bedrohungsmodell (Threat Model), eine transparente Liste bekannter Einschränkungen sowie Deployment- und Rollenübergabe-Runbooks. Ein unabhängiger Auditor kann seine Zeit darauf verwenden, Schwachstellen zu suchen, statt Absichten zu erraten.
N° 02Qualitätssicherung
Unit-Tests prüfen Ahnungen. Fuzzing findet die Wirklichkeit
Ein klassischer Unit-Test überprüft einen Szenarienpfad, den der Entwickler vorab bedacht hat. Das ist notwendig, reicht bei Finanzkontrakten aber keineswegs aus. Relevante Schwachstellen verbergen sich selten in einem einzelnen Funktionsaufruf. Sie entstehen in unerwarteten Abfolgen: Zeichnen, Übertragen, Dividende anfordern, Rückzahlung auslösen — mit einer Pausierung dazwischen und einer Rollenrotation während des laufenden Betriebs.
Zustandsbasiertes Fuzzing (Stateful Fuzzing mit Foundry) deckt genau jene Kombinationen auf, an die niemand gedacht hat. Ein Fuzz-Handler feuert pseudo-zufällige, aber protokollkonforme Transaktionsfolgen gegen das bereitgestellte System ab und überprüft nach jedem einzelnen Schritt unverletzliche Systeminvarianten: Entspricht die Summe aller Salden exakt dem Total Supply? Deckt das Escrow-Guthaben jederzeit alle offenen Erstattungsansprüche ab? Kann kein Anleger zweimal aus derselben Ausschüttung beanspruchen?
Unsere Referenzarchitektur validiert seven zentrale Invarianten in zustandsbasierten Fuzzing-Kampagnen mit je 256 Sequenzen, flankiert von 131 Tests bei 98.3% Zeilenabdeckung und null Slither-Befunden mittlerer oder hoher Priorität.
Zusätzlich setzen wir auf Mutations-Testing: Wir bauen gezielt Defekte in den Code ein und prüfen, ob der jeweilige Test zuverlässig fehlschlägt. Ein Invariantentest, der grün bleibt, weil seine Assertion wirkungslos ist, wiegt in falscher Sicherheit. Mutations-Testing schliesst diese Lücke.
N° 03Fehlerkultur
Zwei von elf Schwachstellen entstanden durch den Fix
Ein unnachgiebiges adverses Review unserer eigenen Referenzarchitektur brachte elf Defekte ans Licht. Zwei davon waren im ursprünglichen Code gar nicht vorhanden: Sie entstanden erst durch den Patch für eine andere Schwachstelle. Die Fehlerbehebung erzeugte neue Risiken.
Genau darauf sind herkömmliche Entwicklungsprozesse selten vorbereitet. Ein Bugfix geniesst den psychologischen Vertrauensvorschuss eines gelösten Problems, betrifft Code, den der Prüfer bereits kennt, und wird unter Zeitdruck oft weniger kritisch hinterfragt. Deshalb prüfen wir jeden Patch genauso feindselig wie den Ursprungscode, validieren ihn gegen die gesamte Invariantenliste und lassen die vollständige Testsuite durchlaufen.
Jeder behobene Fehler hinterlässt einen dedizierten Regressions-Test, benannt nach dem Fehlverhalten, damit dasselbe Muster nicht drei Commits später unbemerkt zurückkehrt. Dies macht die Arbeit nicht automatisch auditiert — das System läuft auf Base Sepolia, und wir deklarieren das transparent. Aber es reduziert die Fehlerzahl, die ein bezahlter externer Prüfer für Sie finden muss.
N° 04Upgradeability
Keine Proxies, eine bewusste Risikoabwägung
Unsere Standard-Referenzarchitektur verzichtet bewusst auf Upgrade-Proxies. Einmal deployed, ist der Bytecode unveränderlich. Wer Unveränderlichkeit als reine Tugend anpreist, verschweigt allerdings die Kosten: Ein nach dem Start entdeckter Fehler kann nicht gepatcht werden, sondern erfordert ein Redeployment und die Migration aller Anleger — was primär eine operative und rechtliche Herausforderung ist.
Das Gegenargument wiegt jedoch schwer: Ein Proxy (UUPS, ERC-1967) ist ein zweites System mit eigenen Fehlermustern. Das Storage-Layout kann durch unbedachte Variablendeklarationen beschädigt werden, der Initializer kann anfällig für Frontrunning sein, und der Upgrade-Schlüssel wird zum wertvollsten Ziel des gesamten Projekts — eine Adresse, die die Geschäftslogik unter den Guthaben aller Investoren austauschen kann.
Welcher Weg der richtige ist, hängt von Ihrer Struktur ab: Eine geschlossene Emission mit festem Regelwerk ist mit unveränderlichen Verträgen meist sicherer aufgestellt. Eine wachsende Plattform, deren Regelwerk sich über Jahre anpassen muss, benötigt transparente Upgrade-Pfade — kombiniert mit Timelocks, institutionellen Multisigs und einem öffentlich dokumentierten Upgrade-Protokoll.
N° 05Architekturentscheidungen
Vier Weichenstellungen, vor dem ersten Test
01
Die Blockchain-Wahl
Solidity-Contracts lassen sich leicht portieren — die zugrundeliegenden Gas-Annahmen nicht. Ein pull-basierter Anspruch, der auf Base wirtschaftlich ist, wird auf Ethereum L1 unbrauchbar, sobald Gas-Kosten den Ausschüttungsbetrag übersteigen. Diese Entscheidung muss vor dem Code fallen.
02
Unveränderte Bibliotheken
OpenZeppelin in fest gepinnten Versionen, niemals modifiziert. Ein lokal veränderter Fork bekannter Bibliotheken ist die gefährlichste Fehlerquelle: Er wirkt vertraut, wird oberflächlich gelesen, und die fatale Abweichung liegt in einer unauffälligen Zeile. Wenn Verhalten abweichen muss, erweitern wir durch Vererbung.
03
Standard-Kompatibilität
Ob CMTA (CMTAT) oder ERC-3643: Die Wahl des Standards legt die Schnittstellen für Verwahrer, Banken und Sekundärmärkte fest. Wir definieren die Interface-Abweichungen vor der ersten Codezeile und dokumentieren sie präzise.
04
Rollen- und Schlüsselarchitektur
Privilegierte Funktionen werden auf separate Rollen mit unterschiedlichem Schadenspotenzial aufgeteilt: Der Schlüssel, der eine Einzelposition wiederherstellen kann, kann keine neuen Anteile drucken; der Schlüssel, der den Handel pausiert, kann keine Gelder verschieben. Übergaben an Ihr institutionelles Multisig erfolgen mit Ankündigungsfrist.
Investition
Fester Umfang. Kein Abdriften.
Ab CHF 35.000 — Smart-Contract-Suite mit Invariantentests, Spezifikation und Audit-Bereitschaft.
- Solidity-Codebasis mit begleitend geschriebener Testsuite
- Formal dokumentierte Invarianten und zustandsbasierte Fuzzing-Kampagnen
- Mutations-Testing zur Verifikation der Test- und Invariantenschärfe
- Slither- und Solhint-Statikanalyse als CI-Gatekeeper
- Vollständige technische Spezifikation und Rollen-Matrix
- Bedrohungsmodell, Known-Issues-Katalog und Audit-Scope-Dossier
- Testnet-Deployment mit verifiziertem Sourcecode
- Deployment- und Rollenübergabe-Runbooks für institutionelle Multisigs
- Festpreisangebot nach technischer Discovery
- 30 Tage Gewährleistung auf Implementierungsfehler
Fragen
Die Antworten, die wir am häufigsten geben.
- Welche Testabdeckung streben Sie für Smart Contracts an?
- Wir zielen auf über 95 % Zeilenabdeckung auf Vertragsebene; unsere Referenzarchitektur liegt bei 98.3% über 131 Tests. Eine reine Prozentzahl sagt jedoch wenig aus: Ein Test ohne strikte Assertions erreicht mühelos 100 % Abdeckung, ohne einen einzigen Fehler zu fangen. Deshalb weisen wir Branch-Coverage aus, führen formal dokumentierte Invariantenlisten und validieren diese durch Mutations-Testing.
- Schreiben Sie die Tests oder übernimmt das unser Team?
- Wir schreiben die vollständige Testsuite begleitend zur Implementierung. Tests sind kein nachträglicher Prüfschritt, sondern das Werkzeug, mit dem die Architektur gehärtet wird, solange Änderungen noch günstig sind. Bei der Übergabe erhält Ihr Team den Fuzzing-Handler und die Eigenschaftsdefinitionen, sodass Sie die Testkampagnen künftig eigenständig erweitern können.
- Was geschieht, wenn ein externes Sicherheitsaudit Befunde liefert?
- Wir beheben die Befunde. Befunde mittlerer, hoher oder kritischer Schwere in unserem Code bereinigen wir innerhalb der Gewährleistungsfrist ohne Zusatzkosten. Handelt es sich um geänderte regulatorische Anforderungen Ihrer Rechtsberatung, kalkulieren wir den Aufwand transparent als Zusatzpaket.
- Bauen Sie upgradefähige Smart Contracts (Proxies)?
- Ja, wenn die Anforderungen des Projekts dies erfordern. Wir wägen die Vor- und Nachteile gemeinsam mit Ihnen ab. Unser Standard ist klein und unveränderlich, da eine kleinere Angriffsfläche leichter zu prüfen ist. Wenn Proxies nötig sind, implementieren wir sie nach OpenZeppelin-Standards mit Timelock, Multisig und schriftlichem Upgrade-Prozedere.
- Für welche Blockchains entwickeln Sie?
- Wir konzentrieren uns auf EVM-kompatible Blockchains. Base und Arbitrum sind unsere Standard-Empfehlungen für Systeme mit regelmässigen Anleger-Claims; Ethereum L1 für institutionelle Primäremissionen mit hohem Gegenpartei-Anspruch. Solana nutzt ein grundlegend anderes Kontomodell und Rust; hierfür empfehlen wir spezialisierte Rust-Teams.
- Können Sie eine bestehende Codebasis übernehmen und fit für ein Audit machen?
- Ja, im Rahmen eines ein- bis zweiwöchigen Code-Assessments. Wir analysieren die Verträge, verfassen die Spezifikation, bringen die Testsuite zum Laufen und führen statische Analysen durch. Das Ergebnis ist ein detaillierter Bericht, der aufzeigt, was das System tut, wo Risiken liegen und ob eine Erweiterung günstiger ist als ein Neuanfang.
- Mit welchen Schweizer Audit-Häusern arbeiten Sie zusammen?
- Wir bereiten Codebasen für führende internationale und Schweizer Prüfunternehmen vor, darunter ChainSecurity in Zürich, OpenZeppelin, Spearbit und Ackee Blockchain. Wir stehen in direktem Austausch mit den Audit-Teams während des Review-Fensters, um technische Fragen umgehend zu beantworten.
Nächster Schritt
Nachträglich geschriebene Tests beweisen nur, dass der Code tut, was er tut.
Nennen Sie uns die Anforderungen an Ihre Smart Contracts, die gewünschte Schlüsselarchitektur und Ihren Zeitplan.