I learning about blockchain and look in mana token Decentraland. I compared total supply in etherscan and polygonscan but there are difference why?
The Total Supply coinmarketcap: 2,193,554,627 https://coinmarketcap.com/currencies/decentraland/
The Max Total Supply: etherscan: 2,193,554,627 https://etherscan.io/token/0x0f5d2fb29fb7d3cfee444a200298f468908cc942
The Total Supply polygonscan: 3,881,772 https://polygonscan.com/token/0xa1c57f48f0deb89f569dfbe6e2b7f46d33606fd4
any one can answer for it pleas.
I know some tokens use polygon or binance chain beside ethereum to add more scalable and less fee? if that true
but there are difference why?
One of the numbers is wrong.
add more scalable and less fee? if that true
yes
Related
I can't find in any way what is the difference between tvm.rawReserve(address(this).balance, 0) и tvm.accept()?
Before executing a smart contract:
the total amount of ever on the contract address and those who came with message is considered (for external message 0, for internal how many were sent)
storage fee is deducted from this amount
execution of the smart contract begins
For payment for the execution of a smart contract, it is always debited from the account balance.
if it is an external message (and 0 coins were transferred with it)
that is, a small credit for which you can check the require and, if something is wrong, cancel the transaction. in this case, nothing will be removed from the account balance.
If the checks were successful and it is necessary to execute the rest of the function code, payment for the execution of the transaction is made from the balance of the contract:
tvm.accept() — no gas limit
tvm.rawReserve(uint value, uint8 flag) — set the gas limit, that is, we reserve part of the funds and it will not be possible to spend more than this value. See also tvm.setGasLimit(uint g).
I'm a noob at Ethereum and need to make statistics from blockchain data.
I have a full node up and running with RPC ready, but can't find a clue in the doc on how to query :
Total number of transactions in/out for a contract/address
Total number of ether sent/received for a contract/address
The only solution I found was to parse all blocks and transactions in a double for loop and the performance is way too slow to do this.
Can someone help me ?
TL;DR : How do you do getTotalAmountSentTo(address) and getTotalNumberOfTransactionsFor(address) in Ethereum?
If you are using web3JS you can use web3.eth.filter function to find all the transactions you are interested in.
I am currently studying the bitcoin and litecoin to try and get a better understanding of cryptocurrencies, and blockchains in general - and I have spotted something in the code that I have a question about.
in src/amount.h - I see the following code...
/** No amount larger than this (in satoshi) is valid.
*
* Note that this constant is *not* the total money supply, which in Bitcoin
* currently happens to be less than 21,000,000 BTC for various reasons, but
* rather a sanity check. As this sanity check is used by consensus-critical
* validation code, the exact value of the MAX_MONEY constant is consensus
* critical; in unusual circumstances like a(nother) overflow bug that allowed
* for the creation of coins out of thin air modification could lead to a fork.
* */
static const CAmount MAX_MONEY = 84000000 * COIN;
Now, the comment here, seems to suggest that this code does not actually define what the total supply of the currency will be, even though the amount of Litecoin available is in fact 84,000,000...
So, my real question :
Is the real total supply held in another piece of code? If so, what am I missing, where can I find this code, and if I were to be trying to edit this (I'm not - but I want to understand what is going on here) - would I need to edit code in multiple places?
NOTE : Tagged bitcoin even though this is litecoin souce in the question, because litecoin doesn't appear to have a stackoverflow tag, and the two codebases are similar anyway.
EDIT : I also wanted to add, that I performed a grep for "84000000" - and only really found that one line of code to be relevant... So I must be missing something...
EDIT 2 : According to literally every coin out there on git that I have looked at - this is the number that they change when adjusting the total supply - so is the comment just wrong - or did I misunderstand it?
I realise this is an old question, but since it hasn't been updated I'll provide an answer.
As the source suggests, MAX_MONEY is simply a sanity check. If someone tries to create a transaction spending 500 million Bitcoin, and it somehow manages to bypass all other sanity checks, the network will still reject it because the amount exceeds MAX_MONEY. So MAX_MONEY is not directly related to total supply, but as you have observed, many alts will set MAX_MONEY to the expected total supply over the lifetime of the coin.
For a pure proof-of-work coin with consistent reward scheme (eg halving every X blocks) the total supply can be pre-calculated, but a future fork could change that.
For a typical proof-of-stake or hybrid proof-of-work and proof-of-stake coin, the maximum supply can be estimated by simulation, but the exact amount will vary depending on network activity.
(This assumes there is not another part of the code that cuts off all rewards after a limit is reached.)
Assume you are a test analyst working on a banking project to upgrade an existing automated teller machine system to allow customers to obtain cash advances from supported credit cards. The system should allow cash advances from 20 dollars to 500 dollars, inclusively, for all supported credit cards. The correct list of supported credit cards is American Express, Visa, Japan Credit Bank, Eurocard, and MasterCard. The user interface starts with a default amount of 100 dollars for advances, and the ATM keypad is used to increase or decrease that amount in 20-dollar increments.
Consider the decision table shown in table 1.0 that describes the handling of these transactions.
Table 1.0. Cash advance decision table
Check the table in attached image
Assume that you want to design a set of test cases where the following coverage is achieved:
Decision table coverage
Boundary values for allowed and disallowed advance amounts
Successful advance for each supported card
Design a set of test cases that achieves this level of coverage with the minimum possible number of test cases. Assume each test case consists of a single combination of conditions to create and a single combination of actions to check. How many test cases do you need?
Can someone help me understanding this problem and solution?
Thanks in Advance :-)
Decision table coverage Boundary values for allowed and disallowed advance amounts ->
Boundary values for your example will be: less than 0; 0; 20-500; 500+.
Equivalence partitioning, boundary value testing and decision table described here: http://www.maniuk.net/search/label/test%20design%20technique
Successful advance for each supported card ->
Set of instruction number 5 (in decision table) should be applied for all types of provided cars. Depends on risks #4 should be tested too.
Design a set of test cases that achieves this level of coverage with the minimum possible number of test cases. -->
a. If we can assume that cards work totally the same with the same limits and processing procedures so 9 test cases needed, during boundaries testing you can use different cards, so each card can be used. b. If we assume that some specific still exists in processing so 13 test cases needed (9 from previous test + 4 other cards to test instruction #5.
c. If cards has different limits by themselves addition verification will be needed.
For a number of financial instruments, Bloomberg scales the prices that are shown in the Terminal - for example:
FX Futures at CME: e.g. ADZ3 Curncy (Dec-2013 AUD Futures at CME) show as 93.88 (close on 04-Oct-2013), whereas the actual (CME) market/settlement price was 0.9388
FX Rates: sometimes FX rates are scaled - this may vary by which way round the FX rate is asked for, so EURJPY Curncy (i.e. JPY per EUR) has a BGN close of 132.14 on 04-Oct-2013. The inverse (EUR per JPY) would be 0.007567. However, for JPYEUR Curncy (i.e. EUR per JPY), BGN has a close of 0.75672 for 04-Oct-2013.
FX Forwards: Depending on whether you are asking for rates or forward points (which can be set by overrides)... if you ask for rates, you might get these in terms of the original rate, so for EURJPY1M Curncy, BGN has a close of 132.1174 on 04-Oct-2013. But if you ask for forward points, you would get these scaled by some factor - i.e. -1.28 for EURJPY1M Curncy.
Now, I am not trying to criticise Bloomberg for the way that they represent this data in the Terminal. Goodness only knows when they first wrote these systems, and they have to maintain the functionality that market practitioners have come to know and perhaps love... In that context, scaling to the significant figures might make sense.
However, when I am using the API, I want to get real-world, actual prices. Like... the actual price at the exchange or the actual price that you can trade EUR for JPY.
So... how can I do that?
Well... the approach that I have come to use is to find the FLDS that communicate this scaling information, and then I fetch that value to reverse the scale that they have applied to the values. For futures, that's PX_SCALING_FACTOR. For FX, I've found PX_POS_MULT_FACTOR most reliable. For FX forward points, it's FWD_SCALE.
(It's also worth mentioning that how these are applied vaires - so PX_SCALING_FACTOR is what futures prices should be divided by, PX_POS_MULT_FACTOR is what FX rates should be multipled by, and FWD_SCALE is how many decimal places to divide the forward points by to get to a value that can be added to the actual FX rate.)
The problem with that is that it doubles the number of fetchs I have to make, which adds a significant overhead to my use of the API (reference data fetches also seem to take longer than historical data fetches.) (FWIW, I'm using the API in Java, but the question should be equally applicable to using the API in Excel or any of the other supported languages.)
I've thought about finding out this information and storing it somewhere... but I'd really like to not have to hard code that. Also, that would require to spend a very long time finding out the right scaling factors for all the different instruments I'm interested in. Even then, I would have no guarantee that they wouldn't change their scale on me at some point!
What I would really like to be able to do is apply an override in my fetch that would allow me specify what scale should be used. (And no, the fields above do not seem to be override-able.) I've asked the "helpdesk" about this on lots and lots of occasions - I've been badgering them about it for about 12 months, but as ever with Bloomberg, nothing seems to have happened.
So...
has anyone else in the SO community faced this problem?
has anyone else found a way of setting this as an override?
has anyone else worked out a better solution?
Short answer: you seem to have all the available information at hand and there is not much more you can do. But these conventions are stable over time so it is fine to store the scales/factors instead of fetching the data everytime (the scale of EURGBP points will always be 4).
For FX, I have a file with:
number of decimal (for spot, points and all-in forward rate)
points scale
spot date
To answer you specific questions:
FX Futures at CME: on ADZ3 Curncy > DES > 3:
For this specific contract, the price is quoted in cents/AUD instead of exchange convention USD/AUD in order to show greater precision for both the futures and options. Calendar spreads are also adjusted accordingly. Please note that the tick size has been adjusted by 0.01 to ensure the tick value and contract value are consistent with the exchange.
Not sure there is much you can do about this, apart from manually checking the factor...
FX Rates: PX_POS_MULT_FACTOR is your best bet indeed - note that the value of that field for a given pair is extremely unlikely to change. Alternatively, you could follow market conventions for pairs and AFAIK the rates will always be the actual rate. So use EURJPY instead of JPYEUR. The major currencies, in order, are: EUR, GBP, AUD, NZD, USD, CAD, CHF, JPY. For pairs that don't involve any of those you will have to fetch the info.
FX Forwards: the points follow the market conventions, but the scale can vary (it is 4 most of the time, but it is 3 for GBPCZK for example). However it should not change over time for a given pair.