A new wallet address that is domain verified with the domain displayed in the vanity address.

The domain is EGGE.gg - this feels more apt. :fried_egg:

I wouldn't want someone to go to the domain, like "EGGD.gg" and be thrown into some scammy stuff because they saw a link in a vanity address. There is the context that .gg domains don't like that sort of stuff and they would be banned from registering, but that wouldn't be a great experience for the community.

This will be the new address.

rEGGEgg9hQSHLxUwycGnmjW2GKX9thn2yH

This replaces the old address

rEGGDggxupqxJ3ZbDTLUzKtpHxHyhtUtiU

The rollout 🚜:

• [x] 1. New stack created with new wallet and secret seed in a pull-request branch that overwrites mainnet stack workflow
  • This will be using the same code, but based on it's invocation time; it may produce different results as it will reflect the markets during it's invocation.
• [x] 2. Announce change via twitter
• [x] 3. Reach out to ShortTheFomo where the oracle is featured, to notify of change
• [x] 4. Domain verify "🥚🥚" / with a EGGE.gg/.well-known/xrp-ledger.toml
• [x] #39
  • NOTE this might not be possible if the previous trust lines count towards the ledger objects via
    • if that's the case I'll black-hole the wallet, extracting what is possible 😙

https://xrpl-py.readthedocs.io/en/stable/source/xrpl.transaction.html?highlight=autofill#xrpl.transaction.safe_sign_and_autofill_transaction

TIL about autofill :nerd_face:

. After a brief period EGGE… inherits remaining EGGD… through a delete account transaction.

• [x] move remaining funds

• [x] is AccountDelete possible?

• ~blackhole wallet if AccountDelete not possible~

• NOTE this might not be possible if the previous trust lines count towards the ledger objects via

  • if that's the case I'll black-hole the wallet, extracting what is possible 😙

match csv delimiter of semicolon.

i think this makes sense if an aggregate of currencies where some use commas like the EUR ( € 10 € 10,10 € 10 000,10)

another wise decision from Wietse

https://www.quora.com/How-do-you-write-sums-of-euros-over-1-000-i-e-where-do-you-put-the-full-stops-and-the-commas

this also has the added benefit of matching the serialization of the XUMM oracle.

remove fee set to base_fee of the ledger, defer to autofill's lookup:

https://github.com/XRPLF/xrpl-py/blob/8b27082b71a987676970c7a403460c596d5feb6a/xrpl/asyncio/transaction/main.py#L183

xrplcluster.com responds with a message when being throttled that creates an avalanche of failures.

In the interim until my node is available, I may have to swap between json-rpc urls

This should resolve the non-reporting gaps over the last 12 hours

don't check_fee (default=True) which might be getting us throttled at our freq..

on function invocation we cache this for subsequent re-use.

from main, prior to this merge: https://github.com/yyolk/xrpl-price-persist-oracle/blob/4895a1f1484d53f85e527d4619415fbc4c48a044/oracle/contract.py#L45

this addresses a step missing in 0.0.14; it was non-breaking as the result was the same as the prior 0.0.13 release of any exceptions.

the summary is identical to #43

starts to address #27 - by filtering out at the time of failure any chains of providers requests. Platforms that respond to at least the initial request will be included in the aggregate results

i.e.:

[ ❌ ] <~ won't be included
[ ✅ ✅ ❌ ] <~ will be included 👍 
[ ✅ ❌] <~ will be included 👍
[ ✅ ✅ ✅ ] <~ will be included 👍

see yyolk/xrp-price-aggregate#20 https://github.com/yyolk/xrp-price-aggregate/releases/tag/0.0.15 for more info

[email protected]

starts to address #27 - by filtering out at the time of failure any chains of providers requests. Platforms that respond to at least the initial request will be included in the aggregate results

i.e.:

[ ❌ ] <~ won't be included
[ ✅ ✅ ❌ ] <~ will be included 👍 
[ ✅ ❌] <~ will be included 👍
[ ✅ ✅ ✅ ] <~ will be included 👍

see yyolk/xrp-price-aggregate#19 and https://github.com/yyolk/xrp-price-aggregate/releases/tag/0.0.14 This is a broad stroke.

see yyolk/xrpl-price-persist-oracle-metrics#1 - now using a more optimal on-demand graph fetch (still cached) that doesn't involve running a function every 5 minutes. :sunglasses:

closes #34

https://github.com/yyolk/xrp-price-aggregate/releases/tag/0.0.13

notably, threexrp.dev is temporarily dropped (see yyolk/xrp-price-aggregate#13)

While using the JsonRPCClient; the oracle will see an abundance of JSONDecodeErrors that are coming as a result of the server saying it's too busy.

I was aware of this happening, and was swallowing, notifying and then raising FailedExecutionWillRetry

Got a JSONDecodeError of 'Expecting value: line 1 column 1 (char 0)'. Retrying the transaction by failing this execution.

JSONDecodeError: Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
  File "/var/lang/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 850, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/var/task/contract.py", line 45, in <module>
    base_fee = get_fee(xrpl_client)
  File "/var/task/xrpl/ledger/main.py", line 54, in get_fee
    return asyncio.run(main.get_fee(client))
  File "/var/lang/lib/python3.9/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/var/lang/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/var/task/xrpl/asyncio/ledger/main.py", line 64, in get_fee
    response = await client.request_impl(Fee())
  File "/var/task/xrpl/asyncio/clients/json_rpc_base.py", line 46, in request_impl
    return json_to_response(response.json())
  File "/var/task/httpx/_models.py", line 1415, in json
    return jsonlib.loads(self.text, **kwargs)
  File "/var/lang/lib/python3.9/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
  File "/var/lang/lib/python3.9/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/var/lang/lib/python3.9/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None

Not a bug but a suggestion

• i would look at changing up some of the data sources compared with xumm
• there is value in having some over lap but your well over 50%

My suggestion is as follows.

• Bistamp and Kraken should def stay
• FTX is mostly a derivatives exchange, but they do have the one fiat pair (keep that in mind from its data) it a good outsider.
• Bitrue is USD via tether! It should have a lower weighting in the overall price, if you want to keep that in the price calculation.
• add Bitso, cryptocom I am waiting on the new coinsph websocket to launch when that pro exchange fires up that def should go in there.
• Lastly is phemex they provide most of the tech for all the fiat on ramps all exchanges use, this IMO is an important one.

Rocking.

🕳️ in data as a result of a few causes that will be fixed soon :)

• [ ] Most issues are caught by XRPLSendReliableTransaction - our SLA is 4 ledgers. This will be fine-tuned. 4 was indeed a good threshold if we were to retry manually, we may defer to xrpl-py (investigate)

• [ ] terQueued sometimes we get queued! (but theres a probability we'll make it in on their behalf, we can't rely on it though) We see gaps in our data, but there might be some that made it through - this is the relevant lines: https://github.com/yyolk/xrpl-price-persist-oracle-sam/blob/9407737d760d172e8e7e732c4d8edc4e4b59ace0/oracle/contract.py#L231-L253

• [ ] telInsufFee base fee of 10 💧, we sometimes miss for an overloaded ledger!

• [ ] xrp-price-aggregate should be more robustful yyolk/xrp-price-aggregate#17

• [ ] #29

I do see this as a bug+enhancement, the end result most likely is we may we spend a bit more drops to ensure we're publishing every minute.