Jump to content

jn_r

Member
  • Posts

    964
  • Joined

Everything posted by jn_r

  1. It is what you often see as more and more people attend the pool. But at one point some sort of balance is achieved. You also have to be careful for the pools where the reward asset is staked (in this case SFIN and especially SFIN/CAND) as the staked items tend to decrease in value, since more and more of the reward assets enter the market. On the other hand if the asset really has promise value then you might end up big winner. Depends on your risk appetite I guess. Also we see lately that SFIN decreases in value, so overall the rewards decrease in comparison to the stake. Here's an updated overview: ------------------------------------------------------------------------------------------------------ SGB/CAND: 0.0935 EXFI/CAND: 3.7009 SFIN/CAND: 80153.52 ------------------------------------------------------------------------------------------------------ Farm | Token1 total | Token2 total | Total in CAND | Reward | Reward per 1000 CAND | APR ------------------------------------------------------------------------------------------------------ SFIN | 31.189149 | | 2499920.17 CAND | 0.1370 | 0.00005480 SFIN | 160.42% SFIN/CAND | 19.706633 | 1579556.09 | 3159112.18 CAND | 0.4110 | 0.00013009 SFIN | 380.84% EXFI/CAND | 634188.49 | 2347048.82 | 4694097.65 CAND | 0.4110 | 0.00008755 SFIN | 256.31% EXFI/SGB | 987148.91 | 38719224.92 | 7274017.18 CAND | 0.4110 | 0.00005650 SFIN | 165.40% SGB/CAND | 26384538.56 | 2467268.07 | 4934536.14 CAND | 0.4110 | 0.00008328 SFIN | 243.82% EXFI | 6042866.39 | | 22363859.73 CAND | 0.2740 | 0.00001225 SFIN | 35.87% CAND | 2475387.85 | | 2475387.85 CAND | 0.0685 | 0.00002767 SFIN | 81.01% WSGB | 353449847.30 | | 33051763.29 CAND | 0.2740 | 0.00000829 SFIN | 24.27% ------------------------------------------------------------------------------------------------------
  2. Found the programming solution, pretty easy (obviously once you know it), just take totalSupply of the farm contract. Anyways, here's a last update. Maybe I'll check for a contract retrieval of the 'reward', then I'll be fully chain-based (am pressing buttons now and leaning backwards ): ------------------------------------------------------------------------------------------------------ SGB/CAND: 0.1030 EXFI/CAND: 3.5230 SFIN/CAND: 84839.99 ------------------------------------------------------------------------------------------------------ Farm | Token1 total | Token2 total | Total in CAND | Reward | Reward per 1000 CAND | APR ------------------------------------------------------------------------------------------------------ SFIN | 31.675909 | | 2687383.71 CAND | 0.1369 | 0.00005094 SFIN | 157.86% SFIN/CAND | 17.285106 | 1466468.20 | 2932936.40 CAND | 0.4109 | 0.00014010 SFIN | 434.13% EXFI/CAND | 619440.66 | 2182267.38 | 4364534.76 CAND | 0.4109 | 0.00009415 SFIN | 291.74% EXFI/SGB | 1111423.84 | 37806925.81 | 7810564.83 CAND | 0.4109 | 0.00005261 SFIN | 163.02% SGB/CAND | 24272847.56 | 2500709.93 | 5001419.87 CAND | 0.4109 | 0.00008216 SFIN | 254.59% EXFI | 7089000.76 | | 24974297.08 CAND | 0.2739 | 0.00001097 SFIN | 33.99% CAND | 2126875.86 | | 2126875.86 CAND | 0.0684 | 0.00003216 SFIN | 99.66% WSGB | 318972348.04 | | 32862123.69 CAND | 0.2739 | 0.00000833 SFIN | 25.83% ------------------------------------------------------------------------------------------------------
  3. Here's a new overview, now with SFIN farm excluding the 'pool Supply'. I hardcoded the 'pool Supply' to 47.2005, I don't know how to retrieve it from the smart contract. ------------------------------------------------------------------------------------------------------ SGB/CAND: 0.0988 EXFI/CAND: 3.3815 SFIN/CAND: 86004.67 ------------------------------------------------------------------------------------------------------ Farm | Token1 total | Token2 total | Total in CAND | Reward | Reward per 1000 CAND | APR ------------------------------------------------------------------------------------------------------ SFIN | 31.604147 | | 2718104.18 CAND | 0.1369 | 0.00005037 SFIN | 158.22% SFIN/CAND | 17.154435 | 1475361.47 | 2950722.94 CAND | 0.4109 | 0.00013925 SFIN | 437.44% EXFI/CAND | 633847.27 | 2143381.83 | 4286763.65 CAND | 0.4109 | 0.00009585 SFIN | 301.11% EXFI/SGB | 1110100.57 | 37838816.11 | 7493603.54 CAND | 0.4109 | 0.00005483 SFIN | 172.25% SGB/CAND | 24763860.16 | 2447504.24 | 4895008.48 CAND | 0.4109 | 0.00008394 SFIN | 263.69% EXFI | 7088883.43 | | 23971364.49 CAND | 0.2739 | 0.00001143 SFIN | 35.89% CAND | 2144497.16 | | 2144497.16 CAND | 0.0684 | 0.00003190 SFIN | 100.19% WSGB | 344794663.58 | | 34077336.75 CAND | 0.2739 | 0.00000804 SFIN | 25.25% ------------------------------------------------------------------------------------------------------
  4. That explains the difference l see in the SFIN pool, my 78 includes both the 'pool supply' and the 'total staked' :-) Check: 31.6344 + 47.2005 = 78.8349
  5. good idea :-) I can not understand where the difference comes from with the SFIN pool, I've noticed it too and no explanation. For this single pool I check the amount of SFIN tokens that the SFIN Farm account holds (check the link). It points 78 SFIN. The same procedure I did for the other single tokens and for those others it does match. (CAND, EXFI, SGB) I don't know what the 'pool supply' is, also looking forward for someone to explain :-)
  6. But you should calculate the Total Staked to 1 type of value, e.g. CAND. Only then you can compare.. I scripted it, seems rather useful to have this ready under the button (the APRs should of course be in the GUI). Not 100% sure I made no errors, but I think these are the current numbers (scroll to the right for the APR): ------------------------------------------------------------------------------------------------------ SGB/CAND: 0.0924 EXFI/CAND: 3.2133 SFIN/CAND: 87310.87 ------------------------------------------------------------------------------------------------------ Farm | Token1 total | Token2 total | Total in CAND | Reward | Reward per 1000 CAND | APR ------------------------------------------------------------------------------------------------------ SFIN | 78.175965 | | 6825611.50 CAND | 0.1369 | 0.00002006 SFIN | 63.96% SFIN/CAND | 16.676115 | 1456006.08 | 2912012.17 CAND | 0.4109 | 0.00014111 SFIN | 449.99% EXFI/CAND | 646607.51 | 2077734.69 | 4155469.39 CAND | 0.4109 | 0.00009888 SFIN | 315.34% EXFI/SGB | 1095356.19 | 38058832.18 | 7035236.47 CAND | 0.4109 | 0.00005841 SFIN | 186.26% SGB/CAND | 25672957.41 | 2371444.61 | 4742889.22 CAND | 0.4109 | 0.00008663 SFIN | 276.28% EXFI | 7093985.35 | | 22795001.95 CAND | 0.2739 | 0.00001202 SFIN | 38.32% CAND | 2459513.96 | | 2459513.96 CAND | 0.0684 | 0.00002781 SFIN | 88.69% WSGB | 426072186.05 | | 39356844.33 CAND | 0.2739 | 0.00000696 SFIN | 22.19% ------------------------------------------------------------------------------------------------------
  7. Since you are a senior system engineer, why not check out the code and make a PR or an issue? Turns out you're not the only one working on the topic of transaction ordening. Although not working on a chronological tx ordering as you wished, but maybe a good starting point: https://github.com/ripple/rippled/pull/4077 Maybe you can chip-in, or otherwise get more acquainted with the why's and the how's and the why not's of XRPLedger. edit: also a good source for documentation: https://xrpl.org/transaction-queue.html#order-within-the-queue edit2: a must read if you really want to know how the consensus works: https://xrpl.org/consensus.html
  8. There is an issue with chronologic ordering because blockchain is all public. Also the 'pending tx pool' (in ethereum sometimes called the darkpool/forest) is visible for everyone. What we are seeing now in Ethereum is that this dark pool is exploited by 'searchers', looking for an opportunity where they place a trade just in front of another trade, or right behind, or sandwich, several possibilities exists to scr*w with some of the 'honoust' transactions waiting to be included in the next block. The ultimate beneficials are the miners, because they can determine which transactions are added and in which order to the next block. As matter of fact, they are now requesting a 'bribe' from the searchers so that their transactions are included. As you can imagine, this drives in the end all the profitability to the miners. The searchers being the puppets of the miners, getting some crumbs of the leftover profit. This is what they call MEV: Miner Extractable Value. XRPLedger does it different. First of all, not 1 miner decides on the (order of) transactions in a block, but all validators (34 currently) simultaneously. There is no cheating possible, everyone must agree on which transactions are included and in which order they are included. The order, as explained earlier, made as random as practically possible. This gives a system that, at least in my view, is more honest than e.g. the ethereum system. A system where incoming transactions are taken based on time would be maybe even more honest, but that is practically very difficult to achieve in a decentralized world, as not all nodes in a blockchain have the same time, network might be slow in certain parts of the network, etc..
  9. When looking at the trades from r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n is doesn't seem like market manipulation to me. It's just a market maker, maybe market taker, continuously providing offers in the orderbook. Also the front-running imo is very hard to let take place on XRPLedger. Trades are not executed on the order of first offer basis. With XRPLedger transactions are gathered during a certain time window (+/- 4 seconds). After that the transactions selected to be included in that ledger are ordered according to a randomization algorithm based on the tx hashes, meaning it is very hard to have your transaction placed in front of another transaction. You can't know at which place your tx will be executed. Although I have heard from some (rubble labs?) that it would be possible. I think with some trial/erroring-playing with the tx hash value, might get you in front, but I think it's really hard. But for this account, just check at https://xrpscan.com/account/r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n I don't see that as front-running or market manipulation, just providing continuously orders to the order book based on some calculation, maybe based on a price taken from a CEX
  10. One way is checking #setup-guides in the discord, another is after having done a transaction to the LP, check with which account your own account transacted via the songbird-explorer. No, it's not. the LP is a contract that holds these tokens itself. The LP contract holds 2 'buckets' of tokens. When you 'swap', you add a little to the tokenA token and you take a little from the tokenB bucket. you can find the amount of these token buckets also in songbird-explorer, under the specifics of the LP in question via the button 'tokens'. That is correct. The 2 buckets are separate from the totalSupply of the LP token itself. No, it was meant as 1 LP token is equal to so many SGB tokens and so many CAND tokens. Meaning, if you remove 1 LP token then you would receive so many SGB tokens and so many CAND tokens. I think Brianwalden does have a point :-) the LP tokens in itself don't mean much. Anyways, if you want to know more, there is lots of information to be found on the internet on how AMM's (Automated Market Maker) work, if you find that interesting it's worth to watch or read a view.
  11. you can find the on songbird explorer. The CAND/SGB LP address is 0x47C830E141234d029D953dF39B13d7728eB9f2d4 The amount of tokens can be found here: https://songbird-explorer.flare.network/address/0x47C830E141234d029D953dF39B13d7728eB9f2d4/tokens And the total Supply can be found here: https://songbird-explorer.flare.network/token/0x47C830E141234d029D953dF39B13d7728eB9f2d4/token-transfers If the liquidity pool does not exist yet, that's an edge case. The first person decides on the price and stakes an amount of tokenx and an amount of tokeny. In that case a number must be chosen, they usually take something like the sqrt from (amount_tokenx * amount_tokeny)
  12. you should look at the totalSupply and the total reserve of both tokens: totSupply = 7,373,128.19 reserve_SGB = 23,899,445.776 reserve_CAND = 2,889,250.578 1 SGB/CAND LP = (reserve_SGB/totalSupply) SGB + (reserve_CAND/totalSupply) CAND
  13. That would be basically up to the project. But I wouldn't make it too hard. e.g. Black list Ripple's big wallets and all known exchanges. Do the airdrop based on the amount of XRP an account has, but put a max on the airdropped amount per address, like e.g. 1.000.000 This wil still send out to some missed exchanges and others that are wealthy enough, but the amounts are not extreme. In case you want to pursue a certain public and thank them for their community efforts or whatever you could work with a whitelist based on some actions than can be measured on-chain.
  14. True, but chances are low they will lower the account reserves only for you because you were locked-out :-) Anyways, I think escrowing an IOU does not have much value because the real value is in the hand of the issuer. On the other hand if it is a non-IOU (via a trustless bridge - still hope this will one day become possible - maybe via Flare) or one of those trustline-currencies where the issuer has been blackholed (making it also trustless) then it might be useful after all.
  15. Interesting, but .. wouldn't you still be able to change the account setting to enable receiving XRP again? edit. Ahh no, you need a little XRP for that. Nice :-) But tricky also, you might lock yourself out forever
  16. I think taxes is still the most likely reason that he stopped and is now continuing. The thought occurred to me with the XRP sells of Jed, that has been going through so many legal hoops, that there actually might be a legal security contract behind, so no matter the outcome of the case, the Jed sales are legal. Remember it is not the XRP that is a security, but it is the act of selling that could make it being sold as a security. Jed is btw not selling in US, but at a Europe based exchange (Bitstamp). although reading this Bitstamp statement - https://blog.bitstamp.net/post/xrp-trading-and-deposits-be-halted-us-customers - saying the following: This last statement is tricky, it is not really possible to distinguish between US or non-US citizens, it would mean an all or nothing. You can draw parallel with if are you allowed as (US)company to do anything on Ethereum or other blockchain, so interesting in its own way..
  17. I think the way it is currently done by most projects on XRPL is not handy. A powerful trick in decentralized world, is not do it yourself, but let each entity do it themselves. That is what you see with Ethereum airdrops, people have to sort of collect the coins themselves. You can do that with XRPL too. in advance you take a snapshot at a certain date. You DONT tell anyone. you determine a blacklist, or a whitelist. If an account is on the blacklist, or not on the whitelist, they can not collect the airdrop. (And if you feel you are not rightfully on the blacklist, you can discuss with the airdropper) you make public that you have done an airdrop. People who want to collect, create a trust-line and click on a link to receive their legitimate airdrop. you close the airdrop after a certain time. So there is window in which you can collect your airdrop. This approach has several advantages. Namely people that do not want to receive the airdrop do not have to do anything. Nobody can game this, because it is not known in advance when the snapshot will be taken. I cannot think of disadvantages. There is one disadvantage, or maybe sort of the same as in the original solution, the airdropper still has to send every transaction himself
  18. Glad to hear that, that's reassuring for the Bifrost users. In case the wallet is browser based, that would be an option. Even Elixxir does it currently this way, although I don't like it. The advantage is they can update their wallet instantly for everyone, the disadvantage being, well, things like this. (imo leaving your secret at a site is scary sh*t and should be avoided at all times. But yeah, paswords and such, easier said then done. Let's say some secrets should never be left at a site ) Sorry for your financial loss, but happy to see there is more clarity now.
  19. Could you elaborate a bit more on how you tried to log in on this site? I'm not familiar with Bifrost wallet, but what I shortly read, it is multi-chain, so it probably holds the masterprivatekey/24 words? If Bifrost wallet manages this key correct, it should not leave the wallet and should not make the hack possible..But if the key left Bifrost wallet, then people should be aware..
  20. This is more a question for either Binance chain or Trust wallet. I found these links that should get you further: https://community.trustwallet.com/t/what-are-binance-peg-tokens/568 https://community.trustwallet.com/t/convert-binance-peg-tokens-to-native-assets/176123
  21. First off, I don't think XUMM is a scam, they are one of the most trusted parties currently working with the XRPL. 2nd, a trustline cannot be blackholed? Maybe a poor choice of wording. Checking your transactions, it was a trustline to gatehub that was set to 0, which a hacker can do if they have access to your private key. Which rings some other bells, Gatehub has been victim of a hack in the past and if your account has been previously used on Gatehub, then that might very well be the source of your account hacked. Curious to know, did you register this account also at Gatehub? See a thread on the subject here..
  22. I think he makes some really good points, but he kind of jumps over the fact that the content of an IPFS page is immutable, i.e. the IPFS URL is the actual hash of the content of the IPFS page. Which basically is - if you don't worry about losing your data - security wise just as secure as the blockchain.
  23. The code is still available/accessible here: https://github.com/ripplerm/RippleDividend How he traded I'm not sure to remember correct, but I thought mainly through arbitrage with the available assets on XRPL. It was particularly nice, as you could earn some yield + it would also give extra liquidity in the order books which was good for the usage of the XRPL ecosystem in that time.
  24. Things seem to have changed a lot with the xrpl.js client update. I would use 'getBalances' in the previous javascript lib, but with the xrpl.js, it's all different. I think that you should use the request method() function described here: https://js.xrpl.org/interfaces/GatewayBalancesRequest.html
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.