Question 1

Wie funktioniert die wöchentliche Kündigung wirklich?

Accepted Answer

Beende jede Woche mit einer einzigen Nachricht. Keine Frist, kein Exit-Gespräch, kein Kleingedrucktes. Wir rechnen wöchentlich ab, du bist also maximal die laufende Woche gebunden.

Question 2

Was, wenn die Arbeit mich nicht überzeugt?

Accepted Answer

Es steht in deinem Vertrag: Sag es uns, und wir erstatten diese Woche. Keine Rückfragen, keine Rechnungen zum Streiten, keine Eskalationscalls. Einzige Regel: Erstattungen gelten für die letzte Woche.

Question 3

Warum trackt ihr keine Stunden?

Accepted Answer

Weil Stunden die falsche Metrik sind. Wenn wir auf abrechenbare Stunden optimieren, optimieren wir nicht auf dein Ergebnis. Der Deal ist einfacher: Jede Woche müssen wir die nächste verdienen. Wenn wir das nicht tun, zahlst du nicht. Wir können null Stunden oder sechzig investieren. Was zählt, ist, ob du umgehauen bist.

Question 4

Was bedeutet „Erwartungen losgelöst von der Realität“?

Accepted Answer

Wir arbeiten mit Operators, nicht mit Lottogewinnern. Wenn eine Anforderung Physik, Gesetz oder Drittanbieter-Systeme brechen würde, sagen wir das, und wenn wir uns nicht ausrichten können, gehen wir. Die Garantie ist gegenseitig: Du kannst uns jede Woche feuern; wir können uns auch selbst feuern.

Question 5

Baut ihr Smart Contracts von Grund auf oder forkt ihr bestehende Protokolle?

Accepted Answer

Beides. Wir starten, wo immer möglich, von auditierten, praxiserprobten Patterns (OpenZeppelin, Account-Abstraction-Referenzimplementierungen). Eigene Smart Contracts schreiben wir, wenn der Use Case wirklich neu ist. Greenfield ist manchmal nötig, aber von produktionsbewährtem Code auszugehen ist fast immer der sicherere und günstigere Weg.

Question 6

Wie handhabt ihr Smart-Contract-Sicherheit und Audits?

Accepted Answer

Drei Schichten: defensive Coding-Patterns, umfassende Foundry-/Hardhat-Testsuiten mit Invariant- und Fuzz-Testing, und für alles Custodial ein Third-Party-Audit vor Mainnet. Audit-Zeit und -Budget planen wir ab Tag eins ein, nicht im Nachhinein.

Question 7

Könnt ihr Web2 und Web3 in einem Produkt verbinden?

Accepted Answer

Ja – und genau da liegt der meiste Mehrwert. Account Abstraction (EIP-4337), Social Logins, gaslose Transaktionen und eingebettete Wallets lassen Web3 sich anfühlen wie Web2. Wir haben MetaMask Snaps, AA-Wallets und hybride Backends gebaut, die Krypto-Komplexität für Endnutzer wegabstrahieren und gleichzeitig die On-Chain-Integrität wahren.

Question 8

Auf welchen Chains liefert ihr aktiv aus?

Accepted Answer

EVM: Ethereum L1, L2s (Optimism, Arbitrum, Base, Polygon) und zkSync. Non-EVM: Solana, NEAR, Internet Computer – und überall sonst, wo die Nutzer deiner Kunden tatsächlich sind. Wir sind chain-agnostisch: Wir sagen dir, wann „wir sollten auf Chain X“ stimmt – und wann es Tribalismus ist, der dich Nutzer kostet.

Question 9

Was kostet ein Smart-Contract-Projekt end-to-end?

Accepted Answer

Fokussiertes ERC-20-/NFT-Deployment mit eigener Logik und schlanker dApp: 15.000–35.000 € inkl. Mainnet-Rollout. DeFi-Protokoll mit Custodial-Logik, Integrationen und Third-Party-Audit: 60.000–150.000 €+ – je nach Audit-Scope (Trail of Bits und OpenZeppelin liegen in unterschiedlichen Preisstufen). Produktionsreife AA-Wallets, Bridges oder neue L1-/L2-Infrastruktur: 100.000 €+ und 3–6 Monate. Audit, Gas-Optimierungs-Passes und Post-Launch-Monitoring quotieren wir direkt im Angebot mit, damit der Betrag, den du unterschreibst, der Betrag ist, den du zahlst.

Question 10

Wann sollten wir KEINE Blockchain verwenden?

Accepted Answer

Wenn zentralisierte Infrastruktur das Problem schon löst. Wenn der einzige Grund am Tisch „die Investoren wollen einen Token“ ist. Wenn die UX unter einem Wallet-Handshake leiden würde und du das nicht mit einem echten Werttransfer rechtfertigen kannst. Wenn die Daten nicht zensurresistent, öffentlich verifizierbar oder mit anderen On-Chain-Systemen interoperabel sein müssen. Blockchain-Projekte, die diesen Filter nicht bestehen, nehmen wir nicht an. Das ist für alle billiger.

Question 11

Wie schützt ihr Nutzer vor MEV, Front-Running und Sandwich-Attacks?

Accepted Answer

Auf EVM: private Mempools (Flashbots Protect, MEV Blocker), Commit-Reveal-Schemes, wo Reihenfolge zählt, Batch-Auktionen für Swaps und Slippage-Kontrollen mit sinnvollen Defaults. Für Protokolle mit echtem Volumen routen wir kritische Transaktionen über Flashbots-Bundles, um Inclusion-Attacks zu verhindern. Adversarial-Szenarien modellieren wir in Foundry-Invariants. MEV ist nicht theoretisch – wir behandeln das von Tag eins als First-Class-Threat.

Blockchain

Was wir tun

Wie gehen wir Blockchain-Projekte an?

Bereit einzutauchen?

Wie wir Software entwickeln

Discovery-Phase

Erste Iteration

Folge-Iterationen

Wartung

Weiterentwicklung / Übergabe

Beweise statt Versprechen

Was Kunden sagen

FAQs

Mehr aus KI & Frontier-Tech

Lern uns kennen