Nach dem Ende eines Hackathons ist die Zahl der Anmeldungen am leichtesten als Werbeaushängeschild zu verwenden.
@renaissxyz hat kürzlich die Ergebnisse für die erste Tech Hackathon S1 bekannt gegeben: über 70 Teams haben sich angemeldet, 45+ Projekte wurden geliefert, die teilnehmenden Teams kamen aus der ganzen Welt, und die Arbeiten decken Bereiche wie KI-Anwendungen, Entwickler-Tools, Sammlerstücke und RWA ab.
Als ich diese Daten zum ersten Mal sah, dachte ich nicht sofort: „Das Renaiss-Ökosystem ist bereits entstanden“.
Die Einstiegshürde für die Teilnahme an einem Hackathon ist nicht hoch: „Lieferung abgeschlossen“ bedeutet, dass die teilnehmenden Teams ein Werk eingereicht haben, das vorführbar ist—und heißt nicht, dass diese Projekte bereits offiziell in Betrieb sind. Nach dem Wettbewerb aktualisiert ein Teil der Entwickler möglicherweise weiterhin, und andere kehren zu ihrer ursprünglichen Arbeit zurück.
Wenn man diese Daten jedoch in echte Sammel-Assets (RWA) einordnet, verraten sie weiterhin eine Veränderung, die es wert ist, erforscht zu werden: Renaiss wird zunehmend als Entwicklungswerkzeug betrachtet – nicht nur als eine Seite zum Auspacken und Handeln.
Diese beiden Ausrichtungen wirken ähnlich, aber der kommerzielle Spielraum ist völlig unterschiedlich.
Wenn Renaiss nur seine eigenen Nutzer bedient, muss es ständig neue Kartensets, Aktivitäts- und Handelsfunktionen entwickeln – und dann auch selbst nach Traffic suchen. Jede neue Spielweise wird von internem Teamwork erledigt, und das Wachstumstempo wird durch die Teamgröße und die Fähigkeiten im Betrieb begrenzt.
Wenn externe Entwickler auf die bereits aufgebaute Hosting-, Asset- und Abwicklungsfähigkeit zugreifen können, muss Renaiss nicht jede einzelne Art von Sammel-Asset-Produkt selbst entwickeln.
Es muss nur den schwierigsten und am häufigsten wiederholten Teil richtig machen – der Rest kann von anderen darauf aufbauend Spiele, Tools, Community- und Handelsszenarien entwerfen.
Ich glaube, das ist das, was ein Hackathon wirklich verifizieren soll.
Wie viele Leute am Wettbewerb teilnehmen wollen, ist nicht schwer zu zählen. Viel wichtiger ist jedoch, wie viele Menschen entdecken, dass man mit Renaiss tatsächlich einen Umweg spart.
Angenommen, ich möchte ein Sammelspiel mit Sportkarten bauen.
Die Spielmechanik kann relativ simpel sein: Nutzer stellen ihr eigenes Kartenteam zusammen, sammeln Punkte nach realen Wettkampfergebnissen, und nach Ende der Saison kann man die Karten handeln oder zurückfordern.
Wenn es keine fertige Infrastruktur gibt, ist das, was ich zuerst lösen müsste, nicht das Spiel-Interface.
Ich muss bestätigen, ob jede Karte wirklich existiert, wo die Assets liegen, wie nach dem Kauf die Eigentumsverhältnisse dokumentiert werden, wie verhindert wird, dass dieselbe Karte bei der Übertragung zweimal an zwei Personen verkauft wird, und schließlich muss ich die Rückforderung der physischen Gegenstände und die Logistik abwickeln.
Keine dieser Aufgaben erhöht den Spielspaß direkt – aber sie entscheidet darüber, ob das Produkt echte Assets akzeptiert.
Die meisten kleinen Teams schaffen diese Ebene nicht.
Sie sind vielleicht gut in Spielmechaniken, Community-Betrieb oder KI-Anwendungen. Aber sie haben nicht die Fähigkeit, in mehreren Ländern eigene Tresore aufzubauen – und erst recht nicht, um für ein frühes Produkt allein ein vollständiges System für das Hosting von Sammel-Assets zu entwerfen.
Am Ende werden viele Ideen zu einer reinen Ausstellungsseite, oder man verzichtet gleich auf physische Assets und macht nur noch NFTs ohne reale Unterstützung.
Das, was Renaiss bereitstellen will, ist genau der Teil, den Entwickler nicht gern selbst noch einmal aufbauen würden.
Gemäß der Einteilung der Produktarchitektur in den Veranstaltungsunterlagen übernimmt Renaiss.xyz den nutzerorientierten Handel und die Liquidität. Renaiss Layer ist zuständig für die physische Abwicklung, Renaiss OS verbindet Tresore mit dem Sammlerstück-Shop, und Renaiss CLI richtet sich an KI- und Entwickler-Tools.
Unterdessen ist die Renaiss CLI bereits in die Phase des Early Preview eingetreten. Öffentliche Tests zeigen, dass derzeit vor allem Lese-Kommandos wie Karten-/Kartenset- und Marktdatenabfragen freigegeben sind, z. B. über npx renaiss, um Kartensets und Marktinformationen abzufragen. Vollständige Schreib- und Deployment-Fähigkeiten müssen noch auf spätere Versionen warten.
Diese Unterscheidung muss man klarstellen.
Aktuell kommt die CLI noch am ehesten einem Daten-Einstieg für Entwickler gleich – und lässt sich nicht direkt als bereits ausgereifte Plattform für Deployments verstehen. Aber wenn Entwickler im Terminal strukturierte Sammel-Asset-Daten abfragen können, zeigt das zumindest: Renaiss beginnt, interne Datenfähigkeiten in externe Werkzeuge zu überführen.
Wenn man nur Renaiss.xyz, Layer, OS und CLI betrachtet, liegt die Vermutung nahe, dass hier einfach viele Produkte gebaut wurden.
Legt sie in den Arbeitsablauf der Entwickler, dann wird die Logik klarer.
Ein Team kann mithilfe der CLI Karten, Kartensets und Marktdaten auslesen. Mit der bestehenden Asset-Struktur von Renaiss kann es anschließend Sammlerstücke identifizieren, dann bestätigt der Tresor hinter dem OS den physischen Zustand, und Layer übernimmt die finale Auslieferung.
Entwickler denken darüber nach, „warum Nutzer kommen“. Renaiss kümmert sich darum, „warum die von Nutzern erhaltenen Assets vertrauenswürdig sind“.
Das ist eine sehr typische Aufgabenteilung zwischen Plattformen.
Das Problem ist: Die Plattform-Erzählung kann nicht allein durch den Produktnamen funktionieren.
Dass 45+ Projekte ausgeliefert wurden, kann belegen, dass die Entwicklungsrichtung von Renaiss das Interesse einer Reihe von Teams geweckt hat. Es beweist jedoch noch nicht, dass diese Personen es langfristig nutzen werden.
Während des Hackathons gibt es Preisgelder, Mentoren und Deadlines, die das Team vorantreiben. Nach dem Wettbewerb bleiben Entwickler nur für jene Infrastruktur, die wirklich Zeit spart.
Wenn der Aufruf von Renaiss für Entwickler komplizierter ist als das eigene Programmieren, die Dokumentation unvollständig ist, sich die Asset-Schnittstellen ständig ändern oder bei jeder Integration einer Karte jedes Mal der offizielle Support manuell eingreifen muss, dann wird das sogenannte Entwickler-„Plattform“-Modell am Ende wieder zum Kooperationsmodell für Projekte zurückfallen.
Es sieht zwar nach Third-Party aus, aber die Art der Expansion ist komplett unterschiedlich.
Bei Projektkooperationen muss man mit dem Renaiss-Team wirklich eins nach dem anderen sprechen und eine nach der anderen Anbindung durchführen. Eine Entwicklerplattform hingegen erlaubt es fremden Teams, Dokumentation selbst zu lesen, Schnittstellen zu testen, das Deployment abzuschließen und am Ende das Produkt live zu schalten.
Mit der ersten Variante lassen sich ein paar schöne Fallstudien produzieren, aber nur die zweite Variante hat die Chance, die Anzahl der Produkte von der Größe des Teams unabhängiger zu machen.
Daher bewerte ich die Ökosystem-Größe von Renaiss nicht einfach anhand von „45+ Projekten“.
Ich möchte lieber ein paar Monate warten und sehen, wie viele der Hackathon-Arbeiten weiter gepflegt werden, wie viele echte Nutzer hervorbringen und wie viele On-Chain-Aktionen aus Anwendungen stammen, an deren Betrieb das offizielle Renaiss-Team nicht direkt beteiligt ist.
Wenn am Ende nur noch wenige Arbeiten weiterlaufen, hat dieser Hackathon dem Team zumindest dabei geholfen, eine neue Richtung für Produkte zu finden.
Wenn eine Gruppe externer Entwickler wirklich bleibt und anfängt, ihre eigenen Sammler anzuziehen, dann ändert sich die Natur des Ganzen.
Das würde bedeuten, dass Renaiss nicht mehr nur auf die eigene Auspack-Seite angewiesen ist, um Nutzer zu gewinnen. Auch Third-Party-Apps können neue Anforderungen zurück in dasselbe Asset- und Hosting-Netzwerk bringen.
Diese Veränderungen schaffen eine Kette, die länger ist als nur das Wachstum von Nutzern.
Wenn Entwickler zunehmen, nimmt auch die Zahl der Einsatzmöglichkeiten der Sammlerstücke zu. Karten gehen dann nicht nur in den Bereichen Kaufen/Verkaufen und Auspacken auf, sondern könnten auch ins Spiel, in die Community-Identität, in Mitgliedervorteile, in einen KI-Sammlungsassistenten oder in neue Finanzinstrumente gelangen.
Wenn die Spielweisen zunehmen, kann dasselbe reale physische Asset in mehr Szenarien gelangen. Dadurch steigt auch die Nutzungshäufigkeit – was wiederum mehr Tresore, Shops und Entwickler zur Anbindung motiviert.
Dann besteht die Wachstumseinheit von Renaiss nicht mehr nur aus einem neuen Nutzer, sondern auch aus einem Third-Party-Produkt, das kontinuierlich Nutzer hervorbringt.
Natürlich gibt es auch ein klar erkennbares Risiko auf diesem Weg.
Renaiss bietet sowohl eigene Nutzerprodukte als auch bereitet sich darauf vor, Basisinfrastruktur für externe Entwickler zu öffnen. Zukünftig sind Interessenkonflikte unvermeidlich.
Wenn Third-Party-Entwickler eine besonders beliebte Sammlerstück-App entwickeln, würde Renaiss dann ähnliche Funktionen in seiner eigenen Plattform kopieren? Würden offizielle Apps niedrigere Gebühren, bessere Daten oder schnellere Schnittstellen bekommen? Gehören die Nutzerbeziehungen, die durch Entwickler entstehen, am Ende dem App-Team oder Renaiss?
Diese Probleme beeinflussen direkt, ob Entwickler bereit sind, langfristige Kosten zu investieren.
Damit eine Plattform externe Teams beruhigt beim Aufbau unterstützen kann, muss sie stabile Grenzen definieren.
Welche Fähigkeiten gehören zur öffentlichen Basisinfrastruktur, welche Daten können gleichberechtigt genutzt werden, kann die Gebühr plötzlich geändert werden, kann ein Dritter über seine eigenen Nutzer verfügen, verwenden offizielle Produkte und externe Apps die gleichen Regeln?
Wenn die Grenzen nicht klar sind, machen sich Entwickler Sorgen, am Ende selbst Anforderungen für die Plattform zu verifizieren – und dann das Produkt zu verlieren.
Darum ist auch das in den Veranstaltungsunterlagen erwähnte Third-Party-SDK – mehr als das reine Hinzufügen einer neuen Funktion – besonders beachtenswert.
Derzeit befindet sich dieses Third-Party-SDK noch in der „bald verfügbar“-Argumentation; man kann es nicht so formulieren, als sei es bereits offiziell live. Ob es als Nächstes wie geplant geöffnet wird und wie weit diese Öffnung reicht, entscheidet darüber, ob die Hackathon-Projekte weiter wachsen können.
Auch ein SDK ist nicht nur das Zusammenpacken einiger Schnittstellen.
Es steht dafür, ob das Team bereit ist, Fähigkeiten, die bisher nur intern genutzt wurden, so aufzubereiten, dass externe Entwickler sie unabhängig verstehen und aufrufen können – als Standard.
Ein echtes, nutzbares SDK sollte es Entwicklern ermöglichen, Tests und Deployments auch dann durchzuführen, wenn sie die Teammitglieder von Renaiss nicht kennen.
Die Dokumentation ist klar genug, Fehler lassen sich lokalisieren, Test- und Produktionsumgebung verhalten sich konsistent, und ein Interface-Upgrade macht alte Produkte nicht plötzlich unbrauchbar.
Diese Dinge eignen sich nicht als Werbeslogans, entscheiden aber darüber, ob Hackathon-Projekte die ersten Monate nach dem Wettbewerb überhaupt überleben.
Darum glaube ich auch, dass der Wert von über 70 Teams und 45+ ausgelieferten Projekten erst später klar zu erkennen ist.
Ein Hackathon bringt zunächst nur eine Gruppe von Entwicklern vor die Tür. Einige schauen hinein, einige verlassen nach dem Abschluss ihres Projekts wieder, vielleicht entdeckt auch jemand, dass Renaiss die Teile bereits so gebaut hat, die es am wenigsten wiederholen möchte – und entscheidet sich deshalb, zu bleiben.
Die kleine Gruppe danach ist wichtiger als die reine Anmeldedaten-Zahl.
Wenn es in Zukunft ein Sammelspiel, ein KI-Toolset oder ein Community-Produkt gibt, dessen größte Nutzergruppe nicht einmal weiß, was Renaiss ist, aber im Hintergrund dauerhaft die von Renaiss bereitgestellten Asset-, Hosting- und Abwicklungsfähigkeiten nutzt, dann ist Renaisss Infrastruktur-Route wirklich aufgegangen.
Der idealste Zustand ist, dass Entwickler ihren Nutzern nicht jeden Tag erklären müssen, welche Protokolle sie im Unterbau tatsächlich verwenden.
Wie bei normalen Apps, die nicht ständig erklären, welchen Cloud-Dienst sie nutzen: Sammler müssen nur bestätigen, dass die Assets vertrauenswürdig sind, die Transaktion abgewickelt werden kann und die physischen Gegenstände zurückgeholt werden können.
Renaiss ist dabei im Hintergrund versteckt und nimmt für viele unterschiedliche Produkte dieselben Mühen ab.
Darum interessiert mich als Nächstes an Renaiss am meisten nicht, was die offizielle Plattform noch für zusätzliche Spielweisen hinzufügt.
Ich würde am liebsten sehen, ob es in diesen 45+ ausgelieferten Projekten eine App gibt, die von einem externen Team unabhängig betrieben wird, kontinuierlich Updates liefert und echte Sammler anzieht.
Erst wenn Third-Party-Produkte mehr Nutzer bringen als offizielle Aktivitäten, wird Renaiss wirklich von einer reinen Sammel-Asset-Plattform hin zu einer Basisinfrastruktur, die von Sammlungsentwicklern langfristig genutzt werden will.