Az XRP-tulajdonosok végre hozamra tehetnek szert anélkül, hogy az Ethereumhoz nyúlnának: Részletek

Az XRP könyvtár (XRPL) natív hitelezési és hitelfelvételi képességeket kíván közvetlenül a hálózatába bővíteni egy XLS-66 nevű javaslatAmennyiben a validátorok jóváhagyják, a módosítás lehetővé tenné a felhasználók számára, hogy a láncon belüli, fedezet nélküli, fix lejáratú hiteleken keresztül hozamot realizáljanak a kihasználatlan tőkéjükön, anélkül, hogy a főkönyvre épülő harmadik féltől származó platformokra kellene támaszkodniuk. A protokoll jelenleg 17%-os konszenzust ért el a validátorok körében, ami jóval elmarad a bevezetéshez szükséges 80%-os többségtől.

Mi az XLS-66 kölcsönzési protokoll?

Az XLS-66-ot, hivatalos nevén „Lending Protocol”-t, az XRPL 3.1.0-s verziójában vezették be, és a Ripple fejlesztői, Vytautas Vito Tumas és Aanchal Malhotra társszerzői voltak. A javaslat a láncon belüli hitelnyújtás alapvető építőelemeit közvetlenül az XRP Ledgerben vezeti be, ahelyett, hogy egy külön telepített intelligens szerződéses ökoszisztémán keresztül történne.

A protokoll fix lejáratú, közös betétekből finanszírozott hiteleket kínál. Ami megkülönbözteti a legtöbb DeFi hitelezési rendszertől, az az, hogy szándékosan kihagyja az automatizált, láncon belüli fedezetkezelést és likvidációs botokat. Ehelyett az identitás-ellenőrzés, a hitelminősítés és egyéb kockázatértékelési lépések a láncon kívül történnek, mielőtt bármilyen hitelt kibocsátanának. A főkönyv kezeli az elszámolást, a tulajdonosi nyilvántartásokat és az auditnaplókat.

Az XRPL kutatója és validátora, Vet, egy aktív közösségi tag, aki ezt a hálózat „végső DeFi-határának” nevezte, a következőket mondta: 

„A hitelező eleve nem adna neked XRP-t anélkül, hogy tudná, ki vagy, és elvégezne néhány off-chain ellenőrzést.”

Hogyan működik valójában a protokoll?

Az XLS-66 specifikáció két új, láncon belüli objektumot vezet be: a LoanBrokert és a Loant.

A LoanBroker objektumot egy Loan Broker, a hitelezési művelet lebonyolításáért felelős entitás hozza létre és kezeli. Protokollspecifikus adatokat rögzít, beleértve a díjakat és a bróker által a nemteljesítések elleni pufferként letétbe helyezett első veszteségű tőkét. A Loan objektum rögzíti a Loan Broker és a hitelfelvevő közötti megállapodást, beleértve a feltételeket, a fizetési ütemtervet és a státuszt.

Az alapáramlás így működik:

• A hitelközvetítő létrehoz egy trezort, amelyben egy vagy több betétestől származó letétbe helyezett eszközöket tárolja.
• A Hitelközvetítő opcionálisan First-Loss Capital-t helyez el nemfizetési védelmi alapként.
• A kölcsöntárgyat a kölcsönközvetítő és a kölcsönvevő közösen hozza létre.
• A hitelfelvevő LoanDraw tranzakcióval vesz fel pénzt, és a LoanPay segítségével fizeti a törlesztőrészleteket.
• Ha a hitelfelvevő fizetésképtelenné válik, a hitelközvetítő elindíthat egy LoanManage tranzakciót a fizetésképtelenség rögzítésére.
• Amint egy kölcsön lejár vagy fizetésképtelenné válik, egy LoanDelete tranzakció segítségével törlődik a főkönyvből.

A protokoll összesen kilenc tranzakciótípust támogat, lefedve a teljes életciklust a hitel létrehozásától a LoanBroker objektum törléséig, miután az összes hitel rendeződött.

Kamatok és díjak

A protokoll három kamatláb-típust támogat: a tőketartozásra vonatkozó standard kamatlábat, a magasabb késedelmi kamatlábat és a határidő előtti visszafizetési kamatlábat azoknak az adósoknak, akik a futamidő lejárta előtt rendezik a hitelt. A hitelközvetítők ezeken felül számos díjat konfigurálhatnak, beleértve a kamat százalékában felszámított kezelési díjat, a tőkéből levont hitelnyújtási díjat, az egyes befizetések után felszámított hitelszolgáltatási díjat, valamint a késedelmes vagy korai fizetések külön díjait. Díjakat csak akkor számítanak fel, ha a hitelközvetítő elegendő első veszteségű tőkét helyezett letétbe.

Fedezze fel az ígéretes projekteket...

