Smart-Contract-Architektur

Documentation Index

Fetch the complete documentation index at: https://whitepaper.rwanftfi.com/llms.txt

Use this file to discover all available pages before exploring further.

Die RWANFTFI-Plattform basiert auf einer robusten, modularen und sicheren Smart-Contract-Architektur, die alle Interaktionen, Verteilungen und Token-Mechaniken ohne zentrale Steuerung regelt.

​

Diamond Pattern (EIP-2535)

Der Kern des RWANFTFI-Systems ist mit dem Diamond Pattern (EIP-2535) implementiert. Diese architektonische Wahl ermöglicht es dem Protokoll, das standardmäßige Smart-Contract-Größenlimit (24 KB) zu umgehen, indem die Funktionalität auf mehrere unabhängige Module – sogenannte „Facets” (Smart-Contract-Module, auf die über einen einzelnen Proxy-Vertrag zugegriffen wird) – aufgeteilt wird.

​

Kern-Facets

​

NFT-Verträge & Token-ID-Räume

Das Protokoll verwendet drei eigenständige NFT-Verträge (Regular, Gift, Ambassador). Um Identifikator-Kollisionen in der On-Chain-Mapping registeredTokens, das jedes geprägte NFT systemweit verfolgt, zu verhindern, prägen Regular-NFTs und Gift-NFTs in getrennte tokenId-Räume, partitioniert nach Parität:

• Regular NFT – ungerade Token-IDs (1, 3, 5, 7, …).
• Gift NFT – gerade Token-IDs (2, 4, 6, 8, …).

Die Aufteilung wird innerhalb der Minter-Logik jedes NFT-Vertrags zum Zeitpunkt des Mintings durchgesetzt. Da ein erfolgreicher Mint auf einem Vertrag niemals einen Identifikator erzeugen kann, den der andere Vertrag jemals ausgeben könnte, wird eine ganze Klasse von Mapping-Kollisionsfehlern auf Typsystemebene eliminiert – kein Laufzeitschutz und keine Deduplizierungsprüfung pro Aufruf sind erforderlich. Die Partitionierung ist für Endnutzer unsichtbar: Wallets und Marktplätze zeigen weiterhin jedes NFT unter seinem nativen Vertrag an.

​

Upgradability-Matrix

• Diamond Contract (EIP-2535): Aktualisierbar über Facet Cuts – ermöglicht das Hinzufügen, Ersetzen oder Entfernen einzelner Module ohne erneutes Deployment des gesamten Systems.
• TokenReserve (DA): Aktualisierbar über Transparent Proxy – Logik-Updates sind möglich, ohne die Vertragsadresse zu ändern.
• NFTs (Regular, Gift, Ambassador), GovToken, AdminContract: Nicht aktualisierbar – gewährleistet die Unveränderlichkeit der Kernvermögenswerte und Governance-Regeln.

​

Rollenverwaltung

Das System nutzt eine hierarchische Rollenstruktur (AccessControlEnumerable), um Berechtigungen sicher zu verwalten:

• ADMIN_ROLE: Kann andere Rollen vergeben/entziehen und kritische Systemparameter ändern.
• SERVICE_ROLE: Wird von Backend-Skripten für automatisierte Aufgaben ausgeführt (z. B. Auflösung abgelaufener Stacks, Verarbeitung von Cross-Chain-Einzahlungen).
• SIGNER_ROLE: Wird zur kryptografischen Signaturprüfung verwendet, um bestimmte Aktionen wie Gutscheinübertragungen zu autorisieren.
• MINTER_ROLE: Berechtigt, bestimmte Tokens oder NFTs zu prägen.

​

Guthaben-Schema & Zahlungspriorität

Zur Verwaltung des komplexen Mittelflusses verwendet RWANFTFI ein mehrstufiges Guthaben-Schema innerhalb des Smart Contracts. Nutzerguthaben:

