# Account Details Source: https://docs.minaexplorer.com/api-reference/accounts/account-details rest-api/openapi.json get /accounts/{public_key} Get the details of a Mina account # Blockchain Summary Source: https://docs.minaexplorer.com/api-reference/blockchain/blockchain-summary rest-api/openapi.json get /summary Returns summary information about the current chain # Get block Source: https://docs.minaexplorer.com/api-reference/blocks/get-block rest-api/openapi.json get /blocks/{state_hash} Return a block by protocol state hash # Get latest blocks Source: https://docs.minaexplorer.com/api-reference/blocks/get-latest-blocks rest-api/openapi.json get /blocks Get the latest blocks on the canonical chain. The default options return the latest block, but will return up to a maximum of 10 blocks. For full block data use the GraphQL API. # Broadcast Delegation Source: https://docs.minaexplorer.com/api-reference/broadcast/broadcast-delegation rest-api/openapi.json post /broadcast/delegation Broadcasts a signed delegation transaction to the Mina blockchain # Broadcast Transaction Source: https://docs.minaexplorer.com/api-reference/broadcast/broadcast-transaction rest-api/openapi.json post /broadcast/transaction Broadcasts a signed transaction to the Mina blockchain # Berkeley Source: https://docs.minaexplorer.com/block-explorer/berkeley > Support for the proxy service, GraphQL archive service and Archive API on Berkeley was funded via a [zkIgnite grant](https://zkignite.minaprotocol.com/zkignite/dev4dev-track-1/funded/suggestion/381). For the Berkeley testnet, the following services are available and supported: * **Explorer** - [https://berkeley.minaexplorer.com/](https://berkeley.minaexplorer.com/) * **API** - [https://berkeley.api.minaexplorer.com/](https://berkeley.api.minaexplorer.com/) * **Proxy Service** - [https://proxy.berkeley.minaexplorer.com/](https://proxy.berkeley.minaexplorer.com/) * **GraphQL Archive** - [https://berkeley.graphql.minaexplorer.com/](https://berkeley.graphql.minaexplorer.com/) * **Archive API** (actions and events data only) - [https://archive.berkeley.minaexplorer.com/](https://archive.berkeley.minaexplorer.com/) # Data Archive Source: https://docs.minaexplorer.com/block-explorer/data-archive ### Staking Ledgers | Epoch | Ledger Hash | Starting Slot | Last Block | | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------- | | 0 | [jxsAidvKvEQJMC7Z2wkLrFGzCqUxpFMRhAj4K5o49eiFLhKSyXL](https://storage.googleapis.com/mina-explorer-ledgers/jxsAidvKvEQJMC7Z2wkLrFGzCqUxpFMRhAj4K5o49eiFLhKSyXL.json) | 564480 | 363717 | | 1 | [jwgzfxD5rEnSP3k4UiZu2569FfhJ1SRUvabfTz21e4btwBHg3jq](https://storage.googleapis.com/mina-explorer-ledgers/jwgzfxD5rEnSP3k4UiZu2569FfhJ1SRUvabfTz21e4btwBHg3jq.json) | 571620 | 367837 | | 2 | [jw8dq1FtwJxbwqU1aYCxjY98fE21CqMDMynsXzRwAHAvM6yhx5A](https://storage.googleapis.com/mina-explorer-ledgers/jw8dq1FtwJxbwqU1aYCxjY98fE21CqMDMynsXzRwAHAvM6yhx5A.json) | 578760 | 371867 | | 3 | [jwPSjgLj5AsJtA1oTqMasQrxpeZx7pmGy5HKnAAhPBC4tYYvEj5](https://storage.googleapis.com/mina-explorer-ledgers/jwPSjgLj5AsJtA1oTqMasQrxpeZx7pmGy5HKnAAhPBC4tYYvEj5.json) | 585900 | 375866 | | 4 | [jxMWSYe3RVgbMCgoc7ot5wx3QN3M8YXPTgKyBMwKwSCdaY89jvQ](https://storage.googleapis.com/mina-explorer-ledgers/jxMWSYe3RVgbMCgoc7ot5wx3QN3M8YXPTgKyBMwKwSCdaY89jvQ.json) | 593040 | 379944 | | 5 | [jxq5Aw8Z4d7skbAmMFc3ZY8rvYSJ47NEs8Kv6ALfZRuqQ4WyXY4](https://storage.googleapis.com/mina-explorer-ledgers/jxq5Aw8Z4d7skbAmMFc3ZY8rvYSJ47NEs8Kv6ALfZRuqQ4WyXY4.json) | 600180 | 383981 | | 6 | [jxU9QkuXEZwKEYiwAJgbMzHQ1xDpYKhRua67kvnNhYZRA9jFPhe](https://storage.googleapis.com/mina-explorer-ledgers/jxU9QkuXEZwKEYiwAJgbMzHQ1xDpYKhRua67kvnNhYZRA9jFPhe.json) | 607320 | 387991 | | 7 | [jx2nVhtciYhqirG24xWCcDfyRjgxEbxahGbni2DhjkvaYq974DT](https://storage.googleapis.com/mina-explorer-ledgers/jx2nVhtciYhqirG24xWCcDfyRjgxEbxahGbni2DhjkvaYq974DT.json) | 614460 | 392048 | | 8 | [jwhzZrs2qUr1LrnWjgh5vToD9Fcbovu4rTWgFUJG1VqLpwB2NGh](https://storage.googleapis.com/mina-explorer-ledgers/jwhzZrs2qUr1LrnWjgh5vToD9Fcbovu4rTWgFUJG1VqLpwB2NGh.json) | 621600 | 396052 | | 9 | [jxR8kF5S5ebAgcfFCYhJPer7LhYrCmgFGGH8pZnLfCo6BYcidrz](https://storage.googleapis.com/mina-explorer-ledgers/jxR8kF5S5ebAgcfFCYhJPer7LhYrCmgFGGH8pZnLfCo6BYcidrz.json) | 628740 | 400059 | | 10 | [jxELBJq1CZj414V8b37msRiVS6sEEHQyHRgeWMgjPyHuAmzUnnK](https://storage.googleapis.com/mina-explorer-ledgers/jxELBJq1CZj414V8b37msRiVS6sEEHQyHRgeWMgjPyHuAmzUnnK.json) | 635880 | 403993 | | 11 | [jwvTnX2F11AbcPwQDKdmGYSpEq97JjboGgeQzZMaKDwrk9WhMxB](https://storage.googleapis.com/mina-explorer-ledgers/jwvTnX2F11AbcPwQDKdmGYSpEq97JjboGgeQzZMaKDwrk9WhMxB.json) | 643020 | 407930 | | 12 | [jxmhjnXWt2gBHZQakZxstuSm3x5so4A6iRKcHW3DSrS3CnxtGZe](https://storage.googleapis.com/mina-explorer-ledgers/jxmhjnXWt2gBHZQakZxstuSm3x5so4A6iRKcHW3DSrS3CnxtGZe.json) | 650160 | 411840 | | 13 | [jw8GREh6xXFeidrmNCBPdhnxb7UySmnQAhxpCZFhzEgRs2cBYqN](https://storage.googleapis.com/mina-explorer-ledgers/jw8GREh6xXFeidrmNCBPdhnxb7UySmnQAhxpCZFhzEgRs2cBYqN.json) | 657300 | 415733 | | 14 | [jwWgXXSyoRsYUrVS4hzR8cVprSTnigr5n1RLAPiU3GYiZnphqbS](https://storage.googleapis.com/mina-explorer-ledgers/jwWgXXSyoRsYUrVS4hzR8cVprSTnigr5n1RLAPiU3GYiZnphqbS.json) | 664440 | 419622 | | 15 | [jwG7JJmejgi1zjWpgfPEyHb1zwyQdPQV8t1kF9KHNKzLQmXNh1F](https://storage.googleapis.com/mina-explorer-ledgers/jwG7JJmejgi1zjWpgfPEyHb1zwyQdPQV8t1kF9KHNKzLQmXNh1F.json) | 671580 | 423456 | | 16 | [jxDw3ESZbHAcPUCHumF11PaJXtEJcdcjxcUaGgETyi8XpoF6Smr](https://storage.googleapis.com/mina-explorer-ledgers/jxDw3ESZbHAcPUCHumF11PaJXtEJcdcjxcUaGgETyi8XpoF6Smr.json) | 678720 | 427295 | | 17 | [jxNrphKDqCbNQTgvmZN3wvYynGTBjDbX4xnJMaNCiM3pkZK5cuh](https://storage.googleapis.com/mina-explorer-ledgers/jxNrphKDqCbNQTgvmZN3wvYynGTBjDbX4xnJMaNCiM3pkZK5cuh.json) | 685860 | 431143 | | 18 | [jxo6V3o7nMjK3arQd4Mm7Z4SZhErEELbb67ajMRPBnAmTSy6szy](https://storage.googleapis.com/mina-explorer-ledgers/jxo6V3o7nMjK3arQd4Mm7Z4SZhErEELbb67ajMRPBnAmTSy6szy.json) | 693000 | 435069 | | 19 | [jxyb5UaaPCLztB6KBujxyPMZj29d9NC5x6rfWPW8SU8pgpTVaJo](https://storage.googleapis.com/mina-explorer-ledgers/jxyb5UaaPCLztB6KBujxyPMZj29d9NC5x6rfWPW8SU8pgpTVaJo.json) | 700140 | 438917 | | 20 | [jwNgkdZmaT8kekYmspUncrDSdT5HQqrJQNvWCJ6JcGeKATyW4BZ](https://storage.googleapis.com/mina-explorer-ledgers/jwNgkdZmaT8kekYmspUncrDSdT5HQqrJQNvWCJ6JcGeKATyW4BZ.json) | 707280 | 442768 | | 21 | [jxFEmi9RUo7SArPwupC3QWdWPdoCYEWwhQhkMg9EeCM6QQV5HFs](https://storage.googleapis.com/mina-explorer-ledgers/jxFEmi9RUo7SArPwupC3QWdWPdoCYEWwhQhkMg9EeCM6QQV5HFs.json) | 714420 | 446583 | | 22 | [jxyJvcM4j4Mi2hNh6aLTB6wPChm5KtaaYGZBhTurWWBJ1278z5X](https://storage.googleapis.com/mina-explorer-ledgers/jxyJvcM4j4Mi2hNh6aLTB6wPChm5KtaaYGZBhTurWWBJ1278z5X.json) | 721560 | 450314 | | 23 | [jwGzgaRhjAwZvfowL6LhqC6mHEZ7mCeXd6Ps4njfUQYAvYcRRoQ](https://storage.googleapis.com/mina-explorer-ledgers/jwGzgaRhjAwZvfowL6LhqC6mHEZ7mCeXd6Ps4njfUQYAvYcRRoQ.json) | 728700 | 454063 | | 24 | [jwKbLH2f2xRAqgV1ohz618idSEmbARLJyjRUdnNFrsTwRVqVJCb](https://storage.googleapis.com/mina-explorer-ledgers/jwKbLH2f2xRAqgV1ohz618idSEmbARLJyjRUdnNFrsTwRVqVJCb.json) | 735840 | 457652 | | 25 | [jxMFuoiz2pCzKib7NY1JDeR8Q1YxDSWzVMHGK5hTpXP4tuV8nh5](https://storage.googleapis.com/mina-explorer-ledgers/jxMFuoiz2pCzKib7NY1JDeR8Q1YxDSWzVMHGK5hTpXP4tuV8nh5.json) | 742980 | 461154 | | 26 | [jxwu1655GJVWVvWy3u2gph4EXeiZ88EKA3SNrsHcjSrxLT7THbs](https://storage.googleapis.com/mina-explorer-ledgers/jxwu1655GJVWVvWy3u2gph4EXeiZ88EKA3SNrsHcjSrxLT7THbs.json) | 750120 | 464554 | | 27 | [jxwQULVyd44NLC1dYwWgfv75p5voHNVrCeLJeiycfpdvwSmhFfX](https://storage.googleapis.com/mina-explorer-ledgers/jxwQULVyd44NLC1dYwWgfv75p5voHNVrCeLJeiycfpdvwSmhFfX.json) | 757260 | 468004 | | 28 | [jwuZkDT7CUSxky3HduEXbTWBd1B9goXThFdH1uJ7pro4fJgab5b](https://storage.googleapis.com/mina-explorer-ledgers/jwuZkDT7CUSxky3HduEXbTWBd1B9goXThFdH1uJ7pro4fJgab5b.json) | 764400 | 471471 | | 29 | [jx3NmrFnggdbA2n1fJh8Y7uMK4gghTbAVhXv13nsPjmfRuGgf7d](https://storage.googleapis.com/mina-explorer-ledgers/jx3NmrFnggdbA2n1fJh8Y7uMK4gghTbAVhXv13nsPjmfRuGgf7d.json) | 771540 | 474911 | | 30 | [jwVzp6RpXfiNUNwVd1SuraZoEyF1PDHFjE7cqVkSkkwMdmEsRgm](https://storage.googleapis.com/mina-explorer-ledgers/jwVzp6RpXfiNUNwVd1SuraZoEyF1PDHFjE7cqVkSkkwMdmEsRgm.json) | 778680 | 478291 | | 31 | [jx2kYuQwUsNYuYWXkKczqvMSvdcKmeCTUx9QkRTpCJaQotgoWyx](https://storage.googleapis.com/mina-explorer-ledgers/jx2kYuQwUsNYuYWXkKczqvMSvdcKmeCTUx9QkRTpCJaQotgoWyx.json) | 785820 | 481659 | | 32 | [jwnuZ1gKvqkBvskrKhV84gD2z7kSTWVPsJohxg16VARpLz345f2](https://storage.googleapis.com/mina-explorer-ledgers/jwnuZ1gKvqkBvskrKhV84gD2z7kSTWVPsJohxg16VARpLz345f2.json) | 792960 | 485001 | | 33 | [jxAxNh9C2JoitepV5djDDyunkU6pU7Wd1YXECbRwHd2VxXDS2ZV](https://storage.googleapis.com/mina-explorer-ledgers/jxAxNh9C2JoitepV5djDDyunkU6pU7Wd1YXECbRwHd2VxXDS2ZV.json) | 800100 | 488278 | | 34 | [jwjmGqiXosGg6Yo9Nz3EnDh9v8iHdbtgAS5KWVyrGAp7cnzavX8](https://storage.googleapis.com/mina-explorer-ledgers/jwjmGqiXosGg6Yo9Nz3EnDh9v8iHdbtgAS5KWVyrGAp7cnzavX8.json) | 807240 | 491393 | | 35 | [jwAFURwbaAsQddS4qQovQvcq2gKm61Bx9hBf2EC1TMVr3TWHZ6c](https://storage.googleapis.com/mina-explorer-ledgers/jwAFURwbaAsQddS4qQovQvcq2gKm61Bx9hBf2EC1TMVr3TWHZ6c.json) | 814380 | 494414 | | 36 | [jy1vpELjgDmEWdU5cQfpCwQ3RfyGifaUUkh1unmGQCaeYPwMhdA](https://storage.googleapis.com/mina-explorer-ledgers/jy1vpELjgDmEWdU5cQfpCwQ3RfyGifaUUkh1unmGQCaeYPwMhdA.json) | 821520 | 497273 | | 37 | [jw6vWbTAx69iRb3ynYK9tMCN9w1DjK4YwHu19dYWKfZ9q9Qbkve](https://storage.googleapis.com/mina-explorer-ledgers/jw6vWbTAx69iRb3ynYK9tMCN9w1DjK4YwHu19dYWKfZ9q9Qbkve.json) | 828640 | 500128 | | 38 | [jy35zpiodcWZa67DRkKpvSyMZPjgabf79zRfm241fCMtNGUwyyE](https://storage.googleapis.com/mina-explorer-ledgers/jy35zpiodcWZa67DRkKpvSyMZPjgabf79zRfm241fCMtNGUwyyE.json) | 835780 | 502919 | | 39 | [jwaF595NrRx7Sz5VhPuo6XJZojbUzbTgDnS1ReiqUnM8jDptnL2](https://storage.googleapis.com/mina-explorer-ledgers/jwaF595NrRx7Sz5VhPuo6XJZojbUzbTgDnS1ReiqUnM8jDptnL2.json) | 842920 | 505736 | | 40 | [jx25o5nAVQ3WDLCh26nkzrpVv6ryayHAFsm1dgqVJjiVFGMB185](https://storage.googleapis.com/mina-explorer-ledgers/jx25o5nAVQ3WDLCh26nkzrpVv6ryayHAFsm1dgqVJjiVFGMB185.json) | 850060 | 508486 | | 41 | [jwkNu89sKhkfJ1BDXT27U6k9r4tGPc7BAFvgZ1bmFU8DwERgfzg](https://storage.googleapis.com/mina-explorer-ledgers/jwkNu89sKhkfJ1BDXT27U6k9r4tGPc7BAFvgZ1bmFU8DwERgfzg.json) | 857200 | | | 42 | [jxe9iNroVoV4veotTBNMUXXy1To929xBaq8gBeP976N5Vv1iUrB](https://storage.googleapis.com/mina-explorer-ledgers/jxe9iNroVoV4veotTBNMUXXy1To929xBaq8gBeP976N5Vv1iUrB.json) | 864340 | | | Epoch | Ledger Hash | Starting Slot | Last Block | | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ---------- | | 0 | [jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee](https://storage.googleapis.com/mina-explorer-ledgers/jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee.json) | 0 | 5075 | | 1 | [jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee](https://storage.googleapis.com/mina-explorer-ledgers/jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee.json) | 7140 | 10128 | | 2 | [jwAAZcXndLYxb8w4LTU2d4K1qT3dL8Ck2jKzVEf9t9GAyXweQRG](https://storage.googleapis.com/mina-explorer-ledgers/jwAAZcXndLYxb8w4LTU2d4K1qT3dL8Ck2jKzVEf9t9GAyXweQRG.json) | 14280 | 15219 | | 3 | [jxRySSfk8kJZVj46zveaToDUJUC2GtprmeK7poqWymEzB6d2Tun](https://storage.googleapis.com/mina-explorer-ledgers/jxRySSfk8kJZVj46zveaToDUJUC2GtprmeK7poqWymEzB6d2Tun.json) | 21420 | 20366 | | 4 | [jwPwVsSPZ2tmmGbp8UrWGmDgFDrrzTPpYcjpWosckmcVZV2kcW7](https://storage.googleapis.com/mina-explorer-ledgers/jwPwVsSPZ2tmmGbp8UrWGmDgFDrrzTPpYcjpWosckmcVZV2kcW7.json) | 28560 | 25454 | | 5 | [jxVF5YbC3B5Rk6ibfsL97WaqojfxrgWtEqMJST9pb4X8s3kRD2T](https://storage.googleapis.com/mina-explorer-ledgers/jxVF5YbC3B5Rk6ibfsL97WaqojfxrgWtEqMJST9pb4X8s3kRD2T.json) | 35700 | 30439 | | 6 | [jwJXdYzAikMHnTsw2kYyS1WQxJrGQsy1FKT5c18eHP2wGANafKf](https://storage.googleapis.com/mina-explorer-ledgers/jwJXdYzAikMHnTsw2kYyS1WQxJrGQsy1FKT5c18eHP2wGANafKf.json) | 42840 | 35657 | | 7 | [jxQgtuyHp8nA2P6F9CSRrLcVeHi8Ap7wVHeNnH2UbSX15izcSHK](https://storage.googleapis.com/mina-explorer-ledgers/jxQgtuyHp8nA2P6F9CSRrLcVeHi8Ap7wVHeNnH2UbSX15izcSHK.json) | 49980 | 40691 | | 8 | [jxct9rteQ7wjhQVf7h4mGQmGZprJMkjbzEWgU7VvV6HEq2DN5yA](https://storage.googleapis.com/mina-explorer-ledgers/jxct9rteQ7wjhQVf7h4mGQmGZprJMkjbzEWgU7VvV6HEq2DN5yA.json) | 57120 | 45739 | | 9 | [jxVLvFcBbRCDSM8MHLam6UPVPo2KDegbzJN6MTZWyhTvDrPcjYk](https://storage.googleapis.com/mina-explorer-ledgers/jxVLvFcBbRCDSM8MHLam6UPVPo2KDegbzJN6MTZWyhTvDrPcjYk.json) | 64260 | 50606 | | 10 | [jxhjiLBeMR7pgtV8ogcJvqXdr6asoNrC3g6hoUzEDLBSnZoxUDJ](https://storage.googleapis.com/mina-explorer-ledgers/jxhjiLBeMR7pgtV8ogcJvqXdr6asoNrC3g6hoUzEDLBSnZoxUDJ.json) | 71400 | 55533 | | 11 | [jx2XUFjvsvtTKB4HPAzih5boAtuoR34kxjEoU1RUhfXTATyx8tw](https://storage.googleapis.com/mina-explorer-ledgers/jx2XUFjvsvtTKB4HPAzih5boAtuoR34kxjEoU1RUhfXTATyx8tw.json) | 78540 | 60293 | | 12 | [jx4itrnmDkG3ptAiwhitJHt9K8stgFFoenrkZrm2prbtaS54xQU](https://storage.googleapis.com/mina-explorer-ledgers/jx4itrnmDkG3ptAiwhitJHt9K8stgFFoenrkZrm2prbtaS54xQU.json) | 85680 | 65066 | | 13 | [jwq7sAxDuN9MrdLjAQULoyrY5hWa6g52SVq8EmajBeBY38zamgz](https://storage.googleapis.com/mina-explorer-ledgers/jwq7sAxDuN9MrdLjAQULoyrY5hWa6g52SVq8EmajBeBY38zamgz.json) | 92820 | 69766 | | 14 | [jxPj7F7aRew1zvpW9JaGSgt9xmJitenrRSM6YGKnuhe5HXqyZtZ](https://storage.googleapis.com/mina-explorer-ledgers/jxPj7F7aRew1zvpW9JaGSgt9xmJitenrRSM6YGKnuhe5HXqyZtZ.json) | 99960 | 74463 | | 15 | [jxn15ATGoe4WGgYpbssxJH9XW8NXRDy22WvSsBqvMqcnLPgPAwN](https://storage.googleapis.com/mina-explorer-ledgers/jxn15ATGoe4WGgYpbssxJH9XW8NXRDy22WvSsBqvMqcnLPgPAwN.json) | 107100 | 79321 | | 16 | [jwAXd4GZgxE3YCwqs99g4MpLNiEV2ZfZPstyah4jxo753AVgL6R](https://storage.googleapis.com/mina-explorer-ledgers/jwAXd4GZgxE3YCwqs99g4MpLNiEV2ZfZPstyah4jxo753AVgL6R.json) | 114240 | 84066 | | 17 | [jwe63YTTUcc2b4sFdP54ehCZ3Dp9sZKshwCmtoVP3bidzfPfcxw](https://storage.googleapis.com/mina-explorer-ledgers/jwe63YTTUcc2b4sFdP54ehCZ3Dp9sZKshwCmtoVP3bidzfPfcxw.json) | 121380 | 88793 | | 18 | [jx5PU6GmyUqNuCnHNRF3pjHp7CTXXiCog4zJ1WcwHdyF3EJJ1Px](https://storage.googleapis.com/mina-explorer-ledgers/jx5PU6GmyUqNuCnHNRF3pjHp7CTXXiCog4zJ1WcwHdyF3EJJ1Px.json) | 128520 | 93311 | | 19 | [jxos2foijoacWtcKdjzqwv2PrU7je8XFDnsSVNGgrgJaJLeA8VE](https://storage.googleapis.com/mina-explorer-ledgers/jxos2foijoacWtcKdjzqwv2PrU7je8XFDnsSVNGgrgJaJLeA8VE.json) | 135660 | 97903 | | 20 | [jxBBSjakhQRKLbUM7z99KXNnMke2GbdcJyqpD9gyRoJJybsMRqh](https://storage.googleapis.com/mina-explorer-ledgers/jxBBSjakhQRKLbUM7z99KXNnMke2GbdcJyqpD9gyRoJJybsMRqh.json) | 142800 | 102358 | | 21 | [jxix1ap5gwXmiiwRqjijDv5KbHmnjAfj19CDywRLT1J8yTADcsT](https://storage.googleapis.com/mina-explorer-ledgers/jxix1ap5gwXmiiwRqjijDv5KbHmnjAfj19CDywRLT1J8yTADcsT.json) | 149940 | 106759 | | 22 | [jwV7BsK9rBf5uRWqMZmWKVAUcEcd7pDAo9NCFTrvSvXRjHCwypF](https://storage.googleapis.com/mina-explorer-ledgers/jwV7BsK9rBf5uRWqMZmWKVAUcEcd7pDAo9NCFTrvSvXRjHCwypF.json) | 157080 | 111388 | | 23 | [jwb5g4nyyMFvrXqN9wZLLb2TUx3Ux4gJ5F1k8Rt5nT9Eyaw9mZK](https://storage.googleapis.com/mina-explorer-ledgers/jwb5g4nyyMFvrXqN9wZLLb2TUx3Ux4gJ5F1k8Rt5nT9Eyaw9mZK.json) | 164220 | 116012 | | 24 | [jwHGGFvSf4BVMuQs65gXb384cGzdkbQDyr9rVUPnGDXa1kKJNne](https://storage.googleapis.com/mina-explorer-ledgers/jwHGGFvSf4BVMuQs65gXb384cGzdkbQDyr9rVUPnGDXa1kKJNne.json) | 171360 | 120727 | | 25 | [jx3Z9VyiCTMdif3cHZQVs1zfLKmkE8Z6N2CzTfDFi3gM6XyJaRa](https://storage.googleapis.com/mina-explorer-ledgers/jx3Z9VyiCTMdif3cHZQVs1zfLKmkE8Z6N2CzTfDFi3gM6XyJaRa.json) | 178500 | 125666 | | 26 | [jxAqNQwwU31ez8JPg6aJxugdX4uYnKFwbWGjqRtAxkfBBsLf2gf](https://storage.googleapis.com/mina-explorer-ledgers/jxAqNQwwU31ez8JPg6aJxugdX4uYnKFwbWGjqRtAxkfBBsLf2gf.json) | 185640 | 130590 | | 27 | [jxsdc9d3AkKmVSWZQExucepfuLwfzQHtZpiCFArGqtfVe5jveiZ](https://storage.googleapis.com/mina-explorer-ledgers/jxsdc9d3AkKmVSWZQExucepfuLwfzQHtZpiCFArGqtfVe5jveiZ.json) | 192780 | 135426 | | 28 | [jx29wpTRDF8tuMFXgqT8inkJhb5chPjtZiwgTHzs6GxsvAy5KiH](https://storage.googleapis.com/mina-explorer-ledgers/jx29wpTRDF8tuMFXgqT8inkJhb5chPjtZiwgTHzs6GxsvAy5KiH.json) | 199920 | 140335 | | 29 | [jxSi26fHMFyv8kxj4nBDDwi5FBt4oJummDjnfPodDbsNBzyjQdU](https://storage.googleapis.com/mina-explorer-ledgers/jxSi26fHMFyv8kxj4nBDDwi5FBt4oJummDjnfPodDbsNBzyjQdU.json) | 207060 | 145211 | | 30 | [jxDP6iJZGfNixGBiVasAnYYm1Fk29qWP2MecJ4mAg676DK7sQCM](https://storage.googleapis.com/mina-explorer-ledgers/jxDP6iJZGfNixGBiVasAnYYm1Fk29qWP2MecJ4mAg676DK7sQCM.json) | 214200 | 150057 | | 31 | [jwcWudRBTNZuMd1Tcyjzpr71buwc9RNmT2Jip1efA9eWvXcZiKL](https://storage.googleapis.com/mina-explorer-ledgers/jwcWudRBTNZuMd1Tcyjzpr71buwc9RNmT2Jip1efA9eWvXcZiKL.json) | 221340 | 154960 | | 32 | [jwVvWi6GLeL6mz9jVFtD1HA7GNVuqe8tjFedisASfk8WVmdcfKE](https://storage.googleapis.com/mina-explorer-ledgers/jwVvWi6GLeL6mz9jVFtD1HA7GNVuqe8tjFedisASfk8WVmdcfKE.json) | 228480 | 159841 | | 33 | [jw9ZJUdzn6NYSinWYuSEV27qKE2ZFXyvpzgxD5ZzsbyWYpeqnR8](https://storage.googleapis.com/mina-explorer-ledgers/jw9ZJUdzn6NYSinWYuSEV27qKE2ZFXyvpzgxD5ZzsbyWYpeqnR8.json) | 235620 | 164741 | | 34 | [jxHoMZnbhR25patdD3SeNQPe3U9MPctcRSRvPw7p7rpTKcZLB6t](https://storage.googleapis.com/mina-explorer-ledgers/jxHoMZnbhR25patdD3SeNQPe3U9MPctcRSRvPw7p7rpTKcZLB6t.json) | 242760 | 169591 | | 35 | [jx1t9ivUkPJq9QfewYxFEc9GGLQVRZupDa9LRYFQeqpr9JPb1jj](https://storage.googleapis.com/mina-explorer-ledgers/jx1t9ivUkPJq9QfewYxFEc9GGLQVRZupDa9LRYFQeqpr9JPb1jj.json) | 249900 | 174359 | | 36 | [jwJLfz7Pqfr3eRDFAMDw5TJ4Q3aD7ZZpP8YWKdWWU2iHU137NUE](https://storage.googleapis.com/mina-explorer-ledgers/jwJLfz7Pqfr3eRDFAMDw5TJ4Q3aD7ZZpP8YWKdWWU2iHU137NUE.json) | 257040 | 179181 | | 37 | [jwpXcZgEcdvSswWPkaKYBcq1jfydzqitb87psbroyW6FSmjiSL8](https://storage.googleapis.com/mina-explorer-ledgers/jwpXcZgEcdvSswWPkaKYBcq1jfydzqitb87psbroyW6FSmjiSL8.json) | 264180 | 184034 | | 38 | [jwHyH1qgW4iBRHEJEDo4yaxMW82VgNCLmQwHNzVKSxTapisydbo](https://storage.googleapis.com/mina-explorer-ledgers/jwHyH1qgW4iBRHEJEDo4yaxMW82VgNCLmQwHNzVKSxTapisydbo.json) | 271320 | 188888 | | 39 | [jw9FBsiQK5uJVGd8nr333vvctg3hPKf5kZUHf7f5bnUojWyNt3Z](https://storage.googleapis.com/mina-explorer-ledgers/jw9FBsiQK5uJVGd8nr333vvctg3hPKf5kZUHf7f5bnUojWyNt3Z.json) | 278460 | 193622 | | 40 | [jxxaCK9mMbnpCR3D5TS55Tit8y36E9jN8ER1P6Xry8TyHPYp1CY](https://storage.googleapis.com/mina-explorer-ledgers/jxxaCK9mMbnpCR3D5TS55Tit8y36E9jN8ER1P6Xry8TyHPYp1CY.json) | 285600 | 198290 | | 41 | [jwPQHxrJ94osTLCAiHYBuA6L4KGjkDV9t1A4mhdUoVEmbt2gxha](https://storage.googleapis.com/mina-explorer-ledgers/jwPQHxrJ94osTLCAiHYBuA6L4KGjkDV9t1A4mhdUoVEmbt2gxha.json) | 292740 | 202963 | | 42 | [jxYFH645cwMMMDmDe7KnvTuKJ5Ev8zZbWtA73fDFn7Jyh8p6SwH](https://storage.googleapis.com/mina-explorer-ledgers/jxYFH645cwMMMDmDe7KnvTuKJ5Ev8zZbWtA73fDFn7Jyh8p6SwH.json) | 299880 | 207460 | | 43 | [jxRhDLj6Q62jjRDNS2yYtDu6yHziPx6yLNXvPdgMfZaF3NFvJic](https://storage.googleapis.com/mina-explorer-ledgers/jxRhDLj6Q62jjRDNS2yYtDu6yHziPx6yLNXvPdgMfZaF3NFvJic.json) | 307020 | 211988 | | 44 | [jxdhN2AXg5v3c6KbGdmNW58hvdiTVULhXF3yztD8CdKNnGdf3jp](https://storage.googleapis.com/mina-explorer-ledgers/jxdhN2AXg5v3c6KbGdmNW58hvdiTVULhXF3yztD8CdKNnGdf3jp.json) | 314160 | 216401 | | 45 | [jxWMPncjMY9VhwehhVKHhobvJuAhZcdx5kfUtX4V3dy9Rw9aMZA](https://storage.googleapis.com/mina-explorer-ledgers/jxWMPncjMY9VhwehhVKHhobvJuAhZcdx5kfUtX4V3dy9Rw9aMZA.json) | 321300 | 220769 | | 46 | [jxQXzUkst2L9Ma9g9YQ3kfpgB5v5Znr1vrYb1mupakc5y7T89H8](https://storage.googleapis.com/mina-explorer-ledgers/jxQXzUkst2L9Ma9g9YQ3kfpgB5v5Znr1vrYb1mupakc5y7T89H8.json) | 328440 | 225196 | | 47 | [jwfyNt9AX6zRoWf67EcAzSQSDdLsS7Y8gZQPKmceCKo9C4hyKyX](https://storage.googleapis.com/mina-explorer-ledgers/jwfyNt9AX6zRoWf67EcAzSQSDdLsS7Y8gZQPKmceCKo9C4hyKyX.json) | 335580 | 229687 | | 48 | [jxZGkwwaAEXdKaFB12jdxfedApFQ4gDJ58aiSjNw9VUffBgAmdg](https://storage.googleapis.com/mina-explorer-ledgers/jxZGkwwaAEXdKaFB12jdxfedApFQ4gDJ58aiSjNw9VUffBgAmdg.json) | 342720 | 234125 | | 49 | [jwe5YREbjxzPCKe3eK7KfW5yXMdh71ca9mnMFfx9dBBQnRB6Rkb](https://storage.googleapis.com/mina-explorer-ledgers/jwe5YREbjxzPCKe3eK7KfW5yXMdh71ca9mnMFfx9dBBQnRB6Rkb.json) | 349860 | 238512 | | 50 | [jxaswvEn5WF82AHLwbzMJN5Ty6RNAH9azqMV2R9q4sJStCpMp3w](https://storage.googleapis.com/mina-explorer-ledgers/jxaswvEn5WF82AHLwbzMJN5Ty6RNAH9azqMV2R9q4sJStCpMp3w.json) | 357000 | 242807 | | 51 | [jwuGkeeB2rxs2Cr679nZMVZpWms6QoEkcgt82Z2jsjB9X1MuJwW](https://storage.googleapis.com/mina-explorer-ledgers/jwuGkeeB2rxs2Cr679nZMVZpWms6QoEkcgt82Z2jsjB9X1MuJwW.json) | 364140 | 247122 | | 52 | [jxWkqFVYsmQrXQZ2kkujynVj3TfbLfhVSgrY73CSVDpc17Bp3L6](https://storage.googleapis.com/mina-explorer-ledgers/jxWkqFVYsmQrXQZ2kkujynVj3TfbLfhVSgrY73CSVDpc17Bp3L6.json) | 371280 | 251431 | | 53 | [jxyqGrB5cSEavMbcMyNXhFMLcWpvbLR9a73GLqbTyPKVREkDjDM](https://storage.googleapis.com/mina-explorer-ledgers/jxyqGrB5cSEavMbcMyNXhFMLcWpvbLR9a73GLqbTyPKVREkDjDM.json) | 378420 | 255785 | | 54 | [jx6taGcqX3HpWcz558wWNnJcne99jiQQiR7AnE7Ny8cQB1ASDVK](https://storage.googleapis.com/mina-explorer-ledgers/jx6taGcqX3HpWcz558wWNnJcne99jiQQiR7AnE7Ny8cQB1ASDVK.json) | 385560 | 260121 | | 55 | [jw8dXuUqXVgd6NvmpryGmFLnRv1176oozHAro8gMFwj8yuvhBeS](https://storage.googleapis.com/mina-explorer-ledgers/jw8dXuUqXVgd6NvmpryGmFLnRv1176oozHAro8gMFwj8yuvhBeS.json) | 392700 | 264522 | | 56 | [jxXZTgUtCJmJnuwURmNMhoJWQ44X1kRLaKXtuYRFxnT9GFGSnnj](https://storage.googleapis.com/mina-explorer-ledgers/jxXZTgUtCJmJnuwURmNMhoJWQ44X1kRLaKXtuYRFxnT9GFGSnnj.json) | 399840 | 268851 | | 57 | [jwgDB316LgQr15vmZYC5G9gjcizT5MPssZbQkvtBLtqpi93mbMw](https://storage.googleapis.com/mina-explorer-ledgers/jwgDB316LgQr15vmZYC5G9gjcizT5MPssZbQkvtBLtqpi93mbMw.json) | 406980 | 273299 | | 58 | [jwUe5igYAtQWZpcVYxt6xPJywnCZqDiNng9xZQLSZfZKpLZ61Hp](https://storage.googleapis.com/mina-explorer-ledgers/jwUe5igYAtQWZpcVYxt6xPJywnCZqDiNng9xZQLSZfZKpLZ61Hp.json) | 414120 | 277700 | | 59 | [jxffUAqcai9KoheQDcG46CCczjMRzFk61oXSokjaKvphicMpPj5](https://storage.googleapis.com/mina-explorer-ledgers/jxffUAqcai9KoheQDcG46CCczjMRzFk61oXSokjaKvphicMpPj5.json) | 421260 | 282060 | | 60 | [jxKpSD4zcfKCSQQd3CG3yBqiesbUqm7eucRqLSvi9T1gUXtUPR5](https://storage.googleapis.com/mina-explorer-ledgers/jxKpSD4zcfKCSQQd3CG3yBqiesbUqm7eucRqLSvi9T1gUXtUPR5.json) | 428400 | 286370 | | 61 | [jxwahv5MsbGaUwSdAhyQA7Gr7atsyQbcju289PkoAnS4UgHGdce](https://storage.googleapis.com/mina-explorer-ledgers/jxwahv5MsbGaUwSdAhyQA7Gr7atsyQbcju289PkoAnS4UgHGdce.json) | 435540 | 290712 | | 62 | [jy1jMBD7atiiheMxufJQDDfBuC2BjSXGj2HC5uSjXXsjAsGZt71](https://storage.googleapis.com/mina-explorer-ledgers/jy1jMBD7atiiheMxufJQDDfBuC2BjSXGj2HC5uSjXXsjAsGZt71.json) | 442680 | 295150 | | 63 | [jwbeXmeEZ2aYSyXnBbsMqWUxVDouwYZdzCqBejTaoecCkHoinPy](https://storage.googleapis.com/mina-explorer-ledgers/jwbeXmeEZ2aYSyXnBbsMqWUxVDouwYZdzCqBejTaoecCkHoinPy.json) | 449820 | 299568 | | 64 | [jx4MPGB51t9MjrUh7NSsU6dLaouAb9bE2xu8b79kzmkEtKezwfw](https://storage.googleapis.com/mina-explorer-ledgers/jx4MPGB51t9MjrUh7NSsU6dLaouAb9bE2xu8b79kzmkEtKezwfw.json) | 456960 | 303887 | | 65 | [jxAzD4eVVmY4bFF9QnMrEmjG8rEXEgVCFbD4H85LVZu4c4Zmi9D](https://storage.googleapis.com/mina-explorer-ledgers/jxAzD4eVVmY4bFF9QnMrEmjG8rEXEgVCFbD4H85LVZu4c4Zmi9D.json) | 464100 | 307994 | | 66 | [jwvsYHPfACRUFYLL5NknBJc7zEY1q8t9rQfF8ek2pk2dUuKCz5J](https://storage.googleapis.com/mina-explorer-ledgers/jwvsYHPfACRUFYLL5NknBJc7zEY1q8t9rQfF8ek2pk2dUuKCz5J.json) | 471240 | 312153 | | 67 | [jxKCrryFrvzBE4iUURcS9zNTKcRdejiE9K28Bqcu7Us7RQqNfdL](https://storage.googleapis.com/mina-explorer-ledgers/jxKCrryFrvzBE4iUURcS9zNTKcRdejiE9K28Bqcu7Us7RQqNfdL.json) | 478380 | 316123 | | 68 | [jxJbw37Kd7KxNvy5yd322NFwYZUdsXCeeEfjqGJ3cY9ukMmxBiW](https://storage.googleapis.com/mina-explorer-ledgers/jxJbw37Kd7KxNvy5yd322NFwYZUdsXCeeEfjqGJ3cY9ukMmxBiW.json) | 485520 | 319973 | | 69 | [jxQwGGbtjRnhT1k7CqyASPKihyjFdtYSnJMANxdyWbHvGUofn8t](https://storage.googleapis.com/mina-explorer-ledgers/jxQwGGbtjRnhT1k7CqyASPKihyjFdtYSnJMANxdyWbHvGUofn8t.json) | 492660 | 323901 | | 70 | [jxw6YYsPFbC7bPqCcc6pVShATXbebaX1cxFqeV7Kyo1Pa5L3TU4](https://storage.googleapis.com/mina-explorer-ledgers/jxw6YYsPFbC7bPqCcc6pVShATXbebaX1cxFqeV7Kyo1Pa5L3TU4.json) | 499800 | 327945 | | 71 | [jxiXyAr4NX6Ne1jxMU4WsiYc6SeBajSQZgmro9b63yDfQEeunD3](https://storage.googleapis.com/mina-explorer-ledgers/jxiXyAr4NX6Ne1jxMU4WsiYc6SeBajSQZgmro9b63yDfQEeunD3.json) | 506940 | 331863 | | 72 | [jx4YTukDZVaFoiwYpKzzPmoCNzZgyXG1nHQkN7mwoJoB8aXMAmt](https://storage.googleapis.com/mina-explorer-ledgers/jx4YTukDZVaFoiwYpKzzPmoCNzZgyXG1nHQkN7mwoJoB8aXMAmt.json) | 514080 | 335682 | | 73 | [jwyody4XQNTnGxkXQEKf87AN27wXadAjYgnGLAtvHahDkn2uWDU](https://storage.googleapis.com/mina-explorer-ledgers/jwyody4XQNTnGxkXQEKf87AN27wXadAjYgnGLAtvHahDkn2uWDU.json) | 521220 | 339293 | | 74 | [jxvumaCvujr7UzW1qCB87YR2RWu8CqvkwrCmHY8kkwpvN4WbTJn](https://storage.googleapis.com/mina-explorer-ledgers/jxvumaCvujr7UzW1qCB87YR2RWu8CqvkwrCmHY8kkwpvN4WbTJn.json) | 528360 | 343305 | | 75 | [jx25quMPEvvipny2VxwDys5yCHaUL8oCMapfLv4eoRrsxEKm4pD](https://storage.googleapis.com/mina-explorer-ledgers/jx25quMPEvvipny2VxwDys5yCHaUL8oCMapfLv4eoRrsxEKm4pD.json) | 535500 | 347380 | | 76 | [jwqkCmcBJDi7XVRuW3dJpTGJ8ZbFeWo1iuzbQPmt536GeC5YChN](https://storage.googleapis.com/mina-explorer-ledgers/jwqkCmcBJDi7XVRuW3dJpTGJ8ZbFeWo1iuzbQPmt536GeC5YChN.json) | 542640 | 351474 | | 77 | [jwqNEHtM8gmFAThkBWzU2DQiUuK1rW52Z8zsHyxMtwxCMovLu5K](https://storage.googleapis.com/mina-explorer-ledgers/jwqNEHtM8gmFAThkBWzU2DQiUuK1rW52Z8zsHyxMtwxCMovLu5K.json) | 549780 | 355560 | | 78 | [jxXwNfemxGwZcxKGhfrwzfE4QfxxGm5mkYieHQCafFkb6QBf9Xo](https://storage.googleapis.com/mina-explorer-ledgers/jxXwNfemxGwZcxKGhfrwzfE4QfxxGm5mkYieHQCafFkb6QBf9Xo.json) | 556920 | 359534 | | 79 | [jxxZUYeVFQriATHvBCrxmtfwtboFtMbXALVkE4y546MPy597QDD](https://storage.googleapis.com/mina-explorer-ledgers/jxxZUYeVFQriATHvBCrxmtfwtboFtMbXALVkE4y546MPy597QDD.json) | 564060 | 359604 | # Devnet Source: https://docs.minaexplorer.com/block-explorer/devnet Assuming there will be a persistent testnet, we will operate all services on the testnet in addition to mainnet. The current URLs are: * **Explorer** - [https://devnet.minaexplorer.com/](https://devnet.minaexplorer.com/) * **API** - [https://devnet.api.minaexplorer.com](https://devnet.api.minaexplorer.com) * **GraphQL** - [https://devnet.graphql.minaexplorer.com/](https://devnet.graphql.minaexplorer.com/) # Explorer Name Service Source: https://docs.minaexplorer.com/block-explorer/explorer-name-service > The public key of the explorer name service is: **B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE** and the memo field must contain a prefix of **Name:** Since the early days of Mina's first testnets we have always displayed usernames on account pages to help users track their progress in the technical challenges. Now that mainnet has launched, we are only displaying addresses listed on [https://mina.staketab.com/](https://mina.staketab.com/) intended for use for staking providers and notable addresses such as the Foundation or O(1) Labs delegation addresses. While we did not intend to add individual information, primarily due to privacy concerns, a number of users wish to associate their account with their address. To facilitate this we have a simple name service to display a chosen name on the account page of the account holder. ![Add a name to the MinaExplorer account page](https://image-archive.developerhub.io/image/upload/v2_455/qturk6osfowozz5xl3we/1616619109.png) To ensure that only the address holder may update the information, a transaction must be broadcast on the Mina blockchain utilizing the memo field to the specified address. To identify this is a name request, the memo must begin with `Name:` You should send an amount of **0** and only pay the transaction fee. There will be a short delay in the site being updated, but you should be able to view the transaction on the [Name Service](https://minaexplorer.com/wallet/B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE) wallet page. **Memos are limited to 32 characters** that include the prefix. ```json theme={null} mina client send-payment --amount 0 --receiver B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE --fee 0.1 --sender --memo "Name: My new name" ``` ```json theme={null} mina_ledger_wallet send-payment 0 B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE 0 --offline --fee 0.1 --nonce 0 --memo "Name: My new name" ``` ## Retrieving names via GraphQL ### Obtain all name service transactions: ```json theme={null} query memoParser { transactions(query: {to: "B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE", canonical: true, memo_ne: "E4ZJ3rmurwsMFrSvLdSAGRqmXRjYeZt84Wws4dixfpN67Xj7SrRLu"}, sortBy: BLOCKHEIGHT_DESC) { from blockHeight memo } } ``` Memos are returned [Base58Check encoded](https://en.bitcoin.it/wiki/Base58Check_encoding). The query excludes where the memo is empty. ### Get the name associated with an account: ```json theme={null} query memoForAccount { transactions(query: {from: "B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE", to: "B62qjzJvc59DdG9ahht9rwxkEz7GedKuUMsnaVTuXFUeANKqfBeWpRE", canonical: true, memo_ne: "E4ZJ3rmurwsMFrSvLdSAGRqmXRjYeZt84Wws4dixfpN67Xj7SrRLu"}, sortBy: BLOCKHEIGHT_DESC, limit: 1) { memo } } ``` # FAQs Source: https://docs.minaexplorer.com/block-explorer/faqs ## Blocks ### What do the fields of a block mean? | Field | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Date | The time of the block creation. This is defined as the **start** of the allocated slot time. | | Creator | The public key of the creator of the block i.e. the block producer. | | State Hash | A unique identifier of the block. It is the hash of the hashes of the previous state state and the block body. | | Previous State Hash | The previous block's state hash. Blocks are connected together in this way to form an immutable chain. | | Snarked Ledger Hash | The hash of the current [snarked ledger](https://minaprotocol.com/docs/glossary#snarked-ledger). This ledger includes transactions that have been snarked. | | Staged Ledger Hash | The hash of the current [staged ledger](https://minaprotocol.com/docs/glossary#staged-ledger). This ledger includes transactions that are yet to be snarked. | | Coinbase | The amount of the coinbase transaction. | | Coinbase Receiver | The account receiving the block rewards. May be the same as creator or a different address. | | Transaction Fees | A sum of all transaction fees included in a block. | | Snark Fees | A sum of all snark fees paid by the block producer in a block to snark workers. | | Slot | The slot number when the block was produced. | | Blockchain Length | The height of the blockchain this block represents. | | Epoch | The epoch number when the block was produced. | | Total Currency | The total currency in circulation after this block was produced. New issuance is via the coinbase reward and new account fees can reduce the total issuance. | ### What does block not in canonical chain mean? This means that the block has been orphaned and is not in the main chain. There will be no block rewards for these blocks and there will be no balance changes as a result of transactions included. There can be more than one block producer per slot due to the way block producers are selected. So if two (or more) blocks are produced for the same slot, it will cause a short fork, and only one will be chosen - the winner in this instance is random based on the VRF output for each block producer. It is also possible to produce a block in catchup, and this block will also be quickly orphaned as it is not building on the correct height. ## Accounts ### My account is not listed in the ledger page This data is from the *staged ledger* and is updated periodically and is not real-time. It should be used as an overview of the top holders in Mina and not an accurate reflection of balances. You can query any information for an account directly on the [account page](https://minaexplorer.com/wallet/B62qizP44x4FJB746LRk6KCQQ1qNAFHKe9pDECzbJagZvriduXTx7zK). ## Transactions ### My transactions are stuck as pending Transactions with higher fees are given priority when being included in blocks. As a result some transactions with lower fees may become stuck until eventually included in a block, replaced with a higher fee transaction, or evicted from the transaction pool when it becomes full and there is a higher fee. ## Staking Ledger ### My balance or delegation in the staking ledger has not been updated Changes to the staking ledger are made once per epoch at the start of the epoch. The current epoch staking ledger is the snarked ledger of the last block of `current epoch - 2`. So, if you receive funds at the start of epoch 4, they will not be considered until the start of epoch 6. The same is true of sending delegation transactions, any delegations are only taken into account when the staking ledger is updated. *** # Advanced Querying Source: https://docs.minaexplorer.com/graphql-api/advanced-querying It is possible to construct advanced GraphQL queries using the following features. ## Comparison Operators A comparison operator field allows you to define a condition that is more complex than exact equality, such as a range query. | Operator | Description | | -------- | ------------------------------------------------------------------------------- | | gt | Finds results where the field is greater than the specified value. | | gte | Finds results where the field is greater than or equal to the specified value. | | lt | Finds results where the field is less than the specified value. | | lte | Finds results where the field is less than or equal to the specified value. | | ne | Finds results where the field is not equal to the specified value. | | in | Finds results where the field is equal to any value in the specified array. | | nin | Finds results where the field is not equal to any value in the specified array. | | exists | Finds documents where the field is not `null`. | ## Logical Operators A logical operator field allows you to define logical combinations of independent `QueryInput` objects. | Operator | Description | | -------- | ---------------------------------------------------------------------- | | AND | Finds documents that match *all* of the provided `QueryInput` objects. | | OR | Finds documents that match *any* of the provided `QueryInput` objects. | ```json theme={null} blocks( query: { AND: [ { protocolState: { consensusState: { epoch: 2 } } } { stateHash: "3NK6UJfL6WWvqsdLGdmpYpmmRrdR8oCZsq3AuWdRnH8WcmaFGiRn" } ] } ) ``` ```json theme={null} snarks( query: { OR: [ { prover: "B62qnwquaQY3xc8eReKbhQq3oE8WDuzufr4jNWnKVCXBiqzSTmTstS7" } { fee_gt: 40000 } ] } ) ``` ## Sorting You can sort in ascending and descending order by any root-level field that does not have a type of `object` or `array.` ```json theme={null} snarks( limit: 10 sortBy: FEE_DESC } ) ``` # Blocks Source: https://docs.minaexplorer.com/graphql-api/blocks Returns all archived block data. While user commands and snark work is also available, they each have dedicated collections to ease the querying and filtering of very deeply nested objects. ## Return the last 10 blocks from the canonical chain ```json theme={null} { blocks(query: { canonical: true }, sortBy: DATETIME_DESC, limit: 10) { creatorAccount { publicKey } stateHash dateTime protocolState { consensusState { blockHeight } } transactions { coinbase } } } ``` ## Find all blocks produced by a public key This query returns all blocks seen by the explorer node, whether on the canonical chain or not. ```json theme={null} { blocks( query: { creatorAccount: { publicKey: "B62qnZwmdaN8yHvonypfcHxCn2dRb3fRK7jKK8CmrG3trRhuUfE58iA" } } sortBy: DATETIME_DESC ) { creatorAccount { publicKey } stateHash protocolState { consensusState { blockHeight } } } } ``` ## Find all blocks produced past a certain date Add a date filter to limit your blocks by date. ```json theme={null} { blocks( query: { dateTime_gte: "2021-01-31T00:00:00Z" } sortBy: DATETIME_DESC ) { creatorAccount { publicKey } dateTime stateHash protocolState { consensusState { blockHeight } } } } ``` ## Find a block by state hash Get the full details for a block based on the protocol state hash of the block. > When returning a single result, you can use the block query. The blocks query will return multiple matching results. ```json theme={null} { block( query: { stateHash: "3NKF9BSvELt38KqhCYRVTjfY6BbGLHSXqQjoXRa51MRUCE736Wsh" } ) { creatorAccount { publicKey } dateTime stateHash protocolState { consensusState { blockHeight } } } } ``` ## Find a canonical block by height Find the canonical block for a specific height. Remember that a canonical block can be updated for `k` blocks before it reaches finality! ```json theme={null} { block( query: {canonical: true, blockHeight: 1212} ) { stateHash protocolState { consensusState { blockHeight } } winnerAccount { publicKey } creatorAccount { publicKey } transactions { coinbase } } } ``` ## Return all blocks between two heights Filter your queries based on the block height to retrieve a range of blocks based on height. ```json theme={null} { blocks( query: { AND: [ { canonical: true } { blockHeight_gte: 100 } { blockHeight_lte: 105 } ] } ) { stateHash protocolState { consensusState { blockHeight } } winnerAccount { publicKey } creatorAccount { publicKey } transactions { coinbase } } } ``` # Explore the API Source: https://docs.minaexplorer.com/graphql-api/explore-the-api Easily explore the GraphQL API by using the hosted [GraphiQL GUI](https://graphql.minaexplorer.com). ![Use GraphiQL to browse the API](https://image-archive.developerhub.io/image/upload/v2_455/ls8sid4q5dwofmojrbuy/1612145872.png) # Getting Started Source: https://docs.minaexplorer.com/graphql-api/getting-started > The GraphQL API is now deprecated following the Berkeley hard fork. It may be removed at any time. The MinaExplorer GraphQL API is an implementation of an archive service to return the full chain history via a GraphQL API. It maintains a familiar interface to the Mina node's [GraphQL API](https://minaprotocol.com/docs/developers/graphql-api) but has the advantages: * It returns all blocks on the chain rather than `k` blocks (without relying on an archive node). * It offers extensive querying and filtering capabilities for block, transaction and snark worker data. * It is much more performant that an equivalent `bestChain` query to extract blocks. * It removes the need to host an archive node, or build a custom API to extract archived data. * Can act as a backup for other archive node implementations as can recreate original GraphQL `blocks` subscription response. > The GraphQL API is available via **[graphql.minaexplorer.com](https://graphql.minaexplorer.com)** ## Authorization Currently the GraphQL API is unauthorized and allows public access. Requests are throttled to prevent abuse and we reserve the right to change the authorization mechanism in the future, depending on usage. The current limit for all unauthenticated users is **10000** requests per second with a burst of **5000** requests. For users who wish to authenticate requests to avoid any potential rate limiting please [contact us](https://docs.minaexplorer.com/minaexplorer/get-help). ## Collection The following archived data is exposed: * [Blocks](#) - containing the full block output including embedded user commands and snark work * [Transactions](#) - only user commands collection which are split out for easier querying and filtering * [Snarks](#) - only snark work which are split out for easier querying and filtering * [Current Staking Ledger ](#)- the current staking ledger, including querying for determining delegations * Next Staking Ledger - the next staking ledger. Only available after 290 blocks of the current epoch. ## Schema * [Mainnet](https://storage.googleapis.com/mina-explorer-data/schema.graphql) ## Making Your First Query The easiest way to construct a query is via the [GraphiQL interface](https://graphql.minaexplorer.com/). For a sample query, let's get the latest canonical block on the chain and see who won it. Visit the blocks documentation to learn more about querying and options available. As you continue to explore the GraphQL API consider using [graphqurl](https://github.com/hasura/graphqurl#steps-to-install-cli) (demonstrated below) or a standalone client such as [Altair](https://altair.sirmuel.design/), as using cURL soon gets unweildy! ```json theme={null} { blocks(limit: 1, sortBy: DATETIME_DESC, query:{canonical: true}) { stateHash protocolState { consensusState { blockHeight } } winnerAccount { publicKey } creatorAccount { publicKey } transactions { coinbase } } } ``` ```json theme={null} { "data": { "blocks": [ { "creatorAccount": { "publicKey": "B62qks6ervvF2M6KaZAQA6iTRmudeVNRBpvPKD3865ctnuVLU15RBjT" }, "protocolState": { "consensusState": { "blockHeight": "4699" } }, "stateHash": "3NKvPX8HYb8jvE6BBhFpJ2apXHFu6N1W5T1Zwhhg6jyovHJXX4e6", "transactions": { "coinbase": "400000000000" }, "winnerAccount": { "publicKey": "B62qpCdnMgLC5YzXM3qrqybsqHB35UFHHt9muUDuAm2d1ny1ZqEDJzh" } } ] } }__ Click to edit code ``` ```bash theme={null} gq https:__graphql.minaexplorer.com \\ --singleLine \\ -q 'query { blocks(limit: 1, sortBy: DATETIME_DESC, query:{canonical: true}) { stateHash protocolState { consensusState { blockHeight } } winnerAccount { publicKey } creatorAccount { publicKey } transactions { coinbase } } }' ``` > This service does not aim to replicate all functionality of the Mina GraphQL API and does not return pending data or account information, which you will have to get from a node running the GraphQL API or via a [public proxy](https://minagraph.com/graphql). # Snark Workers Source: https://docs.minaexplorer.com/graphql-api/snark-workers There is a dedicated collection for snark workers to easily extract the data only for purchased SNARKs. This is the same data that is embedded in the `blocks` collection and you may access the top level block data. ## Get the last 10 snark work for a public key ```json theme={null} { snarks( limit: 10 query: {prover: "B62..."} sortBy: DATETIME_DESC ) { fee dateTime block { stateHash protocolState { consensusState{ blockHeight } } } canonical } } ``` ## Determine the most expensive snark work for a period ```json theme={null} { snarks( limit: 10 sortBy: FEE_DESC query: { AND: [ { dateTime_gte: "2021-01-26T00:00:00Z" } { dateTime_lte: "2021-01-27T00:00:00Z" } ] } ) { prover fee } } ``` # Staking Data Source: https://docs.minaexplorer.com/graphql-api/staking-data Returns data from the staking ledgers The staking ledger of the current epoch is the snarked ledger of the last block of current epoch minus two. ## Stake by Delegate Filters the staking ledger for delegates. Summing the balance determines the stake of the delegate in the current epoch. Timing may be used to determine if the account is eligible for the supercharged coinbase rewards. If there is timing available, the following fields are included: * `timed_in_epoch` is a boolean that is `true` if the account has a time-locked balance at the **start** of the epoch. * `untimed_slot` is the global slot at which the account is no longer timed. Useful if the account is untimed during the epoch. * `timed_epoch_end` is a boolean that is `true` if the account has a time-locked balance at the **end** of the epoch. Returns `null` if `timed_in_epoch` is `false` . If the account has no timing information in the ledger `timing` will return `null` . ```json theme={null} { stakes( query: {delegate: "B62...", ledgerHash: "jx94..."} ) { public_key balance timing { cliff_amount cliff_time initial_minimum_balance vesting_increment vesting_period untimed_slot timed_in_epoch timed_epoch_end } } } ``` ```bash theme={null} curl -d '{"query":"{\\n stakes(\\n query: {delegate: \\"B62...\\"}\\n ) {\\n public_key\\n balance\\n timing {\\n cliff_amount\\n cliff_time\\n initial_minimum_balance\\n vesting_increment\\n vesting_period\\n untimed_slot\\n timed_in_epoch\\n timed_epoch_end\\n }\\n }\\n}\\n"}' -H 'Content-Type: application_json' https:__graphql.minaexplorer.com ``` ```json theme={null} { "data": { "stakes": [ { "balance": 65949.4, "public_key": "B62qrAoKfgQx8oXMVQauRs9WYzXpCmYqQrLxivgc8qMYVkK9eH9GjjF", "timing": null }, { "balance": 71771.5149999, "public_key": "B62qrKMAUagWp1VJhvb1AA6y1G4P4tr3inYyPqDRq1VyprA1wmVthcV", "timing": null }, { "balance": 65958.8001, "public_key": "B62qoDaiV18ZGhLfb3j2SuDQEhjyM7c8sDppmvpAyE3cXjutPtHLBfA", "timing": { "cliff_amount": 12000, "cliff_time": 150, "initial_minimum_balance": 60000, "timed_epoch_end": null, "timed_in_epoch": false, "untimed_slot": 2070, "vesting_increment": 150, "vesting_period": 6 } } ] } } ``` ## Filter By Staking Ledger Filter by staking ledger hash to return a specific staking ledger. Includes all historical staking ledgers. ```json theme={null} { stakes(limit: 10, query: {ledgerHash: "jx94FuTZwDmQrqczmWD3iBZcAmBqADdDj196dRXN9WqEBkMYTaY"}) { balance delegate public_key } } ``` ## Top 10 Accounts in Staking Ledger Find the biggest whales in the staking ledger. ```json theme={null} { stakes( query: {ledgerHash: "jx94FuTZwDmQrqczmWD3iBZcAmBqADdDj196dRXN9WqEBkMYTaY"} sortBy: BALANCE_DESC, limit: 10 ) { public_key balance } } ``` ```bash theme={null} curl -d '{"query":"{\\n stakes(\\n sortBy: BALANCE_DESC, limit: 10\\n ) {\\n public_key\\n balance\\n }\\n}"}' https:__graphql.minaexplorer.com ``` ```json theme={null} { "data": { "stakes": [ { "balance": 2251664.0021, "public_key": "B62qmtS1GNjgqBs4n5FKsGMFYYuspGmLtrJmxGtNPtc6gpHMWV45SgT" }, { "balance": 2251562.3917, "public_key": "B62qka2yxv6QHgUuyzxn47HMpReYuWrrGi2NqWZHVGLaoZZxPgc5rGU" }, { "balance": 2251548.5881, "public_key": "B62qmfrWwaUR38Lbc5uW4kF5fQFX532FLk5D8xHjgfZGxYNLoR6Geib" }, { "balance": 2250697.09833855, "public_key": "B62qoWjj77gk6UD55nAPMr8NeTwVgXGiannrZ34cmfjamuJjG3YNH5K" }, { "balance": 2250296.932210155, "public_key": "B62qj7JjRrNfTBAUo9seVTxGBZsr4Zd3iCcoEQEeL9TN2JamefBZRVH" }, { "balance": 2250113.176, "public_key": "B62qknuGAmW8ZB82yZ5xU245fBGCPJxavL8EtxDHgkqnoS1KEo3mpEC" }, { "balance": 2250034.57824422, "public_key": "B62qpCdnMgLC5YzXM3qrqybsqHB35UFHHt9muUDuAm2d1ny1ZqEDJzh" }, { "balance": 2250020.72624221, "public_key": "B62qiptquSVjVM3rNYarUta8g1qgxfKus931RAnheNKX6LxssJbRiYf" }, { "balance": 2250020.2019, "public_key": "B62qpB1oBckU1wXkRFxcwwCheq3chiKtVhY6T3q8aQiwJUaoCjpqgXS" }, { "balance": 2250018.8531, "public_key": "B62qn6xwANH3jgqqxyqmDEHK5a3jbVd54p2oBdahRuMLmL7qfAxXWGF" } ] } } ``` ## Determine the Last Block of Epoch The next staking ledger is only available after `k` blocks from the last block of the prior epoch. Adding `k` to the following result will determine when the next epoch ledger is available. ```json theme={null} { blocks( query: {protocolState: {consensusState: {epoch: 1}}} sortBy: DATETIME_DESC limit: 1 ) { protocolState { consensusState { blockHeight } } } } ``` ```bash theme={null} curl -d '{"query":"{\\n blocks(\\n query: {protocolState: {consensusState: {epoch: \\"1\\"}}}\\n sortBy: DATETIME_DESC\\n limit: 1\\n ) {\\n protocolState {\\n consensusState {\\n blockHeight\\n }\\n }\\n }\\n}"}' https:__graphql.minaexplorer.com ``` ```json theme={null} { "data": { "blocks": [ { "protocolState": { "consensusState": { "blockHeight": "4329" } } } ] } } ``` ## Filter Delegates to only those with Timed Account Only show those delegates that have a timed account at the start of the current epoch. ```json theme={null} { stakes( query: { delegate: "B62..." timing: { timed_in_epoch: true } } ) { public_key balance timing { cliff_amount cliff_time initial_minimum_balance vesting_increment vesting_period untimed_slot timed_in_epoch timed_epoch_end } } } ``` ## Balances and total count of delegators You can retrieve the total amount delegated and total number of delegators to a staking pool. ```json theme={null} { stake(query: {public_key: "B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN"}) { delegationTotals { countDelegates totalDelegated } } } ``` # Transactions Source: https://docs.minaexplorer.com/graphql-api/transactions A query dedicated to returning user commands, otherwise known as transactions (excludes coinbase and fee transfers). This data is the same as that obtained via the `block` query but separated out into its own query for ease of use. ## Get the last 25 transactions for a public key Get all transactions to, or from, a public key. Only includes those on the canonical chain. ```json theme={null} { transactions(limit: 25, sortBy: DATETIME_DESC, query: { canonical: true, OR: [{ to: "B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN" }, { from: "B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN" }] }) { fee from to nonce amount memo hash kind dateTime block { blockHeight stateHash } failureReason } } ``` ## Return associated block data for a transaction The `block` relationship may be used to extract information about the block the transaction was contained in. ```json theme={null} { transactions( limit: 1 sortBy: DATETIME_DESC query: {from: "B62qqHM1bihHNvju89PFYugLw73PYRb7pGwp82CpEmWfSYVJiQAppaC"} ) { from to nonce amount hash block { protocolState { consensusState { blockHeight } } } failureReason } } ``` ## Get all transactions sent from a public key after a date ```json theme={null} { transactions( limit: 10 sortBy: NONCE_DESC query: { from: "B62qqHM1bihHNvju89PFYugLw73PYRb7pGwp82CpEmWfSYVJiQAppaC" dateTime_gte: "2021-01-26T00:00:00Z" } ) { from to nonce dateTime amount hash failureReason } } ``` ## Find the largest fees sent in a period This query demonstrates additional sorting options by sorting the transactions by largest fee. ```json theme={null} { transactions( limit: 10 sortBy: FEE_DESC query: { AND: [{dateTime_gte: "2021-01-26T00:00:00Z"}, {dateTime_lte: "2021-01-27T00:00:00Z"}] } ) { from to fee nonce dateTime amount hash failureReason } } ``` ## Determine the largest transfers made in a period This query finds the largest transfers made over a period. ```json theme={null} { transactions( limit: 10 sortBy: AMOUNT_DESC query: { AND: [{dateTime_gte: "2021-01-26T00:00:00Z"}, {dateTime_lte: "2021-01-27T00:00:00Z"}] } ) { from to fee nonce dateTime amount hash failureReason } } ``` ## Find where the memo field is not empty Memos are returned in base58 check encoding. The default memo is `E4YM2vTHhWEg66xpj52JErHUBU4pZ1yageL4TVDDpTTSsv8mK6YaH` so this query simply returns all results who memo is no that value so they can be decoded. ```json theme={null} { transactions( limit: 10 sortBy: AMOUNT_DESC query: { AND: [ { dateTime_gte: "2021-01-26T00:00:00Z" } { dateTime_lte: "2021-01-27T00:00:00Z" } { memo_ne: "E4YM2vTHhWEg66xpj52JErHUBU4pZ1yageL4TVDDpTTSsv8mK6YaH" } ] } ) { from to fee nonce dateTime amount hash memo failureReason } } ``` > Using the dateTime query filters you can greatly improve the performance of your queries by more specifically targeting your date range of returned results. # Troubleshooting Source: https://docs.minaexplorer.com/graphql-api/troubleshooting ## Common Errors If you see an error about a "Sort operation using more than x bytes of RAM" you likely did not specify a query and as a result it is unable to perform the search on such a large amount of data. `(OperationFailed) Executor error during find command :: caused by :: Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.` To resolve, use a query such as adding `canonical: true` to limit the results returned, and to use the pre-defined indexes. # BigQuery Public Dataset Source: https://docs.minaexplorer.com/guides/bigquery-public-dataset > Due to the schema changes involved, the BigQuery dataset will no longer be supported post hard-fork. [Mina](https://minaprotocol.com/) is a succinct blockchain, which means while we can verify the chain's current state using a zero-knowledge proof, the prior history is not retained. So, if we want to analyze the chain's history (for example, to see individual transactions), we need to obtain it from an [archive node](https://docs.minaprotocol.com/en/advanced/archive-node). The official implementation of an [archive node](https://docs.minaprotocol.com/en/advanced/archive-node) stores its data to a [Postgres](https://www.postgresql.org/) database, which typically requires the use of [recursive queries](https://www.postgresqltutorial.com/postgresql-recursive-query/) to determine the canonical chain information. > See [this post](https://garethtdavies.medium.com/running-a-mina-archive-node-f6299219aab1) on how to set up and configure an archive node for redundancy. Those who want to query historical data without running their own archive nodes (and associated Mina node(s)) can use historical services like [Figment's DataHub](https://figment.io/datahub/mina/) or MinaExplorer's archive [GraphQL API](https://docs.minaexplorer.com/v1.0/minaexplorer/graphql-getting-started). However, neither offer simple aggregation features to answer questions such as "how many blocks were produced in the last 24 hours". While obtaining this information via scripting is possible, directly querying a database with a SQL query is more accessible and efficient. MinaExplorer has published its custom archive node dataset to [Google BigQuery](https://cloud.google.com/bigquery) as a public dataset to resolve this issue. Google BigQuery is a cloud-based big data analytics web service for processing very large data sets. Data is replicated from MinaExplorer's database (which stores GraphQL subscriptions) with a small latency of no more than a few minutes. > The schema of the BigQuery dataset matches that of the MinaExplorer [GraphQL API](https://graphql.minaexplorer.com/). Notably, snarks and user transactions (aka user commands), which are also nested in blocks data, are separated into their own tables for easier querying. ### Making your first query While you can use any GUI that supports BigQuery, such as [PopSQL](https://popsql.com/), [Tableau](https://www.tableau.com/), or [DataGrip](https://www.jetbrains.com/datagrip/), we will use the BigQuery console to execute our queries for this article. Access the console via [https://console.cloud.google.com/bigquery](https://console.cloud.google.com/bigquery), create a new project if required, and add the data source by selecting *Add Data* -> *Pin a project* -> *Enter project name* and enter *minaexplorer.* ![Pin the project for easy access and to view the schema](https://image-archive.developerhub.io/image/upload/v2_455/qco0n27qpvm1pb08xnyq/1636051698.png) While it is not necessary to pin the project, this will allow you to browse the table’s schemas easily. ![Browse the schema of the blocks table](https://image-archive.developerhub.io/image/upload/v2_455/mlztgownmgyjrhfyiiad/1636051735.png) To create our first query, click *Compose New Query* in the top right of the console, and enter the following to determine the number of blocks in the database, and click *Run*. ```sql theme={null} SELECT canonical, COUNT(statehash) AS total FROM minaexplorer.archive.blocks GROUP BY canonical ``` If all goes well, you should see output similar to the below (your result will differ). ![Number of blocks in the database, grouped by canonical status](https://image-archive.developerhub.io/image/upload/v2_455/mdneps2yw8hmjy4fpdvf/1636051870.png) This query highlights that the database stores all blocks seen. If you are only interested in the canonical chain, filter all of your queries `WHERE canonical = true` to only return canonical blocks/snarks/transactions. > While MinaExplorer pays to host the dataset, any queries you run against the dataset are charged against your own personal billing account. There is a generous free tier of 1TB of data processing to get started. > The remainder of the article will provide some sample queries to demonstrate the use of the dataset. ### Querying Block Data Each block has a corresponding `datetime` field (UTC), which we can use to, for example, group canonical blocks by day. ```sql theme={null} SELECT datetime_trunc(datetime, DAY) as day, COUNT(statehash) as total_blocks FROM minaexplorer.archive.blocks WHERE canonical = true GROUP BY day ORDER BY total_blocks DESC ``` This query returns the following result, which we could additionally visualize in [Data Studio](https://datastudio.google.com/u/0/) by clicking on the *Explore Data* link. ![Number of canonical blocks produced per day](https://image-archive.developerhub.io/image/upload/v2_455/bxkelmfqc7wlsnkd7uyw/1636051973.png) ### Querying Transaction Data For transactions, as well as filtering for the canonical status of the transaction, you should also check that the transaction did not fail. You can do this by adding a `WHERE failurereason IS NULL` filter as this field is only populated if the transaction fails. Let's find how many transactions have failed and how many of each type: ```sql theme={null} SELECT failurereason, COUNT(id) as total FROM minaexplorer.archive.transactions WHERE canonical = true GROUP BY failurereason ``` ![Transactions can fail and should filter for failurereason IS NULL](https://image-archive.developerhub.io/image/upload/v2_455/kguykmjh46kb3j93w669/1636052049.png) There are currently two failure reasons in the database `Amount_insufficient_to_create_account` where the receiving account is not in the ledger, and the amount sent does not cover the account creation fee, and `Receiver_not_present` which occurs when delegating to an account, not in the ledger. You can also query user transactions via the blocks table, which is stored as nested JSON under *blocks*->*transactions*->*usercommands.* However, using the transactions table for transaction querying is likely simpler, joining on the block statehash if you require additional block data. Let's find the largest transactions (in MINA) that occurred over the last 7 days. ```sql theme={null} SELECT amount _ 1000000000 as sent_amount, `from`, `to`, dateTime, blockheight FROM minaexplorer.archive.transactions WHERE canonical = true AND failurereason IS NULL AND datetime >= TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -7 DAY) ORDER BY amount DESC ``` ![Largest transactions over the last 7 days in MINA](https://image-archive.developerhub.io/image/upload/v2_455/l52rpeqg459xqoh2gkk4/1636052106.png) The following [gist](https://gist.github.com/garethtdavies/dc59372f8100de1a5012a581a3fbedda) retrieves the last 100 transactions for a public key, both sent and received, with the associated transaction information. ### Querying SNARK Data One major advantage of the MinaExplorer data over the Postgres archive node is the ability to extract individual SNARK information (these are combined to a single fee transfer in the archive node). As with the transaction data, SNARK data is also available, stored as nested JSON, in the blocks table. Let's get summary data for all SNARKs included in the canonical chain: ```sql theme={null} SELECT COUNT(fee) as total_snarks, MIN(fee) _ 1000000000 as minimum_fee, MAX(fee) _ 1000000000 as maximum_fee, AVG(fee) _ 1000000000 as average_fee FROM minaexplorer.archive.snarks WHERE canonical = true ``` ![Maximum, minimum, and average SNARK fees in the canonical chain](https://image-archive.developerhub.io/image/upload/v2_455/iv4cckuiu1u0ch1sokxj/1636052146.png) *Yes, [this block](https://minaexplorer.com/block/3NLY8oFDnccLHXUsVcCsWTuDGi3Xz2xuEhp4YECh2QzYekWJT56T) really did have a SNARK included for 700 MINA*. You can use this data to help choose appropriate SNARK fees, for example, by filtering for just the last 24 hours by adding `AND datetime >= TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -24 HOUR)` to the `WHERE` clause. Or via the previous 100 blocks (this query includes a subquery to first determine the latest height). ```sql theme={null} SELECT COUNT(fee) as total_snarks, MIN(fee) _ 1000000000 as minimum_fee, MAX(fee) _ 1000000000 as maximum_fee, AVG(fee) _ 1000000000 as average_fee, FROM minaexplorer.archive.snarks as s, ( SELECT blockheight FROM minaexplorer.archive.blocks WHERE canonical = true ORDER BY blockheight DESC LIMIT 1 ) as b WHERE canonical = true AND s.blockheight >= (b.blockheight - 100) ``` > ## Querying Account Data The following query to determine the number of accounts in the ledger demonstrates how accounts are added to the ledger. Either via: * Included in the Genesis ledger (ledger hash `jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee`). * Received a transaction with an amount high enough to cover the ledger creation fee. * Was included via a fee transfer (snark work or coinbase receiver) with a high enough amount to cover the ledger creation fee. ```sql theme={null} WITH ordered_inclusion as ( SELECT `to`, datetime, ROW_NUMBER() OVER ( PARTITION BY `to` ORDER BY datetime ) as first_created FROM ( SELECT `to`, datetime, FROM minaexplorer.archive.transactions WHERE canonical = true AND failurereason iS NULL UNION ALL SELECT `public_key`, '2021-03-17T00:00:00.000+00:00' FROM minaexplorer.archive.ledgers WHERE ledgerhash = "jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee" UNION ALL SELECT transactions.coinbasereceiveraccount.publickey, datetime FROM minaexplorer.archive.blocks WHERE canonical = true UNION ALL SELECT json_extract_scalar(h, '$.recipient'), datetime FROM minaexplorer.archive.blocks LEFT JOIN unnest(json_extract_array(transactions.feetransfer)) as h WHERE canonical = true AND json_extract_scalar(h, '$.recipient') = "{{public_key}}" ) ) SELECT `to`, datetime FROM ordered_inclusion where first_created = 1 ORDER BY datetime ASC ``` The result of this query determines when the account was first added to the ledger so we can visualize the data grouped by date to produce the following chart (thanks to davidg#1063 for help in generating this query). ![Accounts in ledger](https://image-archive.developerhub.io/image/upload/v2_455/w31uyo4cdsnvqaipwbyx/1636052342.png) We can calculate the balance of any account at any block height with the following query. Replace the variable `${public_key}` with the address of the account that you wish to calculate. ```sql theme={null} SELECT sum(balances.amount) _ 1000000000 as current_balance FROM ( _* Fee transfers received (positive) - this can be snark work or transaction fees *_ SELECT SUM(CAST(json_extract_scalar(h, '$.fee') as NUMERIC)) as amount FROM minaexplorer.archive.blocks LEFT JOIN unnest(json_extract_array(transactions.feetransfer)) as h WHERE canonical = true AND json_extract_scalar(h, '$.recipient') = '${public_key}' UNION ALL _* Fee transfers paid out of the received coinbase (negative) - snark work paid for out of coinbase transaction *_ SELECT SUM(CAST(json_extract_scalar(h, '$.fee') as NUMERIC)) * -1 as amount FROM minaexplorer.archive.blocks LEFT JOIN unnest(json_extract_array(transactions.feetransfer)) as h WHERE canonical = true AND json_extract_scalar(h, '$.recipient') != '${public_key}' AND blocks.transactions.coinbasereceiveraccount.publickey = '${public_key}' AND json_extract_scalar(h, '$.type') = 'Fee_transfer_via_coinbase' UNION ALL _* Transactions received (positive) *_ SELECT sum(amount) as amount FROM minaexplorer.archive.transactions WHERE `to` = '${public_key}' AND canonical = true AND failurereason IS NULL UNION ALL _* Amount paid for an outgoing transaction (negative). Include a check if the tx failed. *_ SELECT sum(amount) * -1 as amount FROM minaexplorer.archive.transactions WHERE `from` = '${public_key}' AND canonical = true AND failurereason IS NULL UNION ALL _* Transaction fees sent (negative). Always apply even if tx failed. *_ SELECT sum(fee) * -1 as amount FROM minaexplorer.archive.transactions WHERE `from` = '${public_key}' AND canonical = true UNION ALL _* Coinbase transactions received (positive) *_ SELECT SUM(transactions.coinbase) FROM minaexplorer.archive.blocks WHERE blocks.transactions.coinbasereceiveraccount.publickey = '${public_key}' AND canonical = true UNION ALL _* Any balance in the Genesis ledger or -1 for ledger creation fee. Genesis ledger is in MINA instead of nanomina *_ ( WITH genesis_balance AS ( select balance * 1000000000 from minaexplorer.archive.ledgers WHERE public_key = '${public_key}' AND ledgerhash = 'jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee' ) SELECT * FROM genesis_balance UNION ALL SELECT -1000000000 FROM ( SELECT 1 ) LEFT JOIN genesis_balance ON FALSE WHERE NOT EXISTS ( SELECT 1 FROM genesis_balance ) ) ) balances ``` Balances are comprised of: * Any balance in the Genesis ledger (or a 1 MINA ledger creation fee). * The amount of any outgoing transactions that succeded. * Any fees paid for any outgoing transactions. * The amount of any incoming transactions received. * Any coinbase rewards received. * Any fee transfers received (via block production or snark work). If the account is not in the ledger, the following query will return *-1*. Finally, we can determine the vesting slot of any timed account with the following query (replace the variable`{public_key}`). Calculate the unvested slot for any timed public key: ```sql theme={null} SELECT timing.initial_minimum_balance, timing.cliff_time, timing.cliff_amount, timing.vesting_period, timing.vesting_increment, CASE timing.vesting_increment WHEN 0 THEN timing.cliff_time ELSE CAST( timing.cliff_time + ( ( timing.initial_minimum_balance - timing.cliff_amount ) _ timing.vesting_increment ) * timing.vesting_period AS INT ) END AS fully_vested_slot FROM minaexplorer.archive.ledgers WHERE ledgerhash = "jx7buQVWFLsXTtzRgSxbYcT8EYLS8KCZbLrfDcJxMtyy4thw2Ee" AND public_key = "${public_key}" ``` ### Foundation Delegation Analysis The [Foundation delegation program](https://docs.minaprotocol.com/en/advanced/foundation-delegation-program) requires [calculating](https://docs.minaprotocol.com/en/advanced/foundation-delegation-program#reward-specifications) the amount to return to the Foundation each epoch from the balance of the pool and the number of blocks produced. While scheduled emails now provide this information, we can independently verify the values in the email using a public key and epoch data using the following [query](https://gist.github.com/garethtdavies/3a4893be632bdeb7fa2fc5213452c0e5). We can also confirm the amount sent between the epoch deadlines (change the variables `${public_key}` and `${epoch}` to match the address and epoch, you wish to check against the emails received. ```sql theme={null} SELECT SUM( CAST(json_extract_scalar(h, '$.amount') as NUMERIC) ) _ 1000000000 as amount FROM minaexplorer.archive.blocks LEFT JOIN unnest(json_extract_array(transactions.usercommands)) as h WHERE canonical = true AND json_extract_scalar(h, '$.to') = "${public_key}" AND protocolstate.consensusstate.slotsincegenesis >= (${epoch} * 7140) + 3501 AND protocolstate.consensusstate.slotsincegenesis <= ((${epoch} + 1) * 7140) + 3500 ``` # Guide to Snark Work Source: https://docs.minaexplorer.com/guides/guide-to-snark-work While block producers create **blockchain proofs** that prove the validity of the current state of the blockchain, they do not certify the included individual transactions. Snark workers handle the task of creating these **transaction proofs**. Offloading these transaction proofs from the block producer to snark workers means that the transaction proof generation may be parallelized, significantly improving the network’s throughput. Snark workers charge a fee for generating these transaction proofs and are compensated by the block producers purchasing their completed snark work. A snark worker may charge any fee for the work they produce, but a block producer will (all things being equal) purchase the work required for the lowest fee. > You can view a breakdown of each transaction snark work included on MinaExplorer under the SNARK Jobs heading on a [block page](https://minaexplorer.com/block/3NLBWTQ6BQzGcuoQyzzufVL3jyaNyBYnSBbKLJaP9Ln7AdZGu4SA). When a block producer generates a block, they may include transactions recently seen on the network and included in the transaction pool. The block producer includes these transactions in the staged ledger via a data structure known as the [scan state](https://docs.minaprotocol.com/en/architecture/scan-state) that becomes pending work for the snark workers to complete. For each transaction they add to the scan state, the block producer must add an equivalent amount of completed snark work from the snark pool. The snark pool contains completed transaction proofs submitted by snark workers for transactions added via *prior* block producers. ## Running a Snark Worker Anyone may run a snark worker with any public key, and there is no minimum amount of MINA required. However, the address used for payouts must be in the ledger, else a ledger creation fee (of 1 MINA) will be applied on the first transaction, and snark fees of less than 1 MINA will fail. When the payout address is in the ledger, you may snark with any fee. Running a snark worker requires [running a full node](https://docs.minaprotocol.com/en/using-mina/connecting) to get the latest work and submit completed proofs to the network. See the notes on [snark coordinators](https://docs.minaexplorer.com/minaexplorer/guide-to-snark-work#snark-coordinator) to run multiple snark workers via a single daemon). To start a snark worker via the command line, run the following commands, replacing with your fee (default 0.025 MINA) and the public key of the snark worker: ```bash theme={null} mina client set-snark-work-fee mina client set-snark-worker --address ``` Alternatively, start the daemon with the addition of these two extra flags (add to your existing options): ```bash theme={null} mina daemon \\ -run-snark-worker \\ -snark-worker-fee ``` Snark work is computationally expensive, and you can control the number of threads used with the `-snark-worker-parallelism` option. To stop a snark worker, just pass an empty address as the public key in the command `mina client set-snark-worker --address` ### Snark stopper If running a snark worker on a machine that also produces blocks, the snark worker may use too many resources which prevents completing the blockchain proof in time. As a result, you may not produce your block in time and forgo the coinbase rewards. To alleviate this, you can stop the snark worker when you are about to produce a block. This can be done manually as above or make use of a script such as the [snark stopper script](https://github.com/c29r3/mina-snark-stopper) that will stop the snark worker for the duration of block production and start it up again after. ### Work selection As detailed earlier, when block producers add transactions to blocks, they must include a matching amount of snark work. These snarks are for earlier transactions added to the transaction proof queue, aka the [scan state](https://docs.minaprotocol.com/en/architecture/scan-state). The scan state requires work to be purchased in a specific order according to its position in the tree. So when a block producer adds a transaction, they must purchase the required piece of snark work, and they will select that work from their local snark pool. The snark pool only contains the lowest fee seen for that work. If the node sees cheaper work, it replaces the existing work in the snark pool. When a new block is produced and gossiped, the added transactions become pending work for the snark workers to complete. Snark workers may choose how to select the work they complete, and there are two work selection algorithms in the daemon (though there is nothing to prevent you from creating your own). The two algorithms are **sequential** and **random**. The sequential algorithm produces snark proofs in the order required by block producers. The random option, as the name suggests, selects required work randomly. Snark workers will only complete work if they can complete the work cheaper than they have in their existing snark pool. You can set the work selection algorithm with the option `--work-selection rand` or `--work-selection seq` for sequential. Random is the default. You must restart the daemon for this to be applied. If you run the random algorithm, it may take a while for any work you produce to be purchased as you might be completing work that is not required for some time. Generally speaking, by running the sequential algorithm, you should see faster results. ### Snark coordinator For more advanced use-cases a snark coordinator coordinates snark jobs among many snark workers. The coordinator is responsible for sending new work to the snark workers, ensuring they do not duplicate the same work. The snark workers communicate with the snark coordinator via RPC calls. New work is requested by a snark worker using the `get_work` RPC call. Completed work is submitted via the `submit_work` daemon RPC call. Once received, the coordinator broadcasts the completed work to the network. A snark coordinator is run by providing the `-run-snark-coordinator ` option to the `mina daemon` command. All workers using the same coordinator will use the same public key. A standalone snark worker may be started using the `mina internal snark-worker` command by providing the `-daemon-address`, which is the client port of the daemon running the coordinator (default 8301). > While the coordinator can be used to control multiple snark workers, as would be the case of a snark worker pool, as it communicates via the client port, it is only suitable for coordinating trusted machines. There are plans to enable snark pools, making snark work more efficient as it will help reduce duplicated work. ## Choosing a Fee Pricing snark work is part art, part science, and part luck. There is no centralized pool, and each block producer has a local snark pool from which they purchase snarks. So while snark work is gossiped between nodes, a block producer may be offline or have other issues and never see your snark work or see others first. Other than the coinbase transaction, snark fees are paid for by transaction fees. If a node sees the same price snark work, the original will not be replaced, so while the speed of producing snark work isn't that important (it is more a factor of the price) if you are competing at, say 0 using a sequential selection, then speed may matter. The main approaches to setting a fee are to look at historical prices of snarks in the latest blocks and/or to try to predict snark prices from the current snark pool. For finding historical snark prices, you can get the data from prior blocks by using the daemon [GraphQL API](https://docs.minaprotocol.com/en/developers/graphql-api) (on the node is restricted to the last 290 blocks) or via the [MinaExplorer GraphQL API](https://docs.minaexplorer.com/minaexplorer/snark-workers) for all the chain history. There is a simple summary published [here](https://minaexplorer.com/snark-fees) for the last 100 to 1000 blocks: ![Example snark fees for the last 1000 blocks from MinaExplorer](https://image-archive.developerhub.io/image/upload/v2_455/edjxifnc1jwv5sdcsmfa/1621279498.png) Alternatively, you can see a breakdown of the average snark fee per day on MinaExplorer [here](https://minaexplorer.com/snarketplace#snark-average-fee). ![Charting the average snark fees on MinaExplorer](https://image-archive.developerhub.io/image/upload/v2_455/db75vmw1ui1rrqqhseqv/1621279627.png) An alternate approach is to look at the snark pool on the node to see the current fees for each snark work. This is complicated by the fact that the fees may be replaced at any time by cheaper work and higher-priced work that is not required for some time skews the averages. Additionally, the snark pool includes work that has already been completed or referenced in forks for the last 290 blocks, so naively calculating averages from the raw snark pool will not work. It is possible to determine which work is required by the scan state (and the order required) to infer a more accurate estimate. An example implementation for inspiration is provided [here](https://gist.github.com/garethtdavies/408530cb44c1d8129bc8a877da7ffe17). > You can change your fee using the `mina client set-snark-work-fee ` command or use [GraphQL](https://docs.minaprotocol.com/en/developers/graphql-api) to set this value dynamically. You do not need to restart the daemon. ### Explore the snark pool The snark pool contains all the completed work submitted by snark workers. The pool only maintains the lowest fee for each work bundle (group of work ids) as well as the public key and the fee required by the prover. For example, a single entry in the snark pool may contain this: ```json theme={null} { "work_ids":[ 839740827, 702578095 ], "fee":"0.011", "prover":"B62qpEX1JXC7qNrC3bTwEEDU3UQGSE5DUVSenpmmLpLnNmwPDsLj8Jh" } ``` The scan state structure derives the work required to be purchased by the block producer, and work must be purchased in a defined order. If there is no available snark work to purchase for a required work id, then no transactions will be included in a block (including the coinbase transaction). Additionally, a block producer will not purchase unprofitable snark work, i.e., the block producer may forgo a coinbase reward rather than spend more on snark work than they would receive. Typically, transaction fees cover the fees paid for purchased snark work. Once work has been included in a block, it remains in the snark pool for as long as it is referenced in the last `k` blocks of the scan state. After that time, the snark work is removed from the snark pool. You can view a summary of the snark pool output via the following command. Note that this will likely give different results on each node you run it on: ```bash theme={null} mina advanced snark-pool-list | grep -v "Using password" | jq '.[]|.prover + ":" + .fee' -r -c | sort|uniq -c |sort -nr ``` ## FAQ ### How do I know it is working? Blocks displayed on the explorer only include snark work that is purchased, so if you are snarking with a higher fee, they may never be purchased. To ensure that your snark worker is working correctly, you can [check the logs](https://docs.minaprotocol.com/en/developers/logging), and you should see lines such as `Submitted completed SNARK work`. You can also examine your local snark pool and grep for your public key as you should create snark work in your local snark pool before it is replaced by any cheaper work gossiped to the node. ### I changed my price, but the old price is still being bought. If you are running the snark worker with the random work selection, you may complete work that is not required for some time. That work will remain in the snark pool unless cheaper work is seen and eventually bought. This delay can be significant and depends on the number of transactions added to the scan state. So it is the snark work completed for the older price that is being bought. ### My snark work was not included in the canonical chain. Block producers are responsible for including snark work in a block. There can be multiple block producers for a slot, and/or the block producer may not produce at the correct height to make it into the canonical chain. As a result, the included work may be included in a non-canonical block, and there will be no rewards for it. It might be included in another block that makes it into the canonical chain, and non-canonical snarks are expected and does not indicate there is an issue with the snark worker. ### Why do some very high fees get in when I am snarking for 0? To include a coinbase transaction, a block producer needs to purchase a snark. They can only buy the snark required if it is in their snark pool, so as the coinbase reward is at least 720 MINA, it makes sense to pay anything up to that as it is still profitable. While it is highly unlikely someone will not produce a snark for less than that amount in certain circumstances, if the block producer has been offline for a long period, they may not have seen the cheaper work, and the expensive snark sneaks in. See [this block for an example](https://minaexplorer.com/block/3NLY8oFDnccLHXUsVcCsWTuDGi3Xz2xuEhp4YECh2QzYekWJT56T) that includes a snark sold for 700 MINA, but ultimately this is just down to luck. ### Why are so many snarks sold for 0? At the time of writing, the majority of snarks are being sold for 0. This is largely a reflection of the low number of transactions and the low transaction fees. There are many users wanting to run snark workers and a lot of competition. While it is uneconomical for those running nodes, many users are already running nodes, so there are little additional costs for them to additionally run a snark worker. This will likely change as transaction throughput increases and the demand for snark work becomes greater. ### What are the recommended hardware requirements? Running a snark worker is computationally expensive. The recommended requirements are at least 8 CPUs and 16GB of RAM. ### Why do some blocks have transactions and no snark work? While block producers have to add snark work for any transactions they add, in certain cases, if the block producer can, they will include additional snark work. In [this example](https://minaexplorer.com/block/3NLBWTQ6BQzGcuoQyzzufVL3jyaNyBYnSBbKLJaP9Ln7AdZGu4SA), 124 snarks were included at no cost, and as a result, the next block producers can use these "pre-purchased" snarks to add transactions for free. # Running an Archive Node Source: https://docs.minaexplorer.com/guides/running-an-archive-node [Mina](https://minaprotocol.com/) is a succinct blockchain, and as a result, consensus nodes only store the recent history of the chain before discarding it (the last `k` blocks, currently 290). While prior transaction history is not required to prove the current state is valid (this is handled via a recursive zero-knowledge proof), many applications would like access to this prior transaction history. Examples include [block explorers](https://minaexplorer.com) and [wallets](https://clor.io/). To solve this problem, users may optionally run an archive node that stores a summary of each block seen in a [Postgres](https://www.postgresql.org/) database. The archive node is just a regular mina daemon that connects to a running archive process. > After seeing 28,500 blocks on mainnet the size as reported by `pg_size_pretty( pg_database_size('archiver') );` is **74 MB**. ## Setting up Running an archive node is comprised of running the following components: * A mina daemon. * The archive node package. * A Postgres node, with a database created with the [archive node schema](https://raw.githubusercontent.com/MinaProtocol/mina/master/src/app/archive/create_schema.sql). Links to the relevant downloads and installation instructions are available in the [official documentation](https://docs.minaprotocol.com/en/advanced/archive-node#setup). ![The simplest configuration of an archive node](https://image-archive.developerhub.io/image/upload/v2_455/b1ulfxdmalow0remkgyj/1623266573.png) ### Adding redundancy While the above configuration of a single daemon writing to a single archive node process is the most straightforward, it offers little [redundancy](https://docs.minaprotocol.com/en/advanced/archive-redundancy) if either the daemon or archive process crashes. In those cases, blocks will likely be lost and need to be recovered from other sources (or re-syncing the node if within the last `k` blocks). For redundancy, multiple daemons can write to a single archive node process by each specifying the address of an archive process. ![Multiple daemons writing to a single archive process](https://image-archive.developerhub.io/image/upload/v2_455/njd2lc3wdswody2wxe95/1623266629.png) Further, we can have multiple daemons, pointing to separate archive nodes, both writing to a single Postgres database. Note that in this instance, to ensure consistency of the data, the database should be modified after creating the database and before connecting an archive process to it. ```sql theme={null} ALTER DATABASE SET DEFAULT_TRANSACTION_ISOLATION TO SERIALIZABLE ; ``` ![Multiple daemons writing to multiple archive processes](https://image-archive.developerhub.io/image/upload/v2_455/sznpnr7gcfwccwyqrhzz/1623266714.png) If running Postgres via a cloud service such as with [AWS](https://aws.amazon.com/rds/) or [GCP](https://cloud.google.com/sql), you can further add redundancy with replication and failover by following these [best practices](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/). ### Alternate storage for block data In addition to writing the block data to the Postgres database, we can also archive a [representation of the block data](https://docs.minaprotocol.com/en/advanced/archive-redundancy#backing-up-block-data), known as a *precomputed block* to either [the logs](https://docs.minaprotocol.com/en/advanced/archive-redundancy#save-block-data-from-logs), or [upload them to Google Cloud Storage](https://docs.minaprotocol.com/en/advanced/archive-redundancy#upload-block-data-to-google-cloud-storage). As a result, a final, fully-redundant setup may look like this: ![Fully redundant archive node setup](https://image-archive.developerhub.io/image/upload/v2_455/tqiah6itpxoxk1hrzazd/1623266802.png) > The precomputed blocks can be huge (as much as 5 MB per block) and much larger than is stored by the archive node. If using `log-precomputed-blocks` ensure that your logging service can handle such long log lines. ## Monitoring Even with the above setup, likely, you will want to monitor the status of your archive node, and in the case of data loss, be able to restore blocks to the database. The archive node has some available tooling, detailed below, that will identify individual missing blocks, but for a quick overview of the status of the database, the following two queries can be used in conjunction. ```sql theme={null} SELECT count( * ) FROM (SELECT h::int FROM generate_series(1 , (select max(height) from blocks)) h LEFT JOIN blocks b ON h = b.height where b.height is null) as v ``` This query determines if there is a block for every height (up to the maximum height seen). This query should return `0` where there are no missing blocks at any height. This query does not, however, confirm that there is a canonical block at each height. As such, this query should be used in conjunction with: ```sql theme={null} select count(*) from blocks where parent_id is null ``` This query checks for any missing parents of a block. For a complete archive database, this query should return `1` for the Genesis block, which does not have a parent. If the two queries return `0` and `1` respectively, you are likely in good shape. If they don’t, you’ll likely need to recover some missing blocks using the archive node tooling. ## Archive Tooling To allow for data restoration, exporting, and verification, the archive node has the following tooling available: * **mina-missing-blocks-auditor** — reports state hashes of blocks missing from archive database. * **mina-extract-blocks** — extracts all blocks or a chain (from a provided start and end hash) from the database. * **mina-archive-blocks** — writes blocks to the archive database. * **mina-replayer** — replays transactions from the archive node. ### mina-missing-blocks-auditor This tool will identify any parent state hashes missing from the archive database. This tool will only identify the missing parent state hashes for blocks it has stored, i.e., if you are missing a sequential sequence of blocks, it will only return the first. The output from this tool should only return the Genesis block on a complete database, as it has no parent hash. The following output is returned on a database with missing blocks, which allows us to identify the missing blocks, which correspond to the `parent_hash`. ```bash theme={null} mina-missing-blocks-auditor --archive-uri {"timestamp":"2021-04-22 16:36:21.127744Z","level":"Info","source":{"module":"Dune__exe__Missing_blocks_auditor","location":"File \\"src_app_missing_blocks_auditor_missing_blocks_auditor.ml\\", line 30, characters 10-21"},"message":"Block has no parent in archive db","metadata":{"block_id":1145,"parent_hash":"3NLD34ddu4i8aPF6c7cD4aDh27MFWYTwamAoVRXWBFtcTeAbcJjA","pid":32,"state_hash":"3NK3zgLmMdptx9ubM1H4LTBadSQoQJ3ouYQbR6PQQnbq5vfTpGEo"}} {"timestamp":"2021-04-22 16:36:21.127756Z","level":"Info","source":{"module":"Dune__exe__Missing_blocks_auditor","location":"File \\"src_app_missing_blocks_auditor_missing_blocks_auditor.ml\\", line 30, characters 10-21"},"message":"Block has no parent in archive db","metadata":{"block_id":3386,"parent_hash":"3NLk4z4hvUgiWPMyeF7iaKp78XyqHjGUqm2vabJB6v28VLuMyLQ2","pid":32,"state_hash":"3NKrHrebU3mQUiGwynuKxWW3d3snDCP2wczeDKw7S8t54kK8VkSX"}} ``` ### mina-extract-blocks To extract blocks from an archive node, for example, for use in recovering missing blocks on a different database, you can use the `mina-extract-blocks` tool to output blocks in an *extensional* format. This format, as compared to the *precomputed* blocks, is more lightweight as it only contains the information required to restore data to the archive node. This tool may export either all the blocks in the database with `--all-blocks`. Or a chain between a range of state hashes by optionally providing the `--start-state-hash` or `--end-state-hash`. ```bash theme={null} mina-extract-blocks --archive-uri --all-blocks ``` This tool outputs each extensional block as a file with the name of the file being the state hash, e.g., `3NKGgTk7en3347KH81yDra876GPAUSoSePrfVKPmwR1KHfMpvJC5.json`. ### mina-archive-blocks The `mina-archive-blocks` tool is used to restore blocks to the database. This tool can be used either with *precomputed* blocks, i.e. those stored to logs or via Google Cloud Storage or the *extensional* format as exported by another archive node. For example, to import the extensional block we exported in the previous section, we could run: ```bash theme={null} mina-archive-blocks --extensional 3NKGgTk7en3347KH81yDra876GPAUSoSePrfVKPmwR1KHfMpvJC5.json --archive-uri ``` We can pass multiple files to the tool to import a large number of files via `mina-archive-blocks`. To do this in a batch, we can make use of standard Linux tooling. For example, the following command will attempt to import all `.json` files in the current directory. It will also write to separate output files for successful and failed blocks during the process for later review. ```bash theme={null} find . -name "*.json" | xargs -I % mina-archive-blocks --extensional % --archive-uri --log-successful false --successful-files success.txt --failed-files failed.txt ``` There is a very similar approach for *precomputed blocks* but instead, use the `--precomputed` flag. ### mina-replayer One issue when recovering blocks is that you have to trust the source of the data — for example, downloading a backup you have to trust that the data was not tampered with. The `mina-replayer` tool takes as input a genesis ledger and can be run on the archive data to produce a ledger corresponding to a protocol state and can be used to verify that the archived data is correct and complete by comparing the resulting ledger to a known one. ```bash theme={null} mina-replayer --archive-uri --input-file genesis.json --output-file calculated_ledger.json ``` ## Bootstrapping If you are new to Mina and wish to start an archive node, you will need to get an existing database to bootstrap from (as the node will only restore the last 290 blocks). While you could use the tools listed above to extract and import all blocks, it would be easier to request a database exported using the `pg_dump`[tool](https://www.postgresql.org/docs/9.1/backup-dump.html) (and imported via `psql`) to bootstrap the archive node from an existing archive database operator. If you need assistance then ask on the project [Discord](https://discord.com/invite/sYUKfqDJ4P). If the dump is recent enough, i.e., within the last 290 blocks and you sync a node, it will catchup any missing blocks between the dump and when you started the archive node. # Documentation Home Source: https://docs.minaexplorer.com/introduction We build tools and services for the [Mina Protocol](https://minaprotocol.com/). ### What we do: * The first Mina blockchain explorer at [minaexplorer.com](https://minaexplorer.com/). * A [Staking Pool](https://docs.minaexplorer.com/v1.0/minaexplorer/staking-pool). * Tools and data utilities, such as an archive [GraphQL API](https://docs.minaexplorer.com/v1.0/minaexplorer/graphql-getting-started) service and a [public BigQuery dataset](https://docs.minaexplorer.com/minaexplorer/bigquery-public-dataset) (now deprecated) * A GraphQL public proxy on all supported networks. ![MinaExplorer.com Blockchain Explorer](https://image-archive.developerhub.io/image/upload/v2_455/ximwk7civsvi0ykn2uft/1613017003.png) > MinaExplorer is a community-led initiative and is not affiliated to Mina Foundation. # REST API Reference Source: https://docs.minaexplorer.com/rest-api/introduction A REST API for the latest Mina Blockchain Data ## Overview The MinaExplorer REST API provides access to the latest Mina blockchain data. For all archived data, please use the GraphQL API. `https://api.minaexplorer.com` ## Getting Started The REST API allows you to interact with current Mina blockchain data programmatically. All endpoints return JSON responses. ## Support * **Email**: [support@minaexplorer.com](mailto:support@minaexplorer.com) * **Terms of Service**: See our [Website Terms of Service](/support/website-terms-of-service) ## OpenAPI Specification Browse the complete API reference below to see all available endpoints and their parameters. # Calculating Payouts Source: https://docs.minaexplorer.com/staking-pool/calculating-payouts > The payment mechanism has been updated to reflect the new Foundation delegation rules. A reference implementation of this payout mechanism is [here](https://github.com/garethtdavies/mina-payout-script), but it is encouraged to use [this](https://github.com/jrwashburn/mina-pool-payout) implementation which is more robust and flexible. This page details how we determine payouts to delegators. Payouts are based on the block rewards received by the block-producing account. Only blocks on the canonical chain have block rewards. Due to the consensus mechanism, there may be multiple block producers for a slot and, only one will be selected (all things being equal, determined randomly). So it is expected that we will occasionally not have a payout for some (orphaned) blocks. Rewards are only final once the block has `k` (290) confirmations. ### Determining block rewards Block rewards are determined by: * Coinbase reward * Transaction fees * Snark work fees Block rewards are calculated as: `block reward = coinbase fees + transaction fees - snark work fees` We take a small portion of this total (5%) as the fee for running and maintaining the block producer infrastructure. The remainder of this reward is returned to the delegators, based on the weighting of their contribution to the pool. While all winnings from the pool are shared, it is possible to determine the individual account that won the chance to produce a block in a slot (see `winningAccount` in [GraphQL](https://docs.minaexplorer.com/minaexplorer/blocks)). This becomes important when we consider additional rules for [supercharged rewards](#supercharged-rewards) and [foundation delegations](#foundation-delegations). **Example:** Let's assume the pool wins a block where: * Coinbase: 200 mina * Tx fees: 1.5 mina * Snark fees: 1.2 mina In this case, the block reward will be equal to 200 + 1.5 - 1.2 = 200.3 mina. Pool fees for the block are 5% of the total or 10.015 mina with the remainder (190.285 mina) distributed among delegates according to their effective pool weightings. > We (or anyone) do not know what snark and transaction fees will be at mainnet. It is assumed that they will be low, and the primary reward will be the coinbase transaction. As throughput will be limited, it is possible that transaction fees could be meaningful (though unlikely at the scale of the last testnet). The pool will share all transaction fees with delegators. ### Fee Transfers Snark fees pay for two type of transfers, one for including the coinbase transaction, which is paid out of the coinbase reward `Fee_transfer_via_coinbase` and the remaining snark work pays for any included transactions `Fee_transfer` Therefore, via fee transfers, we can determine the snark fees due to transactions and which for the coinbase reward. This is useful in calculating the supercharged rewards factor for a block. ## Staking Ledger The staking ledger of the epoch determines those delegating and the balances used. It is the balance in the staking ledger that determines the probability of winning a slot to produce a block and **not** the current account balance. Staking ledgers are only updated once per epoch, with the staking ledger of the current epoch being determined by the snarked ledger of the last block of the current epoch - 2. We will publish the staking ledger for each epoch on the site, clearly showing your % [contribution to the pool](https://minaexplorer.com/wallet/B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN/delegations). The staking ledger will detail the balance and also any timing information used in determining the supercharged rewards factor (detailed [below](#supercharged-rewards)). As an example, consider the simple ledger: ```json theme={null} { "data": { "stakes": [ { "balance": 20000, "public_key": "B62qrAoKfgQx8oXMVQauRs9WYzXpCmYqQrLxivgc8qMYVkK9eH9GjjF", "timing": null }, { "balance": 50000, "public_key": "B62qrKMAUagWp1VJhvb1AA6y1G4P4tr3inYyPqDRq1VyprA1wmVthcV", "timing": null }, { "balance": 30000, "public_key": "B62qoDaiV18ZGhLfb3j2SuDQEhjyM7c8sDppmvpAyE3cXjutPtHLBfA", "timing": { "cliff_amount": 5000, "cliff_time": 1500, "initial_minimum_balance": 30000, "timed_epoch_end": true, "timed_in_epoch": true, "untimed_slot": 3000, "vesting_increment": 100, "vesting_period": 6, "timed_weighting": 0.5 } } ] } } ``` *Note, this ledger is generated via the [Staking Data GraphQL query](https://docs.minaexplorer.com/minaexplorer/staking-data) which contains additional pre-calculated timed data to that in the staking ledger dump from the daemon.* Here we have three delegates (A, B and C). The total of the pool is simply the sum of all balances - in this case, 100,000 mina. In this instance, the weighting factors before allowing for the supercharged rewards are as follows: * A: 0.2 (20%) * B: 0.5 (50%) * C: 0.3 (30%) > We can get the total currency from the Mina daemon or via the [GraphQL API](/blocks). From this we can determine the probability of the pool of winning any slot based on the total pool stake and total currency. This uses a factor known as `f` (currently 0.75) that defines the percentage of blocks that are intentionally empty (25%) and `c` (currently 1). Using this we can determine the relative luck of the pool based on the probability of winning a slot being equal to: `c * (1 - (1 - f)^(pool stake / total currency)` ## Supercharged Rewards When an account that **only** contains unlocked tokens (see the docs on time-locked tokens [here](https://minaprotocol.com/docs/architecture/timelock)) wins a block, the coinbase rewards are doubled. Note that this does not affect the probability of winning a slot, which is solely based on stake, but on the amount received for a coinbase transaction. As a result, transaction fees should be shared by all pool delegates but the unlocked account should receive additional weighting proportional to the increased coinbase reward. ### Defining the supercharged weighting > This method has since been updated to make use of fee transfers, which were [added to GraphQL](https://github.com/MinaProtocol/mina/issues/8072) in the mainnet release. The examples below will be updated in due course or refer to the [implementation](https://github.com/garethtdavies/mina-payout-script/blob/main/payout.py#L185).> > `supercharged weighting = 1 + (1 / ((1 + sum fee transfers) / (coinbase - sum fee transfers via coinbase))` The weighting for supercharged rewards should be on a sliding scale from 1x to 2x. Specifically: * If transaction fees are zero it should be 2x. * If transaction fees are infinite (or more practically just *really* high) it should be 1 - as in this instance the coinbase reward is insignificant to the total block rewards to be shared. * If a an account becomes untimed **during** the epoch we use the % of the epoch it is untimed. As such, we can define the `supercharged weighting` for a block to be: `supercharged weighting = 1 + (1 / (1 + transaction fees / coinbase))` *The below calculations assume a default coinbase of 200. We do not know what this will be at mainnet launch.* * When transaction fees are 0 the supercharged weighting = **2** * When transaction fees are low (e.g. 5 mina) the supercharged weighting = **1.9756** * When transaction fees equal the default coinbase reward the supercharged weighting = **1.5** * When transaction fees are very high (e.g. 10,000 mina) the supercharged weighting = **1.0196** At its simplest, if there are no transaction fees the unlocked account gets double the rewards. If the transaction fees are so large that the coinbase is insignificant the factor is close (but not quite) 1. **The standard coinbase amount is always used in determining the supercharged weighting.** > At mainnet launch, the coinbase value will be set as a fixed consensus constant. However, it is expected the coinbase to adjust dynamically to match the inflation schedule, which will be implemented via a hard-fork. Further, if an account becomes untimed **during** the epoch we use the % of the epoch it is untimed where the supercharged factor is accounted for. As an example, if an account becomes untimed at slot 5000 of the epoch of length 7140 the `timed weighting` factor is equal to 7140-5000/7140 = 0.3. For all accounts with any amounts of locked tokens, it will have a `timed weighting` factor of 0. An unlocked account for the entire epoch will have a `timed weighting` factor of 1. `supercharged contribution = ((supercharged weighting - 1) * timed weighting factor) + 1` Finally we can determine the `effective pool weighting` per block as: `effective pool stake = stake * supercharged contribution` `effective pool weighting = effective pool stake / sum(effective pool stakes)` ### Example 1: Low transaction fees Using the staking ledger detailed previously we can determine the effective pool weightings when a block is won with transaction fees of 5 mina and a supercharged coinbase for 400 mina. Total snark fees are 0.8 mina. For each account: * A is untimed for the entire epoch and so has a higher effective pool stake. The `supercharged contribution` is 1.98765 due to the low transaction fees. Therefore their effective pool stake is 39,753 mina. * B is also untimed for the entire epoch and so their effective pool stake is 99,383 mina. * C has locked tokens for the entire epoch and so has a `supercharged contribution` of 1 and no change to their effective pool stake of 30,000. The effective stake of the entire pool is 169,136. The total block reward is 404.2 mina and as a result the block rewards are divided as follows (this ignores the pool fee): * A: 94.98 mina (23.5%) * B: 237.67 mina (58.8%) * C: 71.54 mina (17.7%) While the account containing locked tokens receives proportionally less, this is offset by the higher amounts of the supercharged coinbase. ### Example 2: High transaction fees Using the staking ledger detailed previously we can determine the effective pool weightings when a block is won with transaction fees of 5000 mina and a coinbase for 200 mina. Total snark fees are 15.8 mina. For each account: * The `supercharged contribution` based on A being untimed for the entire epoch is 1.038. Therefore their effective pool stake is 20,760. * B is also untimed and has an effective pool stake of 51,900. * C has locked tokens and so their effective pool stake is 30,000. The effective stake of the entire pool is 102,660. The total block reward is 5184.2 mina and as a result the block rewards are divided as follows (this ignores the pool fee): * A: 1048.35 mina (20.2%) * B: 2620.88 mina (50.6%) * C: 1514.82 mina (29.22%) As expected, with higher transaction fees the supercharged coinbase factor has less of an impact in the distribution of block rewards. ## Foundation Delegations The MinaExplorer pool currently receives a [Mina Foundation delegation](https://minaprotocol.com/blog/mina-foundation-delegation-policy). The rules of the Foundation delegation mean that their rewards for a block are determined by: `(delegation balance / pool balance) * standard coinbase * (1-fee)` The Foundation does not get additional transaction fees and does not share any additional rewards for the supercharged coinbase. In almost all cases, this is beneficial to the pool, and we will share all additional Federation delegation rewards with members of the pool. Specifically: * We calculate the total pool stake * We determine the total rewards of the blocks won (as defined above) * We determine the payout of each of the Foundation / O(1) Labs delegations according to the calculation above * We subtract the Foundation / O(1) Labs delegations from the total rewards * We apply the supercharged algorithm to share the remainder of the pool via effective pool weight (where the Foundation / O(1) Labs addresses are excluded) The addresses of the Foundation delegation addresses for MinaExplorer are: * B62qmsYXFNNE565yv7bEMPsPnpRCsMErf7J2v5jMnuKQ1jgwZS8BzXS * B62qn71s63yywMUCcFhP4iCata7HpgyrvmGjpKa1D9544vGW6FBZ6a1 * B62qqEV4oP7w2jLQGckvZzdWjfdLKySKHJ3tNU5niRjpPD7beYumWTB * B62qmQAFPta1Q3c7wXHxXRKnE3uWyBYZCLb8frdHEgavi3BbBVkpeC1 Foundation delegations are reviewed every 3 months in accordance with their [delegation policy](https://minaprotocol.com/blog/mina-foundation-delegation-policy). # Delegating to the Pool Source: https://docs.minaexplorer.com/staking-pool/delegating-to-the-pool > The public key to delegate to the MinaExplorer staking pool is **B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN** If all of your funds are locked at mainnet, and you wish to delegate to us, you will need some funds to pay for the transaction fee. If you do not have any unlocked funds, please [contact us](https://docs.minaexplorer.com/v1.0/minaexplorer/get-help) and we will send you the fee required to send a delegation transaction. ## Mina Daemon You will need to first import the key to the daemon, then issue the following command with your unlocked key. ```bash theme={null} mina client delegate-stake \\ -receiver B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN \\ -sender \\ -fee 0.01 ``` ## Ledger You can generate the payment offline with the Ledger and then use a service to [broadcast the signed delegation transaction](https://minaexplorer.com/broadcast-ledger). You need to have the latest version of `mina_ledger_wallet`[installed](https://minaprotocol.com/docs/advanced/ledger-app-mina). In the example below change **0** to the BIP44 account of the wallet (e.g. 42) and change `SENDER_PUBLIC_KEY` to the address of the account. See the example for a delegation to the MinaExplorer pool. ```bash theme={null} mina_ledger_wallet delegate --offline --fee 0.01 --nonce 0 --network mainnet 0 SENDER_PUBLIC_KEY B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN ``` ```bash theme={null} mina_ledger_wallet delegate --offline --fee 0.01 --nonce 0 --network mainnet 0 B62qkwrHj3YCKgQsXRktpwhVFij19RiwYDgMmiwp7iggNBi8712a4W4 B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN ``` If all goes well, this will output a transaction similar to the below: ```json theme={null} { "signature": "0371c5dadef6326b475efad026aa3f6c299406519b9652413cde19ff013c7e0a321f23b566e060dcba719f7542457e4e1df0aa3f6c6dba47f11f2ef75a078bc9", "payment": null, "stake_delegation": { "delegator": "B62qnzbXmRNo9q32n4SNu2mpB8e7FYYLH8NmaX6oFCBYjjQ8SbD7uzV", "new_delegate": "B62qnzbXmRNo9q32n4SNu2mpB8e7FYYLH8NmaX6oFCBYjjQ8SbD7uzV", "fee": "10000000", "nonce": "0", "memo": null, "valid_until": "4294967295" }, "create_token": null, "create_token_account": null, "mint_tokens": null } ``` If you see an error, ensure that you have some unlocked tokens to pay for the transaction fee or [request some](https://docs.minaexplorer.com/v1.0/minaexplorer/get-help). If you still have issues please [contact](https://docs.minaexplorer.com/v1.0/minaexplorer/get-help) us to resolve. Take this output and paste it all into the text box on [this page](https://minaexplorer.com/broadcast-ledger). ![Broadcast a Ledger transaction](https://image-archive.developerhub.io/image/upload/v2_455/zgayiht6ulwukaakqhh2/1616003778.png) If all goes well you should see a "Success" message and get the payment ID of the transaction. ![Broadcast a Ledger transaction](https://image-archive.developerhub.io/image/upload/v2_455/mbbxdgag55nfmihi9ctp/1616003897.png) While the delegation should be immediately reflected on the explorer there will be a delay of 1-2 epochs before the delegation is included in the staking ledger. For the period in between your **existing delegation will still be active**. ## Clor.io If you have a [Clorio](https://clor.io/) web wallet or can import your private key e.g. from a Ledger then you can delegate to the pool via the web interface. Once your wallet is open, select *Staking Hub* from the left-hand menu and choose MinaExplorer as the Delegate and confirm. ![Delegate to the pool with Clorio wallet](https://image-archive.developerhub.io/image/upload/v2_455/kvcabuyjbd0lcfgvgelo/1617394658.png) ## Auro If you are using the [Auro browser extension](https://www.aurowallet.com/) simply click on the staking tab, select MinaExplorer as the staking provider and send the delegation transaction. ![Select MinaExplorer as the staking provider](https://image-archive.developerhub.io/image/upload/v2_455/gxhu7alsyw2cy4y2qiee/1619755699.png) ## Staking Power If you are using the [StakingPower](https://github.com/crackerli/coda-mobile-wallet) wallet, choose *Stake* from the menu and *Select a Staking Provider* and choose MinaExplorer. Confirm the transaction on the summary page as shown below. ![Select MinaExplorer as your staking provider](https://image-archive.developerhub.io/image/upload/v2_455/fttbcfmdfhdsceg9p7e9/1623783800.jpg) ![Confirm the delegation transaction](https://image-archive.developerhub.io/image/upload/v2_455/dbtmrcs7lexwx1r2kht5/1623783930.jpg) # Epoch delegator list Source: https://docs.minaexplorer.com/staking-pool/epoch-delegator-list * The list of current epoch stakers to the pool is available [here](https://minaexplorer.com/wallet/B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN/delegations). * The list of stakers for the **next** epoch, when available, is [here](https://minaexplorer.com/wallet/B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN/next-epoch-delegations). > When delegating to the pool, there is a delay of **1-2 epochs** before the staking ledger is updated. Until your delegation is active your existing delegation will still be active. GraphQL This data is also available via the [GraphQL API.](https://docs.minaexplorer.com/v1.0/minaexplorer/staking-data) ```bash theme={null} query { stakes(query: {delegate: "B62qpge4uMq4Vv5Rvc8Gw9qSquUYd6xoW1pz7HQkMSHm6h1o7pvLPAN"}, limit:1000) { balance public_key timing { timed_in_epoch } } } ``` # Expected Returns Source: https://docs.minaexplorer.com/staking-pool/expected-returns > This table displays the expected returns for each epoch. the actual pool payouts (which tend higher) may be found [here](https://docs.minaexplorer.com/minaexplorer/performance-his). As the coinbase rewards are currently fixed, at 720 MINA for a regular block and 1440 MINA for a supercharged block, due to the increase in the total currency per epoch the expected APR per epoch is decreasing. This table displays the expected protocol return per epoch - it assumes 24.54 epochs a year, as an epoch is 14 days and 21 hours. The actual payout rate of the pool may be found [here](https://docs.minaexplorer.com/minaexplorer/performance-history#payout-rate). The rewards will continue to decrease, with the supercharged bonus eventually being deprecated (stated for 15 months after mainnet launch). A hard fork may also adjust the future rate at any time.