Crypto Fragen

[daullmer]

• was muss für jede Tour in der Datenbank gespeichert werden? Ich vermute:
  - Contract Adresse des erstellten TourTokens
  - BalancerPool Adresse
  - WrappedEtherum Adresse für den Eintausch gegen TourTokens => ist es hier möglich, für alle BalancerPools die selben WETH anzunehmen? Dann muss der Ersteller einer Tour nicht jedes mal ein eigenes Wrapped Ethereum erstellen. Dann haben wir aber auch beim Erstellen einer Tour das Problem, dass er Ersteller WETH braucht. Wie kommt er an das (siehe Punkt 3)

• Wie kommen wir im "BFactory" Callback an den zugehörigen Token? Im Event bekommt man nur folgende Informationen:

BFactory
Result {
  '0': '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  '1': '0x427996E17113006441F057d591881EA12ca9056b',
  caller: '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  pool: '0x427996E17113006441F057d591881EA12ca9056b'
}

Pool ist die Adresse des Pools, Caller die Adresse des Erstellers des Pools.

• wie kommt man als Käufer der Tour an die Wrapped Ethereum um diese im BalancerPool gegen den TourToken zu tauschen?
  In MetaMask hab ich es nur geschafft die vom Account des Erstellers des BalancerPools an einen anderen Account zu "überweisen". Über die Funktion "Swap" kann man kein Ether in Wrapped Ethereum tauschen (zumindest hat es bei mir nicht funktioniert).
  Bevor man eine Tour kaufen kann, muss auf der Beispielseite Punkt 5.1 "Set Token In Address" ausführen. Woher kommt man an diese Adresse (entweder für jede Tour eigenes WETH und dann mit jeder Tour in der Datenbank oder ein WETH für ganz Cryptour {kann man hier evtl. auch den Ocean Token nehmen? Für den gibt es manche Testnets öffentliche Faucets bei denen man einfach an Tokens kommt})

• Im TourTokenOrder Event wird nur übergeben wer eine Tour gekauft hat. Nicht aber, welche Tour gekauft wurde

TourTokenOrder
Result {
  '0': '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  '1': '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  '2': '1000000000000000000',
  '3': '12345',
  '4': '1650800659',
  '5': '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  '6': '1000000000000000',
  consumer: '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  payer: '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  amount: '1000000000000000000',
  serviceId: '12345',
  timestamp: '1650800659',
  mrktFeeCollector: '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  marketFee: '1000000000000000'
}

[wetzelbe]

1. Ja für die WETH Adresse könnt ihr immer die selbe Adresse annehmen, Wichtig ist hier nur, dass es ein ERC20-Token ist. Das kann also der OCEAN-Token sein oder WETH. Der Nutzer sollte nie diesen Token deployen müssen, wie es im Beispiel ist, das ist dort nur so, weil ich von einer komplett leeren Blockchain wie Ganache ausgegangen bin.
   Ich hoffe ich vergesse jetzt nichts, aber das sollte passen was in die DB kommt.

2. Ihr speichert ja die adresse des BPool für jeden Token ab und habt darüber ja die Verbindung zu dem Token

3. siehe 1. Set Token In Address sollte nicht der Nutzer machen, sondern ihr, praktisch gleich wenn die Seite geladen wird.

4. Hier könnt ihr über die serviceId praktisch jeden String übergeben, den ihr im Backend braucht um richtig damit umgehen zu können. Alternativ hier einfach eine TransaktionsId reinschreiben und über eine API die Daten an das Backend schicken. Das kann dann über die TransaktionsId zuordnen worum es geht. Die serviceId wird beim Aufrufen der consumeTT Funktion übergeben

[daullmer]

Punkte 1, 3 und 4 hab ich dann soweit verstanden.

Zu Punkt 3 ist mir noch nicht ganz klar, wie wir die Zuordnung BPool <-> TourToken hinbekommen. Wenn der Token deployed wird, ist noch nichts vom BPool bekannt. Im Event wenn der BPool erstellt wird, wird allerdings auch nicht übergeben, zu welchem Token der Pool gehört.

TokenCreation:

Result {
  '0': '0x8c1076a7833D33Eb0DC3C82a626619867b36b424',
  '1': 'Tour3',
  '2': 'CrTour3',
  '3': '25000000000000000000000',
  '4': '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  '5': '0x052bde4aa6d933e86094d73f2f931e206f9917b0c828daa269cf9a79afc76614',
  tokenAddress: '0x8c1076a7833D33Eb0DC3C82a626619867b36b424',
  tokenName: 'Tour3',
  tokenSymbol: 'CrTour3',
  tokenCap: '25000000000000000000000',
  registeredBy: '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  blob: '0x052bde4aa6d933e86094d73f2f931e206f9917b0c828daa269cf9a79afc76614'
}

BPool Creation:

Result {
  '0': '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  '1': '0x427996E17113006441F057d591881EA12ca9056b',
  caller: '0x6888c461Fe08e8d1fCeA14397d40A456B5C73f0a',
  pool: '0x427996E17113006441F057d591881EA12ca9056b'
}

Wir wissen also, wenn das BPool Event kommt, zu welchem Token das gehört. Möglich wäre zwar eine Zuordnung über die CallerId und die letzte Tour die der Caller erstellt hat, optimal finde ich das aber nicht

[wetzelbe]

Du hast Recht, ich muss mir das noch mal anschauen, ob es sinn macht das abzuändern

[wetzelbe]

Ich habe ein neues Event hinzugefügt, das ausgelöst wird, wenn das BPool finalisiert wird. Ist im Beispiel beim provider auch drin. Da ist im Event dann die Adresse des BPool, die Adresse der mit ihm verknüpften Token und der Besitzer des BPool drin.

[daullmer]

Perfekt, vielen Dank!