1. Reguläres Guthaben (balance): Die primäre Wallet für verfügbares USDT. Mittel hier können jederzeit abgehoben, zum Kauf von NFTs oder zum Erstellen von Gutscheinen verwendet werden.
2. Akkumulatives Guthaben (accumulativeBalance): Ein verpflichtendes Sparkonto, auf dem 20 % jeder Marketing-Belohnung sofort bei Anrechnung gutgeschrieben werden.
   • Verwendung: Kann nur für den Kauf eines NFTs derselben Stufe oder eines NFTs einer höheren Stufe verwendet werden.
   • Gebühren: Die Verwendung dieses Guthabens für NFT-Käufe ist mit einer 20 %-Gebühr verbunden, die an den DA-Liquiditätspool weitergeleitet wird. Die Übertragung an einen anderen Nutzer ist ebenfalls mit einer 20 %-Gebühr verbunden, die an den DA-Liquiditätspool weitergeleitet wird. Jede Bewegung des Akkumulativen Guthabens erzeugt einen Zufluss in den Pool und schafft die Grundlage für neue DA.
   • 120-Tage-Umverteilung: Wenn der Nutzer sein Akkumulatives Guthaben nicht innerhalb von 120 Tagen verwendet, wird das ungenutzte Guthaben für eine Umverteilung freigegeben. Die Aufteilung hängt vom NFT-Typ des Nutzers ab:
     • Inhaber von Regular NFTs: 70 % werden an den DA-Liquiditätspool zur Prägung neuer DA-Tokens weitergeleitet; 30 % werden an den direkten Upline-Sponsor des Nutzers übertragen.
     • Inhaber von Gift NFTs: 80 % werden an den DA-Liquiditätspool weitergeleitet; 20 % werden an den direkten Upline-Sponsor übertragen (geregelt durch den separaten Parameter accumulativeClaimDistributeGift).
     • Kaskadenregel (beide Typen): Wenn das Einkommenslimit des Upline-Sponsors erschöpft ist (gleich null), wird der Sponsor-Anteil weiter nach oben an den nächsten berechtigten Teilnehmer in der Struktur weitergegeben. Wenn kein Teilnehmer in der Kette ein aktives Einkommenslimit hat, wird der gesamte Betrag an den DA-Liquiditätspool weitergeleitet.
   120 Tage = garantiertes Mindestfenster, kein automatischer Verfall: Der Parameter accumulativeDecayTime wird nur innerhalb von withdrawAccumulative() geprüft – dem von Admin/Service ausgelösten Umverteilungspfad. Er wird nicht auf den Ausgabe- oder Übertragungspfaden ausgewertet. In der Praxis bedeutet dies:

   • In den ersten 120 Tagen nach einer Gutschrift ist die Integrität des Akkumulativen Guthabens garantiert – es kann von niemandem umverteilt werden.
   • Nach dem 120. Tag wird das Guthaben für eine Umverteilung freigegeben, aber die Umverteilung erfolgt nicht automatisch nach Ablauf des Timers. Sie erfolgt nur, wenn withdrawAccumulative() für diesen spezifischen Nutzer durch SERVICE_ROLE oder ADMIN_ROLE aufgerufen wird.
   • Bis dieser Aufruf erfolgt, bleibt ein „abgelaufenes” Akkumulatives Guthaben für NFT-Käufe und Upgrades ausgabbar und gemäß den Standardregeln und -gebühren auf andere Nutzer übertragbar.

   Die in der Audit-Antwort festgehaltene Absicht des Teams: „Our goal is to guarantee the user’s funds’ integrity for a certain period of time, not to give them a lifecycle.” Behandeln Sie 120 Tage als das garantierte Mindestfenster vor möglicher Umverteilung, nicht als harten On-Chain-Verfallszeitstempel.
3. Limit (limit): Repräsentiert das maximale verbleibende Einkommen, das ein NFT generieren kann.

​

Systemguthaben

Zusätzlich zu den Nutzerguthaben verwaltet der Smart Contract drei interne Systemguthaben:

• Dev-Guthaben (devBalance): Sammelt Plattformgebühren und Provisionen zur operativen Finanzierung.
• Token-Reserve-Guthaben (tokenReserveBalance): Der USDT-Liquiditätspool, der den DA-Token zu 100 % deckt. Jede Einkommensquelle im Ökosystem fließt in diesen Pool.
• Price-Impact-Guthaben (priceImpactBalance): Eine spezielle Reserve, die zur Steuerung der Preisstabilität des DA-Tokens während bestimmter Ökosystem-Ereignisse verwendet wird.

Diese Guthaben werden vollständig vom Smart Contract verwaltet und sind für keinen einzelnen Nutzer oder Administrator zugänglich.

​

Zahlungspriorität

Beim Kauf zieht der Smart Contract die Mittel in dieser Reihenfolge ab: