Hallo, ich habe eine Frage zur steuerlichen Behandlung von LKMEX aus MultiversX: Weiss jemand, wie man steuerlich die locked rewards LKMEX in Deutschland ansetzt? Gibt man bei der Besteuerung den MEX-Kurs an, obwohl LKMEX gesperrt sind, oder werden sie erst nach der Entsperrung steuerlich relevant? Hat jemand Erfahrung damit? Danke.
1 „Gefällt mir“
Wäre interessant zu wissen, ob das 1. ein eigener Contract ist und wenn ja, was der zum Ihnalt hat (Backing 1:1 durch MEX?)
Dann würde ich sagen, dass man den dem unlocked underlaying Asset gleichstellen kann. Ist jedoch nur eine Vermutung in völliger Unkenntnis
Hallo, LKMEX waren rewards von einer EGLD/MEX farm auf der exchange. Dann wurden sie eingebracht in einer MEX farm und dabei getrackt als LKFARM. Hilft das weiter oder kannst du mir vielleicht sagen, wie ich die nötigen Infos bekomme? In meiner Wallet sind nur MEX. Ein Zufluss von LKMEX hat nicht stattgefunden.
War dieses Farming ein Liquidity-Providing?
Wenn ja hattest du Abgänge des LP-Paares eingespielt bekommen?
Gibt es bei MultiverseX irgendeine Exportmöglichkeit dafür, abgesehen von der API?
Bin noch immer am Fischen im trüben, aber wir nähern uns 
Es wurde ein Liquidity Providing token EGLDMEXLP als EGLDMEXF getrackt. Ich musste die entsprechenden Transaktionen überwiegend manuell erfassen. Sie wurden nicht automatisch eingelesen. Ich habe nach einer anderen Exportmöglichkeit gesucht. Entity global hat ein tax tool dafür. Leider hat das bisher kein einziges Mal funktioniert.
LP-tracking funktioniert eher bei Chain-APIs, so meine bisherigen Beobachtungen, leider. Aber du bist am richtigen Weg mit der manuellen Erfassung. Ich habe dazu immer eine extra manuelle Integration erstellt, wo ich die LP-Trades dargestellt habe.
Bin da aber nicht mehr aktiv.
Macht eine extra Integration Sinn, wenn man nur in einer Anwendung LP-tracking braucht? Wie ist es nun mit dem LKMEX-Wert?
Nun, ich trenne jedenfalls unterschiedliche Anschaffungsdaten/Kurse in 2 Integrationen, was mitunter gewinntechnisch interessant sein kann.
Weiters ist es so mMn am saubersten dargestellt.
2 x Transfer der benötigten Token in die manuelle Integration, 2 x Tausch in den LP-Token (für gewöhnlich 50:50). Retour genau umgekehrt. Wenn der LKMEX nicht in der Datenbank vorhanden ist, nimm einfach einen Generic Crypto
Ich habe mit der Integration massive Probleme.
a) es werden fehlende Historien durch den Umstand angezeigt, dass Transaktionen nicht in der richtigen Reihenfolge erscheinen, da der Zeitstempel für mehere automatische Aktionen des Wallets gleich erscheint. Also z.B. beim Erstellen eines Liquitidy Paares die Umwandlung von EGLD zu WEGLD nacht dem Abzug des WEGLD erscheint, was zu „fehlender Historie“ führt.
b) das durch den Punkt a) erstellte Liquitity Paar bekommt keinen Wert eingetragen, obwohl die eingehenden Werte bekannt sein sollten (?) Z.B. Eingang WGLD und danach Eingang USDC mit Werten und die dadurch entstehende Paares Währung EGLDUSDCLP bekommt keinen Wert.
c) ich bekam durch verschiedene Liquitity Paare MEX und auch LKMEX „ausgezahlt“. Habe diese als neue Paare mit weiterhin eingezahlten EGLD angelegt. Die Buchungen sind größtenteils Anfang 2022 durchgeführt worden. Eine manuelle Ermittlung dieser MEX Werte ist mir nicht möglich. Sie sind auch zügig im Laufe der Zeit im Wert stark zurückgegangen, wie natürlich auch der EGLD Wert an sich.
Was kann ich tun, damit ich hier zu einer sauberen Darstellung komme? Die Integration zeigt mir Tausende von Fehlern.
1 „Gefällt mir“
Hallo,
Ich habe auch sehr viele Fehlermeldungen in der MultiversX Integration und habe irgendwann damit angefangen, diese manuell zu lösen mit Hilfe des MultiversX Explorers. Meine Erfahrung ist, dass viele Transaktionen im Blockpit gar nicht erfasst werden. Ich musste Transaktion für Transaktion im Explorer durchgehen und manuell erfassen. Im Explorer hatte ich keine Probleme mit dem Zeitstempel.
Die fehlenden Werte muss man wohl ebenfalls anhand der ausgehenden Werte manuell erfassen. Das ist, wenn ich das richtig verstanden habe, zulässig, wenn für den eingehenden Asset kein Wert ermittelbar ist.
Eine Ermittlung der historischen Werte für MEX kannst du auf Coincodex finden. Diese muss man dann leider ebenfalls manuell eintragen. Es ist uferlos.
Es gibt über entity global ein tax tool für MultiversX, der aber leider für mich kein einziges Mal funktioniert hat. Vielleicht hast du mehr Glück. Wenn ja, könntest du dich nochmal melden und erklären, wie du das gemacht hast?
3 „Gefällt mir“
Du kannst API-Timestamps auf eine der Historie entsprechende Sekunde davor/danach umstellen. Mühsam, wenn es sehr viele Transaktionen sind, aber es wäre die fehlende Historie dadurch gelöst
1 „Gefällt mir“
Danke Bernhard, genau so hatte ich ein paar entsprechende Fehler gelöst, aber wie auch AAB vorher schrieb, werden viele Werte nicht abgegriffen und das ist manuell für mich kaum zu lösen, da es über tausend Hinweise sind und ich bei vielen keine Ahnung habe, was überhaupt gemeint ist.
Warum erkennt BlockPit die Werte für ein Liquidity Paar nicht, wenn ich z.b. aus 100 Dollar USDC und 100 Dollar EGLD ein EGLDUSDCLP Paar bilde? Und als Beispiel für mein Unverständis der Bezeichnungen, fließt dann dieses Asset wieder ab und wird zu einem EGLDUSDCF mit fehlendem Wert. Ich bin da immer noch ratlos…
Danke, den Explorer werde ich mir mal anschauen, vielleicht hilft es. Aber ich habe fast 1300 Hinweise…
Ist Entity Global vertrauenswürdig? Um das Tool zu nutzen, kann man dort nicht einfach den Public Key eingeben, sondern muss sich über den Link auf deren Seite beim Wallet einloggen.
Ich hatte mich ja ursprünglich sehr darüber gefreut, dass BlockPit eine Integration anbietet, aber so bringt mir das alles wirklich gar nichts. Am Ende werde ich wohl als Resultat meiner Hilflosigkeit manuell eine Tabelle anlegen müssen, aber das ist gar nicht gut. Und ein Steuerberater wird wohl auch nicht helfen können. Sehr frustrierend.
Hallo, den Hinweis auf entity global habe ich erhalten auf eine Anfrage bei MultiversX. Also würde ich vermuten, dass die Anwendung vertrauenswürdig ist. Nur, wie gesagt, leider hat das nicht wirklich funktioniert. Schwer zu sagen, ob sich ein Versuch wirklich lohnt. Einen fachkundigen Steuerberater zu fragen, ist sicherlich nicht falsch. Manchmal wird man positiv überrascht, wenn man sich einfach „durchfragt“. Viel Glück.
1 „Gefällt mir“
Wenn du mit den bisherigen Lösungsvorschlägen gar nicht weiter kommst,
dann wäre mMn ein Ticket mit einem Zip-Archiv an Screenshots von Beispielen
und einem Erklärtext mit Verweis auf die entsprechenden Bilder angezeigt.
Sollte da ein API-Problem seitens Blockpit vorliegen können die das dann entsprechend verbessern. Es wird ja bei vielen Integrationsanleitungen immer darauf hingewiesen sich bei Problemen an den Support zu wenden. Mir hat das schon sehr oft geholfen
1 „Gefällt mir“
Fehlende oder falsch berücksichtigte Transaktionen könnt ihr uns auch gern via Support-Ticket samt Screenshots und Beschreibung berichten.
Womöglich lässt sich hier die Importlogik optimieren.
Ein- und Ausstieg in einen LP-Pool sollten in den meisten Fällen in Form eines Trades dargestellt werden.
Grundsätzlich macht es nichts, wenn ein LP-Token keinen Wert hat, solang der Wert in Form eines Trades vom Gegenspieler-Asset (z. B. EGLD) übertragen werden kann.
Schwieriger wird es, wenn beide Assets des Trades keinen Wert laut Datenbank haben.
1 „Gefällt mir“
Vielen Dank Bernhard and Florian! Ich werde ein Ticket einreichen, in Form eines Screenshots. Es sollte so gehen, wie Florian beschrieben hat, dass die Werte anhand der Gegenbuchungen ermittelt werden, da die Werte der einfließenden Assets bekannt sind. Also müsste die Schnittstelle diese Vorinformation zur Bildung des Gegenwertes heranziehen, damit die Balance wieder stimmt.
Auch der Wert der MEX Rewards lässt sich aus der Transaktion im Multiverse Explorer herauslesen. Das Label kann durch die Methodenbezeichnung claimReward dann vielleicht auch geändert werden?
Alles Weitere im Ticket.
1 „Gefällt mir“
Danke. Potenziell können wir Labels schon vorab für alle Nutzer vordefinieren. Hier ist jedoch immer auch die Frage, ob der Vorgang sowohl technisch als auch steuertechnisch eindeutig zuordenbar ist.
Für Preisdaten sind wir einerseits direkt von Coinmarketcap und Coingecko abhängig, wobei wir für Ethereum, DeFiChain und auch ein paar andere Blockchains auch Preisdaten direkt von der Chain auslesen.