DeFi whitepaper, 13 augustus 2020

De belangrijkste innovatie van blockchain was misschien wel de mogelijkheid om open netwerken te creëren die economisch zelfprikkelend zijn — organisch in de vorm van “mining”. Met deze innovatie kan een community van node-draaiers geprikkeld worden om deel te nemen vanaf de vroegste stadia van het netwerk, alsook om het netwerk op te schalen (op zijn minst zijn veiligheid) om veilig transacties van miljarden dollars aan waarde uit te voeren.

Maar het creëren van een onbeheerd DLT-netwerk dat geschikt is voor DeFi vereist meer dan slechts node-draaiers die de infrastructuur van laag niveau bieden. Er moet een florerend ontwikkelaarsecosysteem zijn die het soort van nuttige, interoperationele componenten creëert die de Radix Engine en de Componentencatalogus mogelijk maken.

Ontwikkelaarsroyalties

Hoewel traditionele methoden van het doen groeien van een ontwikkelaarsecosysteem kunnen werken geloven we dat gedecentraliseerde zelf-prikkeling van ontwikkelaars een doorbraak kan creëren in snelle gedecentraliseerde ecosysteemgroei, dezelfde soort markt creërend die gebaseerd is op prikkelingen als mining. De Radix Engine en de Componentencatalogus maken dit voor de eerste keer mogelijk; we noemen dit het ontwikkelaarsroyaltysysteem.

Het kernconcept is dat de ontwikkelaar van elk component een specifieke royalty in RADIX-tokens kan specificeren (het eigen Radix gebruikstoken dat al wordt gebruikt voor transactiekosten voor node-draaiers) voor elk gebruik van die component in een transactie.

Neem er notie van dat dit geen app-store is waar men moet betalen voor toegang tot componenten; het is een volledig per-transactie-gebruik-prijs id emoet worden ingesloten in de transactie zelf. Dit betkeent dat betaling van royalties is gebaseerd op het werkelijke gebruik dat de component naar het netwerk brengt.

Het Radix-protocol zelf is in staat om de juiste royalty-kosten te berekenen en in rekening te brengen, op dezelfde manier dat het de kosten voor node-draaiers afhandelt, want de Componentencatalogus en de diverse typen van componentgebruik zijn allemaal on-ledger. Als een ontwikkelaar een heel nuttige, modulaire, interoperationele component aan de catalogus toevoegt verzekert Radix dat hij op een volledig gedecentraliseerde manier beloond wordt voor de transacties die mogelijk worden gemaakt door zijn werk. Dit is een unieke eigenschap van de Radix Engine ontwikkelingsomgeving die het Radix-netwerk in staat stelt om voor de eerste keer een ontwikkelaarscommunity zelf te prikkelen.

Hoe royalty-instellingen werken voor ontwikkelaars

De fundamentele innovatie achter de Radix ontwikkelaarsroyalties is de on-ledger Componentencatalogus en het daaraan gelieerde on-ledger mechanisme voor componentengebruik om applicaties en transacties te creëren. Daarmee verbindt het Radix-protocol direct royalty-definitie (door de ontwikkelaar) met royalty-betaling (door de gebruiker), een open marktplaats creërend voor netwerkgebruik, gecreëerd door ontwikkelaars. Op deze marktplaats worden royaltybetalingen op een per-transactiegebruik-basis geautomatiseerd en gegarandeerd door exact hetzelfde consensusmechanisme dat de Radix-netwerkveiligheid garandeert.

Ontwikkelaars moeten de instrumenten hebben om deel te nemen aan deze on-ledger marktplaats op welke manier ze dan ook prefereren. We starten met het mogelijk maken voor de ontwikkelaar om een andere royalty in te stellen voor elk van de verschillende typen van componentengebruik, wat mogelijk is eenmaal de component is toegevoegd aan de catalogus4. Dit zijn:

1. DIRECT CONCREET GEBRUIK — Dit is wanneer een gebruikerstransactie direct toegank heeft tot een Action van een concrete component. Dit kan bijvoorbeeld de interface naar een DeFi-applicatie als CFMM (constante functie marktmaker) zijn, zelfs wanneer deze component andere componenten achter de schermen gebruikt.

