Spin-Off E · Prototyp
Relay-Deployments per Smart Contract — autorisiert, abgerechnet und gedeckelt
Kein Konto, keine Rechnung, kein Vorstrecken: Der Vertrag hält das Guthaben, gibt den Start frei und rechnet beim Verbrauch ab.
Relay Button on-chain
Der Relay Button startet Infrastruktur auf Knopfdruck. Bezahlt wird sie bisher wie überall sonst — und daran hängt alles Übrige.
Ein Konto, eine Aufladung, ein Vertrauensverhältnis. Genau die Abhängigkeit, die der restliche Stack vermeidet.
Eine App, die ihren Nutzern den Relay-Button anbietet, zahlt erst und rechnet danach ab — manuell, mit Ausfallrisiko.
Ein eingebetteter Startknopf ohne Guthabenprüfung ist eine offene Rechnung für jeden, der ihn findet.
Der Baukasten ist Open Source und wird eingesetzt — aber es gibt keinen Weg, an einem gestarteten Node etwas zu verdienen.
Relay Button on-chain
Ein Vertrag hält das Guthaben und gibt es schrittweise frei — in vier Aufrufen.
approve und deposit mit einem ERC-20-Token. Das Guthaben bleibt beim Nutzer — wir halten es nicht.
reserve(intentHash, amount, expiresAt) — gesperrt für genau dieses Deployment, mit Ablaufdatum.
consume(intentHash, amount) nach dem Start. Abgerechnet wird, was der Node wirklich gekostet hat.
Läuft das Deployment nicht an, gibt refund(intentHash) die Reservierung frei. Niemand muss darum bitten.
Kein Entwurf: Der Client liegt als @le-space/browser im Relay-Button-Monorepo — samt Guthaben-Abfragen, für Base, Avalanche und Ethereum.
Relay Button on-chain
Der eigentliche Gewinn ist nicht die Zahlung, sondern dass der Vertrag entscheidet, ob ein Node überhaupt starten darf.
Der intentHash verknüpft die Reservierung mit genau einem Deployment. Guthaben lässt sich nicht für etwas anderes ausgeben.
Keine Reservierung, kein Start. Die Freigabe hängt nicht mehr an einem Backend, das jemand betreibt und abschalten kann.
Ausgegeben werden kann nur, was eingezahlt wurde. Ein eingebetteter Startknopf kann niemanden mehr überraschen.
Reservierung und Verbrauch sind Transaktionen. Wer wann was gestartet hat, ist prüfbar, ohne dass jemand Buch führt.
Relay Button on-chain
Eine Gebühr pro gestartetem Node — eingezogen im selben Schritt, in dem abgerechnet wird.
Der Vault behält beim consume einen Anteil ein. Kein Inkasso, keine Rechnung, kein Zahlungsausfall.
Jeder Node, den irgendjemand irgendwo über den Baukasten startet, trägt bei — ohne dass wir ihn kennen müssen.
Das Guthaben gehört bis zum Verbrauch dem Nutzer. Wir halten keine Kundengelder — dieselbe Linie wie bei den Spin-Offs B und C.
Wer den Relay Button einbettet, muss nichts mehr vorstrecken. Das ist erst der Grund, warum ihn jemand einbettet.
Relay Button on-chain
Überall dort, wo jemand Infrastruktur braucht, aber kein Verhältnis zu einem Anbieter aufbauen will.
Relay Button on-chain
Die Client-Seite existiert und ist veröffentlicht. Was fehlt, ist der Vertrag dahinter — und die Gebühr darin.
Einzahlen, Reservieren, Verbrauchen, Zurückholen plus Guthaben- und Reservierungsabfragen — in @le-space/browser, für drei EVM-Ketten.
Quellcode, Deployment-Adressen und ein Audit. Ohne das ist der Client ein Schlüssel ohne Schloss.
Der Anteil pro gestartetem Node gehört in den Vertrag, nicht in eine Rechnung. Höhe und Empfänger konfigurierbar.
Laufzeit verlängern, Node stoppen, Reste zurück — und derselbe Vault für weitere Anbieter neben Aleph.
Relay Button on-chain
Vier Punkte, die vor dem ersten echten Guthaben geklärt sein müssen.
Nicht-verwahrend zu bleiben ist die ganze Voraussetzung. Der Vertrag muss so gebaut sein, dass wir das Geld eines Nutzers nie bewegen können — auch nicht versehentlich.
Ein Node kostet in Euro, bezahlt wird in Token. Zwischen Reservierung und Verbrauch kann sich das verschieben — Stablecoin oder Puffer?
Reservieren und Verbrauchen sind zwei Transaktionen. Auf einer L2 ist das vernachlässigbar, auf Ethereum nicht — die Kette ist eine Produktentscheidung.
Wenn ein Vertrag statt eines Menschen den Start freigibt: Wer ist Betreiber dessen, was darauf läuft? Das gehört geklärt, bevor es jemand fragt.
Relay Button on-chain
Gesucht: eine App, die den Relay Button einbetten will, ohne in Vorleistung zu gehen — und jemand, der den Vault-Vertrag mit uns fertigstellt und prüft.
Spin-Off E · prototype
Relay deployments through a smart contract — authorised, settled and capped
No account, no invoice, no fronting the money: the contract holds the balance, releases the launch and settles on consumption.
Relay Button on-chain
The Relay Button launches infrastructure at the press of a button. Paying for it still works like everywhere else — and everything awkward follows from that.
An account, a top-up, a relationship of trust. Exactly the dependency the rest of the stack avoids.
An app offering the Relay Button to its users pays first and bills afterwards — manually, and at its own risk.
An embedded launch button with no balance check is an open tab for anyone who finds it.
The toolkit is open source and gets used — but there is no path to earning anything from a node that was launched.
Relay Button on-chain
A contract holds the balance and releases it step by step. Four calls cover the whole flow.
approve and deposit with an ERC-20 token. The balance stays the user's — we never hold it.
reserve(intentHash, amount, expiresAt) — locked for this one deployment, with an expiry.
consume(intentHash, amount) after the launch. What settles is what the node actually cost.
If the deployment never comes up, refund(intentHash) releases the expired reservation. Nobody has to ask for it.
These four calls are not a design sketch: the client ships as @le-space/browser in the Relay Button monorepo — including balance reads, on Base, Avalanche and Ethereum.
Relay Button on-chain
The real gain is not the payment but that the contract decides whether a node may start at all.
The intentHash ties the reservation to exactly one deployment. The balance cannot be spent on something else.
No reservation, no launch. The go-ahead no longer depends on a backend somebody runs and could switch off.
Only what was deposited can be spent. An embedded launch button can no longer surprise anyone.
Reservation and consumption are transactions. Who launched what and when is verifiable without anyone keeping books.
Relay Button on-chain
A fee per launched node — collected in the same step that settles it.
The vault keeps a share on consume. No collections, no invoice, no bad debt.
Every node anyone launches anywhere through the toolkit contributes — without us needing to know about it.
Until consumption the balance is the user's. We hold no customer funds — the same line as in spin-offs B and C.
Whoever embeds the Relay Button no longer fronts anything. That is what makes embedding it worth doing at all.
Relay Button on-chain
Wherever somebody needs infrastructure but does not want a relationship with a provider.
Relay Button on-chain
The client side exists and is published. What is missing is the contract behind it — and the fee inside it.
Deposit, reserve, consume, refund plus balance and reservation reads — in @le-space/browser, for three EVM chains.
Source, deployment addresses and an audit. Without those the client is a key without a lock.
The share per launched node belongs in the contract, not on an invoice. Rate and recipient configurable.
Extend runtime, stop a node, return the remainder — and the same vault for providers beyond Aleph.
Relay Button on-chain
Four points to settle before the first real balance goes in.
Staying non-custodial is the whole precondition. The contract has to be built so we can never move a user's money — not even by accident.
A node costs in euros and is paid in tokens. Between reservation and consumption that can move — stablecoin or buffer?
Reserving and consuming are two transactions. On an L2 that is negligible, on Ethereum it is not — the chain is a product decision.
When a contract rather than a person releases the launch: who operates what runs on it? That needs an answer before somebody asks.
Relay Button on-chain
Wanted: an app that wants to embed the Relay Button without fronting the cost — and someone to finish and audit the vault contract with us.