Ígéretes projektek...

(Hirdetés)

A cikk folytatódik...

Megfelelőség és kockázatvédelem

A protokoll két beépített megfelelőségi mechanizmust tartalmaz, amelyeket az eszközkibocsátók használhatnak. Az első a visszakövetelés, amely lehetővé teszi a kibocsátó számára, hogy bizonyos körülmények között visszaszerezze a pénzeszközöket a trezorból. A második egy befagyasztási mechanizmus, amely megakadályozhatja, hogy egy adott számla vagy az összes számla küldjön vagy fogadjon egy adott eszközt. Ha egy kölcsönvevő számlája be van zárva, nem vehet fel pénzeszközöket vagy nem teljesíthet kifizetéseket, bár a visszafizetési kötelezettsége továbbra is fennáll.

Az első veszteséget okozó tőkeprogram az elsődleges kockázatkezelési eszköz. A hitelközvetítők a teljes fennálló adósság százalékában meghatározott összeget helyeznek el a hitelintézetnél. Ha egy hitelfelvevő fizetésképtelenné válik, az alap egy részét felszámolják és visszajuttatják a trezorba, hogy ellensúlyozzák a betétesek veszteségének egy részét.

Miben különbözik az XLS-66 a hagyományos DeFi hitelezéstől?

A legtöbb DeFi-hitelezés Ethereum A túlzott fedezetvállalás révén működik. A hitelfelvevők a hitelösszegnél nagyobb értékű kriptovalutát zárolnak, és az automatizált botok likvidálják a fedezetet, ha annak értéke egy meghatározott küszöbérték alá esik. Az olyan protokollok, mint az Aave és a Compound, teljes mértékben erre a modellre épülnek.

Az XLS-66 egyáltalán nem használ láncon belüli fedezeti vagy likvidációs botokat. A kompromisszum az, hogy a hitelezők nagyobb hitelkockázatot vállalnak, de a rendszert úgy tervezték, hogy ezt szigorú, láncon kívüli hitelbírálattal kezelje, mielőtt bármilyen hitelt létrehoznának. A főkönyv csak az eredményt rögzíti, az érzékeny hitelfelvevői adatokat a láncon kívül tartja, miközben nyilvános auditnaplót tart fenn.

Ez a hibrid megközelítés, a központosított kockázatkezelés és a decentralizált elszámolás kombinációja nem teljesen új. Az Algorand Algofi hitelpiaca hasonló kombinációt alkalmazott a láncon belüli fedezet és a láncon kívüli hitelminősítés terén, és körülbelül 12%-os éves hozamot biztosított a korai résztvevőknek. A Stellar hálózat 2020-ban egy egyszerűbb verzióval próbálkozott, erős hitelbírálati ellenőrzések nélkül, és azt tapasztalta, hogy az adósok fizetésképtelenné váltak a likviditás elapadásával. Úgy tűnik, hogy az XLS-66-ot ezeket a tanulságokat szem előtt tartva tervezték.

Mi akadályozza meg az XLS-66 éles indulását?

A módosításhoz 80%-os validátori jóváhagyás szükséges, és ezt a küszöbértéket két egymást követő héten keresztül fenn kell tartani az aktiválás előtt. Jelenleg az XRPL megbízható validátorai közül csak 6 szavazott igennel, 29-en pedig nemmel vagy tartózkodtak. Ez a jelenlegi konszenzust 17.14%-ra teszi, ami messze van a szükséges küszöbértéktől.

A 80%-os többségi követelmény az XRPL irányítási modelljének szándékos jellemzője. Ez biztosítja, hogy a főkönyv nagyobb módosításait ne lehessen keresztülvinni a hálózat validátorainak széles körű egyetértése nélkül, amely magában foglalja a független csomópontokat, tőzsdéket és intézményeket. Ugyanez a mechanizmus lassított vagy blokkolt más módosításokat a múltban, és az XLS-66 is ugyanezzel az akadállyal néz szembe.

Összegzés 

Az XLS-66 egy natív hitelezési réteget biztosítana az XRP Ledger számára, amely fix kamatozású, fedezet nélküli hitelekre épül, láncon kívüli biztosítéknyújtással és láncon belüli elszámolással. A protokoll strukturált eszközöket tartalmaz a hitelek folyósításához, visszafizetéséhez, nemteljesítési kezeléséhez és a betétesek védelméhez a First-Loss Capitalon keresztül. Hogy ez megvalósul-e, az a validátoroktól függ, és jelenleg a számok nem állnak közel egymáshoz.

Tudástár 

1. XLS-66 javaslat: 0066 XLS-66dXRP Ledger-natív hitelezési protokoll

2. XRPL kutató és validátor, X-en dolgozó állatorvosMárcius 8-jei bejegyzés