2. GEREFEREERD CONCREET GEBRUIK — Wanneer een component direct wordt gebruikt, zoals in #1, kan hij specificeren dat meerdere andere concrete componenten ingesloten moeten worden in de Action voor de transactie. Dit is “gerefereerd” concreet gebruik. Een DeFi-aplicatie kan bijvoorbeeld een concrete orakelcomponent gebruiken om toegang te krijgen tot zijn data middels referentie voor een bepaalde transactie.

3. CATALOGUSGEBRUIK — Iedere concrete component is gelieerd aan een originele sjablooncomponent in de catalogus. De royalty voor catalogusgebruik wordt betaald wanneer één van deze cataloguscomponenten de basis vormt voor een actieve, concrete component die wordt gebruikt als in #1 en #2.

4. GEIMPORTEERD GEBRUIK — Dit refereert aan het gebruik wanneer een ontwikkelaar een bestaande cataloguscomponent importeert in zijn eigen nieuwe cataloguscomponent. Zoals in #3 wordt het importeren zelf niet betaald, maar veeleer wordt de geïmporteerde component beschouwd als gebruikt wanneer een andere cataloguscomponent die voorgenoemde importeerde wordt gebruikt als in #3.

Neem er notie van dat er hier twee typen van gebruik zijn, geïndiceerd door de groene en blauwe kleuren. Een ontwikkelaar zou de royalties voor CATALOGUS en GEIMPORTEERD GEDBRUIK specificeren wanneer de component is geïnstalleerd in de catalogus. Deze kunnen gezien worden als de royalties voor het gebruik van componenten achter de schermen. Royalties voor DIRECT CONCREET en REFEREERD CONCREET GEBRUIK zouden gespecificeerd worden op het moment dat een component concreet wordt. Dit zijn de royalties voor het gebruik van de Actions van iedere actieve, onafhankelijke kopie van een component uit de catalogus.

Voor iedere transactie die de Action van een concrete component gebruikt zal er een gelieerde set van royalties zijn voor die concreetheid, elke andere gerefereerde concreetheid, en de diverse catalogussjablonen die zich achter de concreetheden bevinden. Het is uiteindelijk deze volledige set van componenten die de transactie mogelijk maakte.

De vier typen van gebruik kunnen in dit voorbeeld gezien worden voor een enkele transactie die een gebruiker verzoekt aan Dans gemodificeerde CFMM:

Een gebruikerstransactieverzoek aan een Action van Dans gemodificeerde CFMM (en concrete component) moet de opgesomde royaltyprijzen omvatten van de gelieerde componenten, volgens gebruikstype. Deze opgesomde prijzen worden gemakkelijk gedetermineerd door de Radix Engine zodat een gebruiks-app weet wat hij moet betalen, en om te verzekeren dat alle royalties correct worden uitbetaald.

Ontwikkelaars kunnen hun eigen royalties aanpassen voor elk gebruikstype naar de aard van wat ze bouwen en hoe ze verwachten dat het gebruikt zal worden. We geloven dat dit een substantiële flexibiliteit opent voor het creëren van gedecentraliseerde on-ledger inkomstenstromen en bedrijfsmodellen, alsook royalty-vrij gebruik waar gewenst mogelijk maakt. Later worden enkele voorbeeldcasussen gegeven.

Daarbij maakt het royaltysysteem het ontwikkelaars mogelijk om specifieke prijzen in te stellen (voor elk van de vier gebruikstypen) voor specifieke andere ontwikkelaars (via ontwikkelaars-ID) of componenten (via component-ID). Een ontwikkelaar kan bijvoorbeeld gebruik met een korting op de royalty-prijsstelling aan willen bieden wanneer een DeFi-app waarvan hij verwacht dat die een ongebruikelijk hoog gebruiksvolume zal hebben toegang krijgt. Of misschien wil de ontwikkelaar eenvoudigweg de royalty op zijn componenten verwijderen wanneer er toegang is door een andere component die hij zelf heeft gebouwd, terwijl de royalty intact blijft wanneer anderen ervan gebruik maken.

Het updaten van royalty-prijsstelling is ook mogelijk. Zoals met alle andere component-updates heeft dit een revisie-update nodig. Zoals beschreven blijven eerdere versies echter (met eerdere royalties) onveranderlijk en beschikbaar voor gebruik. Iedereen die een nieuwere versie van een component wil gebruiken zou ook de set van geassocieerde royalties daarmee accepteren.

Met het definiëren van de geassocieerde set van royalties bij iedere component heeft het Radix-protocol alles wat nodig is om automatisch de royalties te berekenen en te adresseren die een transactiecreëerder moet betalen voor die transactie. Een voorbeeld kan de creatie van componenten en de inschatting van royalties in een transactie duidelijker maken.

Componentcreatie en royaltyvoorbeeld

Laten we het voorbeeld nemen van Dan: hij wil een DeFi-dienst creëren rond een constante functie marktmaker- (CFMM-)component waarover hij enkele slimme ideeën heeft.

Hij zou dat hele ding vanaf niets kunnen opbouwen, maar hij zoekt eerst in de component-catalogus om te kijken of er al bestaande bewezen oplossingen zijn voor elk deel van het probleem. Eén deel van de CFMM is een aandeel-pool waar een specifiek token wordt gemunt in ruil voor andere tokens die worden bijgedragen aan de pool (in verhouding met de pool-reserves). Gelukkig heeft al iemand een deel-pool-component gebouwd die veel mensen tevreden en veilig lijken te gebruiken van de component-catalogus.

Dan concretiseert de aandeel-pool voor zichzelf, past deze aan door het reserve-token dat kan worden bijgedragen in te stellen (een A-token dat al is geconcretiseerd door Alice) en het aandeel-token dat gemunt kan worden in ruil voor bijdragen (een D-token dat Dan zelf al heeft geconcretiseerd).

Dan stuurt een API-verzoek naar de Radix-ledger om een aandeel-pool te configureren en concretiseren van de component-catalogus. Zijn geconcretiseerde pool is dan actief voor gebruik samen met bestaande tokencomponenten die hij zal gebruiken.

Dan heeft ook een prijsorakel nodig om de huidige marktprijs te krijgen voor het A-token om te gebruiken als deel van zijn CFMM’s interne economielogica. Gelukkig heeft Bob al een leuk en speciaal prijsorakel-component gecreëerd en geconcretiseerd, welke Bob voedt met een variëteit aan marktdata voor verschillende tokens. Dan overweegt dat de GEREFEREERD-royalty die Bob rekent voor het orakel redelijk is en dus kan hij gewoon de actie gebruiken van deze concrete component, zoals die is, om de prijsdata te krijgen die hij nodig heeft.

Dan schrijft daarna de Scrypto-code voor zijn CFMM, (onder andere) een “bijdrage A-token”-actie definiërend. Deze actie-Scrypto-definitie sluit in dat bepaalde Acties gebruikt moeten worden op het A-token, zijn gedeelde pool, zijn D-token en Bobs speciale prijsorakel.

Hij hoeft geen enkele van deze componenten te importeren; hij kan zijn eigen bijdrage-actie implementeren zodat transacties die voorgenoemde gebruiken deze andere component-acties omvatten als gerefereerd gebruik (zo hun desbetreffende GEREFEREERDE royalties aan die transactie toepassend).

Dan stelt een royalty in voor zijn CFMM, stuurt zijn Scrypto-code naar het netwerk en concretiseert hem. Misschien creëert hij een web-UI als front-end-app om gebruikers in staat te stellen transacties te doen bij gebruik.

Een transactie met gebruik van Dans CFMM zou er ongeveer uitzien als onderstaande illustratie. Het gebruikersverzoek van Dans frontend-app, links, wordt vertaald door de DFMM, en de andere componenten waarnaar deze verwijst, naar een correcte set van resulterende uitvoerdataveranderingen rechts (aangenomen natuurlijk dat de transactie voldoet aan de restricties van alle betrokken acties).

Een voorbeeld van transactie waar één component (Dans CFMM) het gebruik specificeert van vier andere geconcretiseerde componenten die automatisch, atomisch samengesteld zijn om een enkel uitvoer-staatresultaat te creëren.

De royalty die de gebruiker moet betalen voor deze transactie wordt eerst berekend door de royalties op te tellen voor elk van de componenten in de catalogus die deel uit maakten van de transactie. Dit omvat de CFMM-component die Dan creëerde, de tokendefinitie-component waarvan de tokens sub-componenten zijn (aangeboden zonder royalty door de Radix Foundation), en zowel het speciale prijsorakel-component en de prijsorakel-component die deze importeerde. (Zie de componenten als eerder getoond in dit document). Dan worden de node-draaierkosten toegevoegd om de uiteindelijke prijs te bepalen:

Hoewel het complex kan lijken zoals het op deze manier wordt opgesomd kan een front-end-applicatie de Radix Engine gebruiken om vooraf automatisch de volledig vereiste kosten te bepalen voor een bepaalde transactie.

Het ontwikkelaars-royalty-systeem creëert een sterke prikkel voor ontwikkelaars om, zo vroeg mogelijk, assertief de nuttigste functionaliteit die ze kunnen bedenken uit te bouwen om de ingebruikname van hun componenten te maximaliseren. Een ontwikkelaar hoeft geen volledige complexe applicatie te bouwen om een punt te bereiken waar zijn moeite kan worden beloond; het kan zelfs waardevoller zijn om componenten te bouwen die één ding heel goed doen en sterk modulair zijn om hun bruikbaarheid voor anderen te maximaliseren. Deze componenten kunnen als resultaat nieuwe standaarden worden van het platform wanneer breed ingebruikgenomen.

De ontwikkelaarsgids voor het Radix-universum

De componentcatalogus en ontwikkelaarsroyalties bieden de fundamenten van een volledig gedecentraliseerde marktplaats voor componentontwikkeling. Aan marktzijde kunnen componentontwikkelaars vrijelijk deze toevoegen aan de catalogus en hun eigen per-transactie-royalties instellen voor bekrachtiging door het Radix-protocol. Aan de andere zijde hebben ontwikkelaars die die componenten willen gebruiken toegang tot onveranderlijke on-ledger data die ze vertelt wat de transactiekosten zullen zijn voor een bepaalde component, hoe breed deze wordt gebruikt, zijn versiegeschiedenis (volledig open source) en welke componenten zijn geassocieerd met een bepaalde ontwikkelaars-identiteit.

Terwijl alle juiste data on-ledger beschikbaar is om deze gemakkelijk zoekbaar, browsebaar en visualiseerbaar te maken vereist dit een juiste font-end-service. De Radix Foundation is toegewijd om de eerste optie te bieden in de vorm van de ontwikkelaarsgids. Hoewel we geloven dat het belangrijk voor ons is om deze service direct aan onze community te bieden is het onze hoop dat veel van dergelijke services zullen oprijzen om de behoeften te adresseren van een diverse ontwikkelaarscommunity.

De ontwikkelaarsgids zal de inhoud verzamelen van de catalogus en huidige geconcretiseerde componenten en ze presenteren in een app-store-achtige interface. Echter in plaats van betaalde apps aan gebruikers te presenteren zal de gids ontwikkelaars in staat stellen om componenten te ontdekken (zowel catalogus als geconcretiseerd) om hun eigen ontwikkeling te versnellen en on-ledger data uit te filteren naar een zicht op de geassocieerde reputatie en geschiedenis van ontwikkeling en gebruik, alsook een transactieroyaltyprijsstelling om goede integratiebeslissingen te maken binnen een hoog interoperationeel DeFi-ecosysteem.

De ontwikkelaarsgids zal een andere nuttige service bieden aan de ontwikkelaarscommunity in hoe het werk van verschillende ontwikkelaars wordt gepresenteerd. Zoals in iedere waarlijk open marktplaats is slecht gedrag mogelijk. Iemand zou ervoor kunnen kiezen om componenten gecreëerd door anderen te kopiëren of op andere wijze uitbuitende componenten in de catalogus te introduceren. Dit kan natuurlijk niet gestopt worden op een onbeheerde ledger. Maar de ontwikkelaarsgids als een off-ledger service kan werken om zulk gedrag te detecteren en relevante context te presenteren in de aangeboden zoekresultaten. In tegenstelling tot een app-store worden geen aankopen gedaan via de ontwikkelaarsgids en de Radix Foundation zal geen aandeel van royalties aannemen (noch zou deze, of wie dan ook, dit kunnen). Het is een gemakkelijke interface voor een volledig gedecentraliseerde marktplaats, volledig tussen ontwikkelaars en hun gebruikers.

De Radix Foundation en het open source Radix-project

De Radix Foundation ontwikkelt het Radix-protocol als een volledig open source codebasis. Op de lange termijn moet Radix een community-geleide beweging zijn, en we zullen kijken naar de voorbeelden die gesteld zijn door andere succesvolle open source- en blockchain-projecten om deze transitie naar de community te bouwen en ondersteunen. Dit project is de basis-infrastructuur voor Radix, inclusief onbeperkte schaalbare Cerberus-consensus en de Radix Engine die de componentcatalogus en ontwikkelaarsroyaltysysteem onderligt.

Startend vanaf deze basis biedt het ontwikkelaars-royalty-systeem de juiste prikkels in de applicatielaag van Radix om het platform snel te laten groeien tot een levendig, interoperationeel en open DeFi applicatie-ecosysteem voor ontwikkelaars en gebruikers.

De missie van de Radix Foundation is om ontwikkelaars op alle niveau’s te ondersteunen met het waar nodig bieden van essentiële mogelijkmakende functies om knelpunten voor ingebruikname te vermijden terwijl al ons werk wordt overgedragen aan onze community om uit te breiden. Dit omvat natuurlijk assertieve ontwikkeling van kerncomponenten die ontwikkelaars royalty-vrij kunnen gebruiken en uitbreiden, maar ook het ondersteunen van componentontwikkelaars via partnerprogramma’s.

Een specifiek gebied waar de Radix Foundation kan assisteren in het opbouwen in de vroege fase is het subsidiëren van ontwikkelaarsroyalties. In de vroege stadia van het netwerk wanneer er relatief weinig transacties kunnen zijn (en geassocieerde kosten) subsidiëren bijna alle blockchains (inclusief Radix) de beloningen voor node-draaiers via tokenvoorraadinflatie of gewoon een subsidie, betaald uit de reserve. De Radix Foundation wil manieren exploreren waarop ze hetzelfde kan bieden aan ontwikkelaars, de royalty-beloningen betaald door gebruikers vermeerderend en ontwikkelaars aanmoedigend om vroeg deel te nemen aan componentenbouw.

Casusonderzoeken van ontwikkelaarsroyalties in actie

Met de instrumenten aangeboden door Radix-componenten en het ontwikkelaarsroyaltysysteem kunnen we ons een variëteit aan manieren voorstellen waarop ontwikkelaars royalty-gebaseerde inkomstenstromen op basis van gebruik kunnen bijdragen en aanpassen. Hier zijn enkele voorbeelden:

De kerncapaciteitontwikkelaar

Cara heeft een tijdje met DeFi-apps gespeeld en hoort dat Radix een opwindend nieuw platform is voor DeFi. Ze wil geen volledige DeFi-app creëren, lanceren en ondersteunen, maar ze vindt het idee van gepoolde liquiditeit leuk en wil die mogelijkheid bouwen voor de vele Radix dApps waarvan ze denk dat die dat willen.

Ze creëert een deelpool-component in de catalogus die geconfigureerd kan worden om een specifiek deel-token kan munten en verbranden als reactie op stortings- en opname-acties voor een specifiek reservetoken. Dit in de juiste kwantiteit om het NAV- (netto activumwaarde-)deel, gerepresenteerd door elk deeltoken, te behouden. Ze verwacht dat anderen hun eigen pools zullen creëren met gebruik van haar component voor diverse doelen. Ze stelt zowel CATALOGUS- als GEIMPORTEERD-gebruiksroyalties in op een lage 0.5 XRD om breed gebruik en uitbreiding door andere ontwikkelaars aan te moedigen.

Cara reageert toegewijd op veiligheidsvragen en eigenschapsverzoeken van de community en dus is er weinig reden voor andere ontwikkelaars om deze mogelijkheid van begin af aan te bouwen in plaats van eenvoudigweg de kleine transactieroyalty die ze voor gebruik vraagt te accepteren. Caras component wordt dé vertrouwde poolstandaard waar omheen anderen hun eigen componentcode bouwen, de weerstand tegen kopieerders of concurrenten verder vergrotend. Wanneer de Radix-ingebruikname groeit bereikt het gebruik van deelpools een gestage 1P.PPP transacties per dag, genoeg inkomen biedend aan Cara om zich full-time te richten op onafhankelijke ontwikkeling.

De hoge waarde-dienstontwikkelaar

Hannah heeft een bedrijf met toegang tot marktdata die tot op de minuut nauwkeurig is en ze wil die aanbieden aan Radix DeFi-apps. Ze wil dit aanbieden via een component waar deze data atomisch kan worden gebruikt, andere componenten in staat stellend om transacties direct te verwerken met gebruik van huidige prijsdata, zelfs wanneer de transactie is samengesteld over meerdere apps.

Hannahs bedrijf bouwt, installeert en concretiseert een eenvoudige prijsorakelcomponent die alleen marktdata-updatetransacties accepteert van haar eigen servers. In de catalogus stelt de royalties van de CATALOGUS en GEÏMPORTEERD in op nul omdat het haar data is die ze wil monetiseren en ze gratis gebruik van haar open source orakelcode niet erg vindt als dat anderen helpt. Wanneer ze de component concretiseert stelt ze ook de DIRECT-royalty in op nul omdat ze directe toegang door eindgebruikerstoepassingen niet erg vindt; het vergroot alleen maar het bewustzijn van de datakwaliteit. Uiteindelijk stelt ze de GEREFEREERD-royalty in op 25 XRD, wat betekent dat wanneer DeFi-applicaties atomische beslissingen willen maken gebaseerd op haar data dit is waar ze haar inkomsten van wil krijgen. Omdat haar data alleen beschikbaar is via haar eigen geconcretiseerde component is het de enige on-ledger bron voor deze data.

De DeFi-applicatieontwikkelaar

Daiki wil een vooraanstaande DeFi getokeniseerde kredietdienst op Radix bouwen, dit beschouwende als een veiliger en schaalbaarder platform en wensend om onder de eersten te zijn om daar een gebruikersbasis op te bouwen. De typische manieren van het monetizeren van deze dienst zijn beschikbaar, zoals het vereisen van een applicatie-niveau-betaling van een prijs in een token naar voorkeur bij ieder gebruik van zijn applicatie-acties. Echter Daiki wil XRD-tokens accumuleren op het vroege netwerk en ziet royalties als een gemakkelijke manier van het genereren van inkomsten van ofwel direct ofwel gerefereerd (d.w.z. opgebouwd uit eem amdere DeFi-app) gebruik, zonder het toevoegen van de additionele integratiecomplexiteit van een prijs op applicatie-niveau. Hij verwacht dat de frontend, ondersteuning, en snelle verbeteringen van zijn bedrijf meer dan genoeg zijn om kopieerders op afstand te houden, maar niettemin stelt hij de CATALOGUS- en GEÏMPORTEERD-royalties voor zijn kern-krediet-app-component in op een erg hoog niveau. Wanneer geconcretiseerd stelt hij de DIRECT- en GEREFEREERD-royalties in op een redelijk 5 XRD-niveau om lage wrijving en een hoog volume samengesteld gebruik door zijn frontend-gebruikers en andere apps aan te moedigen.

Onderdeel van Daikis concurrentievoordeel is toegang tot uitstekende marktprijsdata van Hannahs orakel. Hij ging vroeg naar haar bedrijf en overtuigde haar om een royalty-exceptie te creëren voor Daikis krediet-app-ID, zijn app in staat stellend om haar data atomisch te gebruiken voor de helft van haar algemene royalty.

De gilde-DAO van de bouwers

Beatriz wil een volledig gedecentraliseerde organisatie bouwen waarin meerdere ontwikkelaars samenwerken om nuttige Radix-componenten te produceren en te delen in de totale royalties. Ze creëert eerst een gilde-token (met gebruik van een gratis component ontwikkeld door de Radix Foundation) die senioriteit binnen het gilde representeert. Ze creëert twee primaire componenten:

•Een gilde-beheringscomponent dat gildetokenhoders in staat stelt om te stemmen over het beleid dat ontwikkelaars lidmaatschap en senioriteit geeft binnen het gilde, gebaseerd op hun werk, alsook hoe nieuwe componenten worden geïnstalleerd en geüpdate en hoe hun royalties worden ingesteld.

•Een inkomstendelingscomponent dat basale accountfunctionaliteit uitbreidt om gildetokenhouders in staat te stellen proportionele hoeveelheden XRD te claimen van de gilderoyalties die in zijn account vloeien (wat wordt gebruikt om alle gildecomponenten te installeren).

Ze installeert deze allebei zonder royalty om bij te dragen aan de open source-community en om de creatie van andere DAO’s aan te moedigen, een concept waarin ze sterk gelooft.

Ze lanceert de bouwersgilde-DAP, controle overleverend aan een initiële kernset van ontwikkelaars en de beheercomponent, en ziet toe hoe dit opbloeit tot een wereldwijde community van bijdragers, wat een sterke reputatie ontwikkelt voor het produceren van betrouwbare Radix-componenten.

De initiële componentaanbieding

Itai is een onafhankelijke ontwikkelaar die grootse ideeën heeft voor een DeFi-app, maar hij heeft genoeg kapitaal nodig om hem full-time te committeren om van prototype naar een volledig platform te gaan. Hij maakt deel uit van een netwerk van ontwikkelaars dat zijn vaardigheden respecteert, en dus besluit hij om ze te vragen voor directe sponsoring in ruil voor ene deel van de royalty-opbrengsten die hij verwacht dat zijn app zal produceren.

Gelukkig vindt hij Beatriz’ opbrengstdelingscomponent. In plaats van deze te configureren voor opbrengstaandeelclaims gebaseerd op Beatriz’ lidmaatschapstoken configureert hij hem om zijn eigen Itai-app-token te gebruiken als basis voor opbrengstclaims op de royalty-account. Hij verdeelt 50% van deze tokens aan zijn ondersteuners en houdt de rest voor zichzelf.

De freemium-ontwikkelaar

Felix heeft een component gebouwd dat een slimme set van algoritme’s implementeerd die nuttig zijn voor veel applicaties. Hij wil de breedst mogelijke integratie aanmoedigen en dus stelt hij zowel de CATALOGUS- als de GEÏMPORTEERDE royalty in op nul. Later creëert hij een additioneel algoritme dat erg nuttig is voor een beperkte subset van ontwikkelaars die deze gebruiken. Hij installeert een nieuwe revisie van de component die een bescheiden prijs toevoegt. Omdat Radix een onveranderlijke ledger is gaan ontwikkelaars door met het vrijelijk concretiseren en importeren van de eerdere gratis versie, maar als ze toegang willen hebben tot de nieuwere, meer uitgebreide, versie dan moeten ze ook de nieuwe royalty met de update accepteren.

Zoals boven beschreven is het belangrijk om er opnieuw notie van te nemen dat eenmaal een component is geïnstalleerd op de ledger de ontwikkelaar niet stilletjes een verandering van royalty kan opdringen aan gebruikers of andere ontwikkelaars. Alleen via de creatie van een nieuwe versie van een component kan de set van royalties geüpdate worden, waarbij de oude versie beschikbaar blijft.

Noten

4. Hoewel vaste XRD-prijsstelling het eenvoudigste is verwachten we dat ontwikkelaars de prijsstelling algoritmisch willen instellen voor iedere type van gebruik, wellicht om royalties in te stellen voor een bepaalde fiat-prijs in de huidige XRD-prijs met gebruik van prijsorakel naar eigen keuze. Dit is absoluut mogelijk binnen het Radix-protocol.

Website (https://www.radixdlt.com/)
Medium (https://medium.com/@radixdlt)
Telegram (https://t.me/radix_dlt)
Twitter (https://twitter.com/RadixDLT)