,
+ metadata: CertificateListItemMessageMetadata,
+ protocol_message: ProtocolMessage,
+ signed_message: String,
+ aggregate_verification_key: String,
+ ) -> CertificateListItemMessage {
CertificateListItemMessage {
hash,
previous_hash,
@@ -56,4 +71,3 @@ impl CertificateListItemMessage {
}
}
}
-
diff --git a/rust/src/models/certificate_list_item_message_metadata.rs b/rust/src/models/certificate_list_item_message_metadata.rs
index cf96fbee..4c1ff16b 100644
--- a/rust/src/models/certificate_list_item_message_metadata.rs
+++ b/rust/src/models/certificate_list_item_message_metadata.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::protocol_parameters::ProtocolParameters;
+
/// CertificateListItemMessageMetadata : CertificateListItemMessageMetadata represents the metadata associated to a CertificateListItemMessage
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct CertificateListItemMessageMetadata {
@@ -21,7 +23,7 @@ pub struct CertificateListItemMessageMetadata {
#[serde(rename = "version")]
pub version: String,
#[serde(rename = "parameters")]
- pub parameters: models::ProtocolParameters,
+ pub parameters: ProtocolParameters,
/// Date and time at which the certificate was initialized and ready to accept single signatures from signers
#[serde(rename = "initiated_at")]
pub initiated_at: String,
@@ -35,7 +37,14 @@ pub struct CertificateListItemMessageMetadata {
impl CertificateListItemMessageMetadata {
/// CertificateListItemMessageMetadata represents the metadata associated to a CertificateListItemMessage
- pub fn new(network: String, version: String, parameters: models::ProtocolParameters, initiated_at: String, sealed_at: String, total_signers: i64) -> CertificateListItemMessageMetadata {
+ pub fn new(
+ network: String,
+ version: String,
+ parameters: ProtocolParameters,
+ initiated_at: String,
+ sealed_at: String,
+ total_signers: i64,
+ ) -> CertificateListItemMessageMetadata {
CertificateListItemMessageMetadata {
network,
version,
@@ -46,4 +55,3 @@ impl CertificateListItemMessageMetadata {
}
}
}
-
diff --git a/rust/src/models/certificate_message.rs b/rust/src/models/certificate_message.rs
index 9b5db636..9a72083f 100644
--- a/rust/src/models/certificate_message.rs
+++ b/rust/src/models/certificate_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,11 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{
+ cardano_db_beacon::CardanoDbBeacon, certificate_metadata::CertificateMetadata,
+ protocol_message::ProtocolMessage,
+};
+
/// CertificateMessage : Certificate represents a Mithril certificate embedding a Mithril STM multi signature
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct CertificateMessage {
@@ -24,14 +29,14 @@ pub struct CertificateMessage {
#[serde(rename = "epoch")]
pub epoch: i64,
#[serde(rename = "beacon", skip_serializing_if = "Option::is_none")]
- pub beacon: Option,
+ pub beacon: Option,
/// Entity type of the message that is signed
#[serde(rename = "signed_entity_type")]
pub signed_entity_type: std::collections::HashMap,
#[serde(rename = "metadata")]
- pub metadata: Box,
+ pub metadata: Box,
#[serde(rename = "protocol_message")]
- pub protocol_message: Box,
+ pub protocol_message: Box,
/// Hash of the protocol message that is signed by the signer participants
#[serde(rename = "signed_message")]
pub signed_message: String,
@@ -48,7 +53,18 @@ pub struct CertificateMessage {
impl CertificateMessage {
/// Certificate represents a Mithril certificate embedding a Mithril STM multi signature
- pub fn new(hash: String, previous_hash: String, epoch: i64, signed_entity_type: std::collections::HashMap, metadata: models::CertificateMetadata, protocol_message: models::ProtocolMessage, signed_message: String, aggregate_verification_key: String, multi_signature: String, genesis_signature: String) -> CertificateMessage {
+ pub fn new(
+ hash: String,
+ previous_hash: String,
+ epoch: i64,
+ signed_entity_type: std::collections::HashMap,
+ metadata: CertificateMetadata,
+ protocol_message: ProtocolMessage,
+ signed_message: String,
+ aggregate_verification_key: String,
+ multi_signature: String,
+ genesis_signature: String,
+ ) -> CertificateMessage {
CertificateMessage {
hash,
previous_hash,
@@ -64,4 +80,3 @@ impl CertificateMessage {
}
}
}
-
diff --git a/rust/src/models/certificate_metadata.rs b/rust/src/models/certificate_metadata.rs
index 25d696a4..6838d571 100644
--- a/rust/src/models/certificate_metadata.rs
+++ b/rust/src/models/certificate_metadata.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,10 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{
+ protocol_parameters::ProtocolParameters, stake_distribution_party::StakeDistributionParty,
+};
+
/// CertificateMetadata : CertificateMetadata represents the metadata associated to a Certificate
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct CertificateMetadata {
@@ -21,7 +25,7 @@ pub struct CertificateMetadata {
#[serde(rename = "version")]
pub version: String,
#[serde(rename = "parameters")]
- pub parameters: models::ProtocolParameters,
+ pub parameters: ProtocolParameters,
/// Date and time at which the certificate was initialized and ready to accept single signatures from signers
#[serde(rename = "initiated_at")]
pub initiated_at: String,
@@ -30,12 +34,19 @@ pub struct CertificateMetadata {
pub sealed_at: String,
/// The list of the signers identifiers with their stakes and verification keys
#[serde(rename = "signers")]
- pub signers: Vec,
+ pub signers: Vec,
}
impl CertificateMetadata {
/// CertificateMetadata represents the metadata associated to a Certificate
- pub fn new(network: String, version: String, parameters: models::ProtocolParameters, initiated_at: String, sealed_at: String, signers: Vec) -> CertificateMetadata {
+ pub fn new(
+ network: String,
+ version: String,
+ parameters: ProtocolParameters,
+ initiated_at: String,
+ sealed_at: String,
+ signers: Vec,
+ ) -> CertificateMetadata {
CertificateMetadata {
network,
version,
@@ -46,4 +57,3 @@ impl CertificateMetadata {
}
}
}
-
diff --git a/rust/src/models/certificate_pending_message.rs b/rust/src/models/certificate_pending_message.rs
index c7985081..bb1a6a50 100644
--- a/rust/src/models/certificate_pending_message.rs
+++ b/rust/src/models/certificate_pending_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,10 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{
+ cardano_db_beacon::CardanoDbBeacon, protocol_parameters::ProtocolParameters, signer::Signer,
+};
+
/// CertificatePendingMessage : CertificatePendingMessage represents all the information related to the certificate currently expecting to receive quorum of single signatures
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct CertificatePendingMessage {
@@ -18,23 +22,30 @@ pub struct CertificatePendingMessage {
#[serde(rename = "epoch")]
pub epoch: i64,
#[serde(rename = "beacon", skip_serializing_if = "Option::is_none")]
- pub beacon: Option,
+ pub beacon: Option,
/// Entity type of the message that is signed
#[serde(rename = "entity_type")]
pub entity_type: std::collections::HashMap,
#[serde(rename = "protocol")]
- pub protocol: models::ProtocolParameters,
+ pub protocol: ProtocolParameters,
#[serde(rename = "next_protocol")]
- pub next_protocol: models::ProtocolParameters,
+ pub next_protocol: ProtocolParameters,
#[serde(rename = "signers")]
- pub signers: Vec,
+ pub signers: Vec,
#[serde(rename = "next_signers")]
- pub next_signers: Vec,
+ pub next_signers: Vec,
}
impl CertificatePendingMessage {
/// CertificatePendingMessage represents all the information related to the certificate currently expecting to receive quorum of single signatures
- pub fn new(epoch: i64, entity_type: std::collections::HashMap, protocol: models::ProtocolParameters, next_protocol: models::ProtocolParameters, signers: Vec, next_signers: Vec) -> CertificatePendingMessage {
+ pub fn new(
+ epoch: i64,
+ entity_type: std::collections::HashMap,
+ protocol: ProtocolParameters,
+ next_protocol: ProtocolParameters,
+ signers: Vec,
+ next_signers: Vec,
+ ) -> CertificatePendingMessage {
CertificatePendingMessage {
epoch,
beacon: None,
@@ -46,4 +57,3 @@ impl CertificatePendingMessage {
}
}
}
-
diff --git a/rust/src/models/epoch_settings_message.rs b/rust/src/models/epoch_settings_message.rs
index ba541414..548ffe39 100644
--- a/rust/src/models/epoch_settings_message.rs
+++ b/rust/src/models/epoch_settings_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::protocol_parameters::ProtocolParameters;
+
/// EpochSettingsMessage : Epoch settings
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct EpochSettingsMessage {
@@ -18,14 +20,18 @@ pub struct EpochSettingsMessage {
#[serde(rename = "epoch")]
pub epoch: i64,
#[serde(rename = "protocol")]
- pub protocol: models::ProtocolParameters,
+ pub protocol: ProtocolParameters,
#[serde(rename = "next_protocol")]
- pub next_protocol: models::ProtocolParameters,
+ pub next_protocol: ProtocolParameters,
}
impl EpochSettingsMessage {
/// Epoch settings
- pub fn new(epoch: i64, protocol: models::ProtocolParameters, next_protocol: models::ProtocolParameters) -> EpochSettingsMessage {
+ pub fn new(
+ epoch: i64,
+ protocol: ProtocolParameters,
+ next_protocol: ProtocolParameters,
+ ) -> EpochSettingsMessage {
EpochSettingsMessage {
epoch,
protocol,
@@ -33,4 +39,3 @@ impl EpochSettingsMessage {
}
}
}
-
diff --git a/rust/src/models/mempool_tx_content.rs b/rust/src/models/mempool_tx_content.rs
index b8231375..49b390f0 100644
--- a/rust/src/models/mempool_tx_content.rs
+++ b/rust/src/models/mempool_tx_content.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,20 +11,31 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{
+ mempool_tx_content_inputs_inner::MempoolTxContentInputsInner,
+ mempool_tx_content_outputs_inner::MempoolTxContentOutputsInner,
+ mempool_tx_content_redeemers_inner::MempoolTxContentRedeemersInner,
+ mempool_tx_content_tx::MempoolTxContentTx,
+};
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct MempoolTxContent {
#[serde(rename = "tx")]
- pub tx: Box,
+ pub tx: Box,
#[serde(rename = "inputs")]
- pub inputs: Vec,
+ pub inputs: Vec,
#[serde(rename = "outputs")]
- pub outputs: Vec,
+ pub outputs: Vec,
#[serde(rename = "redeemers", skip_serializing_if = "Option::is_none")]
- pub redeemers: Option>,
+ pub redeemers: Option>,
}
impl MempoolTxContent {
- pub fn new(tx: models::MempoolTxContentTx, inputs: Vec, outputs: Vec) -> MempoolTxContent {
+ pub fn new(
+ tx: MempoolTxContentTx,
+ inputs: Vec,
+ outputs: Vec,
+ ) -> MempoolTxContent {
MempoolTxContent {
tx: Box::new(tx),
inputs,
@@ -33,4 +44,3 @@ impl MempoolTxContent {
}
}
}
-
diff --git a/rust/src/models/mempool_tx_content_outputs_inner.rs b/rust/src/models/mempool_tx_content_outputs_inner.rs
index afa6848c..ee82af51 100644
--- a/rust/src/models/mempool_tx_content_outputs_inner.rs
+++ b/rust/src/models/mempool_tx_content_outputs_inner.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,13 +11,15 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::tx_content_output_amount_inner::TxContentOutputAmountInner;
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct MempoolTxContentOutputsInner {
/// Output address
#[serde(rename = "address")]
pub address: String,
#[serde(rename = "amount")]
- pub amount: Vec,
+ pub amount: Vec,
/// UTXO index in the transaction
#[serde(rename = "output_index")]
pub output_index: i32,
@@ -31,12 +33,23 @@ pub struct MempoolTxContentOutputsInner {
#[serde(rename = "collateral")]
pub collateral: bool,
/// The hash of the reference script of the output
- #[serde(rename = "reference_script_hash", deserialize_with = "Option::deserialize")]
+ #[serde(
+ rename = "reference_script_hash",
+ deserialize_with = "Option::deserialize"
+ )]
pub reference_script_hash: Option,
}
impl MempoolTxContentOutputsInner {
- pub fn new(address: String, amount: Vec, output_index: i32, data_hash: Option, inline_datum: Option, collateral: bool, reference_script_hash: Option) -> MempoolTxContentOutputsInner {
+ pub fn new(
+ address: String,
+ amount: Vec,
+ output_index: i32,
+ data_hash: Option,
+ inline_datum: Option,
+ collateral: bool,
+ reference_script_hash: Option,
+ ) -> MempoolTxContentOutputsInner {
MempoolTxContentOutputsInner {
address,
amount,
@@ -48,4 +61,3 @@ impl MempoolTxContentOutputsInner {
}
}
}
-
diff --git a/rust/src/models/mempool_tx_content_tx.rs b/rust/src/models/mempool_tx_content_tx.rs
index 52705328..9b0e7568 100644
--- a/rust/src/models/mempool_tx_content_tx.rs
+++ b/rust/src/models/mempool_tx_content_tx.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,13 +11,15 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::tx_content_output_amount_inner::TxContentOutputAmountInner;
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct MempoolTxContentTx {
/// Transaction hash
#[serde(rename = "hash")]
pub hash: String,
#[serde(rename = "output_amount")]
- pub output_amount: Vec,
+ pub output_amount: Vec,
/// Fees of the transaction in Lovelaces
#[serde(rename = "fees")]
pub fees: String,
@@ -66,7 +68,25 @@ pub struct MempoolTxContentTx {
}
impl MempoolTxContentTx {
- pub fn new(hash: String, output_amount: Vec, fees: String, deposit: String, size: i32, invalid_before: Option, invalid_hereafter: Option, utxo_count: i32, withdrawal_count: i32, mir_cert_count: i32, delegation_count: i32, stake_cert_count: i32, pool_update_count: i32, pool_retire_count: i32, asset_mint_or_burn_count: i32, redeemer_count: i32, valid_contract: bool) -> MempoolTxContentTx {
+ pub fn new(
+ hash: String,
+ output_amount: Vec,
+ fees: String,
+ deposit: String,
+ size: i32,
+ invalid_before: Option,
+ invalid_hereafter: Option,
+ utxo_count: i32,
+ withdrawal_count: i32,
+ mir_cert_count: i32,
+ delegation_count: i32,
+ stake_cert_count: i32,
+ pool_update_count: i32,
+ pool_retire_count: i32,
+ asset_mint_or_burn_count: i32,
+ redeemer_count: i32,
+ valid_contract: bool,
+ ) -> MempoolTxContentTx {
MempoolTxContentTx {
hash,
output_amount,
@@ -88,4 +108,3 @@ impl MempoolTxContentTx {
}
}
}
-
diff --git a/rust/src/models/mithril_stake_distribution_message.rs b/rust/src/models/mithril_stake_distribution_message.rs
index 33c5c013..b63630fa 100644
--- a/rust/src/models/mithril_stake_distribution_message.rs
+++ b/rust/src/models/mithril_stake_distribution_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{protocol_parameters::ProtocolParameters, signer_with_stake::SignerWithStake};
+
/// MithrilStakeDistributionMessage : This message represents a Mithril stake distribution.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct MithrilStakeDistributionMessage {
@@ -25,17 +27,23 @@ pub struct MithrilStakeDistributionMessage {
pub certificate_hash: Option,
/// The list of the signers with their stakes and verification keys
#[serde(rename = "signers")]
- pub signers: Vec,
+ pub signers: Vec,
/// Date and time of the entity creation
#[serde(rename = "created_at")]
pub created_at: String,
#[serde(rename = "protocol_parameters")]
- pub protocol_parameters: models::ProtocolParameters,
+ pub protocol_parameters: ProtocolParameters,
}
impl MithrilStakeDistributionMessage {
/// This message represents a Mithril stake distribution.
- pub fn new(epoch: i64, hash: String, signers: Vec, created_at: String, protocol_parameters: models::ProtocolParameters) -> MithrilStakeDistributionMessage {
+ pub fn new(
+ epoch: i64,
+ hash: String,
+ signers: Vec,
+ created_at: String,
+ protocol_parameters: ProtocolParameters,
+ ) -> MithrilStakeDistributionMessage {
MithrilStakeDistributionMessage {
epoch,
hash,
@@ -46,4 +54,3 @@ impl MithrilStakeDistributionMessage {
}
}
}
-
diff --git a/rust/src/models/network.rs b/rust/src/models/network.rs
index d3b63b18..37ac9e14 100644
--- a/rust/src/models/network.rs
+++ b/rust/src/models/network.rs
@@ -1,30 +1,30 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
* Generated by: https://openapi-generator.tech
*/
+use super::{network_stake::NetworkStake, network_supply::NetworkSupply};
use crate::models;
use serde::{Deserialize, Serialize};
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Network {
#[serde(rename = "supply")]
- pub supply: Box,
+ pub supply: Box,
#[serde(rename = "stake")]
- pub stake: Box,
+ pub stake: Box,
}
impl Network {
- pub fn new(supply: models::NetworkSupply, stake: models::NetworkStake) -> Network {
+ pub fn new(supply: NetworkSupply, stake: NetworkStake) -> Network {
Network {
supply: Box::new(supply),
stake: Box::new(stake),
}
}
}
-
diff --git a/rust/src/models/network_eras_inner.rs b/rust/src/models/network_eras_inner.rs
index 2d87038c..f70e4eac 100644
--- a/rust/src/models/network_eras_inner.rs
+++ b/rust/src/models/network_eras_inner.rs
@@ -1,28 +1,37 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
* Generated by: https://openapi-generator.tech
*/
+use super::{
+ network_eras_inner_end::NetworkErasInnerEnd,
+ network_eras_inner_parameters::NetworkErasInnerParameters,
+ network_eras_inner_start::NetworkErasInnerStart,
+};
use crate::models;
use serde::{Deserialize, Serialize};
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct NetworkErasInner {
#[serde(rename = "start")]
- pub start: Box,
+ pub start: Box,
#[serde(rename = "end")]
- pub end: Box,
+ pub end: Box,
#[serde(rename = "parameters")]
- pub parameters: Box,
+ pub parameters: Box,
}
impl NetworkErasInner {
- pub fn new(start: models::NetworkErasInnerStart, end: models::NetworkErasInnerEnd, parameters: models::NetworkErasInnerParameters) -> NetworkErasInner {
+ pub fn new(
+ start: NetworkErasInnerStart,
+ end: NetworkErasInnerEnd,
+ parameters: NetworkErasInnerParameters,
+ ) -> NetworkErasInner {
NetworkErasInner {
start: Box::new(start),
end: Box::new(end),
@@ -30,4 +39,3 @@ impl NetworkErasInner {
}
}
}
-
diff --git a/rust/src/models/pool_list_extended_inner.rs b/rust/src/models/pool_list_extended_inner.rs
index d2f6e82f..bdbf6394 100644
--- a/rust/src/models/pool_list_extended_inner.rs
+++ b/rust/src/models/pool_list_extended_inner.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -10,6 +10,7 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use serde_json::Value;
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct PoolListExtendedInner {
@@ -40,11 +41,21 @@ pub struct PoolListExtendedInner {
#[serde(rename = "fixed_cost")]
pub fixed_cost: String,
#[serde(rename = "metadata", skip_serializing_if = "Option::is_none")]
- pub metadata: Option>,
+ pub metadata: Option>,
}
impl PoolListExtendedInner {
- pub fn new(pool_id: String, hex: String, active_stake: String, live_stake: String, live_saturation: f64, blocks_minted: i32, declared_pledge: String, margin_cost: f64, fixed_cost: String) -> PoolListExtendedInner {
+ pub fn new(
+ pool_id: String,
+ hex: String,
+ active_stake: String,
+ live_stake: String,
+ live_saturation: f64,
+ blocks_minted: i32,
+ declared_pledge: String,
+ margin_cost: f64,
+ fixed_cost: String,
+ ) -> PoolListExtendedInner {
PoolListExtendedInner {
pool_id,
hex,
@@ -59,4 +70,3 @@ impl PoolListExtendedInner {
}
}
}
-
diff --git a/rust/src/models/proposal_parameters.rs b/rust/src/models/proposal_parameters.rs
index 7a64678a..a6c60de7 100644
--- a/rust/src/models/proposal_parameters.rs
+++ b/rust/src/models/proposal_parameters.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::proposal_parameters_parameters::ProposalParametersParameters;
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct ProposalParameters {
/// Off-chain metadata of a proposal with a specific transaction hash
@@ -20,11 +22,15 @@ pub struct ProposalParameters {
#[serde(rename = "cert_index")]
pub cert_index: i32,
#[serde(rename = "parameters")]
- pub parameters: Box,
+ pub parameters: Box,
}
impl ProposalParameters {
- pub fn new(tx_hash: String, cert_index: i32, parameters: models::ProposalParametersParameters) -> ProposalParameters {
+ pub fn new(
+ tx_hash: String,
+ cert_index: i32,
+ parameters: ProposalParametersParameters,
+ ) -> ProposalParameters {
ProposalParameters {
tx_hash,
cert_index,
@@ -32,4 +38,3 @@ impl ProposalParameters {
}
}
}
-
diff --git a/rust/src/models/protocol_message.rs b/rust/src/models/protocol_message.rs
index d05313b9..e374d7fd 100644
--- a/rust/src/models/protocol_message.rs
+++ b/rust/src/models/protocol_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,19 +11,18 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::protocol_message_parts::ProtocolMessageParts;
+
/// ProtocolMessage : ProtocolMessage represents a message that is signed (or verified) by the Mithril protocol
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct ProtocolMessage {
#[serde(rename = "message_parts")]
- pub message_parts: models::ProtocolMessageParts,
+ pub message_parts: ProtocolMessageParts,
}
impl ProtocolMessage {
/// ProtocolMessage represents a message that is signed (or verified) by the Mithril protocol
- pub fn new(message_parts: models::ProtocolMessageParts) -> ProtocolMessage {
- ProtocolMessage {
- message_parts,
- }
+ pub fn new(message_parts: ProtocolMessageParts) -> ProtocolMessage {
+ ProtocolMessage { message_parts }
}
}
-
diff --git a/rust/src/models/signer_registrations_message.rs b/rust/src/models/signer_registrations_message.rs
index 76ea7620..c0350171 100644
--- a/rust/src/models/signer_registrations_message.rs
+++ b/rust/src/models/signer_registrations_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,7 +11,9 @@
use crate::models;
use serde::{Deserialize, Serialize};
-/// SignerRegistrationsMessage : This message holds the registered signers at a given epoch.
+use super::signer_registrations_list_item_message::SignerRegistrationsListItemMessage;
+
+/// SignerRegistrationsMessage : This message holds the registered signers at a given epoch.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct SignerRegistrationsMessage {
/// Cardano chain epoch number
@@ -21,11 +23,11 @@ pub struct SignerRegistrationsMessage {
#[serde(rename = "signing_at", skip_serializing_if = "Option::is_none")]
pub signing_at: Option,
#[serde(rename = "registrations", skip_serializing_if = "Option::is_none")]
- pub registrations: Option>,
+ pub registrations: Option>,
}
impl SignerRegistrationsMessage {
- /// This message holds the registered signers at a given epoch.
+ /// This message holds the registered signers at a given epoch.
pub fn new() -> SignerRegistrationsMessage {
SignerRegistrationsMessage {
registered_at: None,
@@ -34,4 +36,3 @@ impl SignerRegistrationsMessage {
}
}
}
-
diff --git a/rust/src/models/signers_tickers_message.rs b/rust/src/models/signers_tickers_message.rs
index 7acd35c3..25d5a5d5 100644
--- a/rust/src/models/signers_tickers_message.rs
+++ b/rust/src/models/signers_tickers_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::signer_ticker_list_item_message::SignerTickerListItemMessage;
+
/// SignersTickersMessage : represents the list of signers known by the aggregator
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct SignersTickersMessage {
@@ -19,16 +21,15 @@ pub struct SignersTickersMessage {
pub network: String,
/// Known signers
#[serde(rename = "signers")]
- pub signers: Vec,
+ pub signers: Vec,
}
impl SignersTickersMessage {
/// represents the list of signers known by the aggregator
- pub fn new(network: String, signers: Vec) -> SignersTickersMessage {
- SignersTickersMessage {
- network,
- signers,
- }
+ pub fn new(
+ network: String,
+ signers: Vec,
+ ) -> SignersTickersMessage {
+ SignersTickersMessage { network, signers }
}
}
-
diff --git a/rust/src/models/snapshot.rs b/rust/src/models/snapshot.rs
index 1dcd96b9..367f9569 100644
--- a/rust/src/models/snapshot.rs
+++ b/rust/src/models/snapshot.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::cardano_db_beacon::CardanoDbBeacon;
+
/// Snapshot : Snapshot represents a snapshot file and its metadata
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Snapshot {
@@ -18,7 +20,7 @@ pub struct Snapshot {
#[serde(rename = "digest")]
pub digest: String,
#[serde(rename = "beacon")]
- pub beacon: models::CardanoDbBeacon,
+ pub beacon: CardanoDbBeacon,
/// Hash of the associated certificate
#[serde(rename = "certificate_hash")]
pub certificate_hash: String,
@@ -32,16 +34,29 @@ pub struct Snapshot {
#[serde(rename = "locations")]
pub locations: Vec,
/// Compression algorithm for the snapshot archive
- #[serde(rename = "compression_algorithm", skip_serializing_if = "Option::is_none")]
+ #[serde(
+ rename = "compression_algorithm",
+ skip_serializing_if = "Option::is_none"
+ )]
pub compression_algorithm: Option,
/// Version of the Cardano node which is used to create snapshot archives.
- #[serde(rename = "cardano_node_version", skip_serializing_if = "Option::is_none")]
+ #[serde(
+ rename = "cardano_node_version",
+ skip_serializing_if = "Option::is_none"
+ )]
pub cardano_node_version: Option,
}
impl Snapshot {
/// Snapshot represents a snapshot file and its metadata
- pub fn new(digest: String, beacon: models::CardanoDbBeacon, certificate_hash: String, size: i64, created_at: String, locations: Vec) -> Snapshot {
+ pub fn new(
+ digest: String,
+ beacon: CardanoDbBeacon,
+ certificate_hash: String,
+ size: i64,
+ created_at: String,
+ locations: Vec,
+ ) -> Snapshot {
Snapshot {
digest,
beacon,
@@ -54,4 +69,3 @@ impl Snapshot {
}
}
}
-
diff --git a/rust/src/models/snapshot_download_message.rs b/rust/src/models/snapshot_download_message.rs
index bce994d2..d8197cf1 100644
--- a/rust/src/models/snapshot_download_message.rs
+++ b/rust/src/models/snapshot_download_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::cardano_db_beacon::CardanoDbBeacon;
+
/// SnapshotDownloadMessage : SnapshotDownloadMessage represents a downloaded snapshot event
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct SnapshotDownloadMessage {
@@ -18,7 +20,7 @@ pub struct SnapshotDownloadMessage {
#[serde(rename = "digest")]
pub digest: String,
#[serde(rename = "beacon")]
- pub beacon: models::CardanoDbBeacon,
+ pub beacon: CardanoDbBeacon,
/// Size of the snapshot file in Bytes
#[serde(rename = "size")]
pub size: i64,
@@ -35,7 +37,14 @@ pub struct SnapshotDownloadMessage {
impl SnapshotDownloadMessage {
/// SnapshotDownloadMessage represents a downloaded snapshot event
- pub fn new(digest: String, beacon: models::CardanoDbBeacon, size: i64, locations: Vec, compression_algorithm: String, cardano_node_version: String) -> SnapshotDownloadMessage {
+ pub fn new(
+ digest: String,
+ beacon: CardanoDbBeacon,
+ size: i64,
+ locations: Vec,
+ compression_algorithm: String,
+ cardano_node_version: String,
+ ) -> SnapshotDownloadMessage {
SnapshotDownloadMessage {
digest,
beacon,
@@ -46,4 +55,3 @@ impl SnapshotDownloadMessage {
}
}
}
-
diff --git a/rust/src/models/snapshot_message.rs b/rust/src/models/snapshot_message.rs
index 1aa66099..1a19fad9 100644
--- a/rust/src/models/snapshot_message.rs
+++ b/rust/src/models/snapshot_message.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::cardano_db_beacon::CardanoDbBeacon;
+
/// SnapshotMessage : This message represents a snapshot file and its metadata.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct SnapshotMessage {
@@ -18,7 +20,7 @@ pub struct SnapshotMessage {
#[serde(rename = "digest")]
pub digest: String,
#[serde(rename = "beacon")]
- pub beacon: models::CardanoDbBeacon,
+ pub beacon: CardanoDbBeacon,
/// Hash of the associated certificate
#[serde(rename = "certificate_hash")]
pub certificate_hash: String,
@@ -32,16 +34,29 @@ pub struct SnapshotMessage {
#[serde(rename = "locations")]
pub locations: Vec,
/// Compression algorithm for the snapshot archive
- #[serde(rename = "compression_algorithm", skip_serializing_if = "Option::is_none")]
+ #[serde(
+ rename = "compression_algorithm",
+ skip_serializing_if = "Option::is_none"
+ )]
pub compression_algorithm: Option,
/// Version of the Cardano node which is used to create snapshot archives.
- #[serde(rename = "cardano_node_version", skip_serializing_if = "Option::is_none")]
+ #[serde(
+ rename = "cardano_node_version",
+ skip_serializing_if = "Option::is_none"
+ )]
pub cardano_node_version: Option,
}
impl SnapshotMessage {
/// This message represents a snapshot file and its metadata.
- pub fn new(digest: String, beacon: models::CardanoDbBeacon, certificate_hash: String, size: i64, created_at: String, locations: Vec) -> SnapshotMessage {
+ pub fn new(
+ digest: String,
+ beacon: CardanoDbBeacon,
+ certificate_hash: String,
+ size: i64,
+ created_at: String,
+ locations: Vec,
+ ) -> SnapshotMessage {
SnapshotMessage {
digest,
beacon,
@@ -54,4 +69,3 @@ impl SnapshotMessage {
}
}
}
-
diff --git a/rust/src/models/tx_content.rs b/rust/src/models/tx_content.rs
index 92ff41a1..d5a8f541 100644
--- a/rust/src/models/tx_content.rs
+++ b/rust/src/models/tx_content.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,8 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::tx_content_output_amount_inner::TxContentOutputAmountInner;
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct TxContent {
/// Transaction hash
@@ -32,7 +34,7 @@ pub struct TxContent {
#[serde(rename = "index")]
pub index: i32,
#[serde(rename = "output_amount")]
- pub output_amount: Vec,
+ pub output_amount: Vec,
/// Fees of the transaction in Lovelaces
#[serde(rename = "fees")]
pub fees: String,
@@ -81,7 +83,30 @@ pub struct TxContent {
}
impl TxContent {
- pub fn new(hash: String, block: String, block_height: i32, block_time: i32, slot: i32, index: i32, output_amount: Vec, fees: String, deposit: String, size: i32, invalid_before: Option, invalid_hereafter: Option, utxo_count: i32, withdrawal_count: i32, mir_cert_count: i32, delegation_count: i32, stake_cert_count: i32, pool_update_count: i32, pool_retire_count: i32, asset_mint_or_burn_count: i32, redeemer_count: i32, valid_contract: bool) -> TxContent {
+ pub fn new(
+ hash: String,
+ block: String,
+ block_height: i32,
+ block_time: i32,
+ slot: i32,
+ index: i32,
+ output_amount: Vec,
+ fees: String,
+ deposit: String,
+ size: i32,
+ invalid_before: Option,
+ invalid_hereafter: Option,
+ utxo_count: i32,
+ withdrawal_count: i32,
+ mir_cert_count: i32,
+ delegation_count: i32,
+ stake_cert_count: i32,
+ pool_update_count: i32,
+ pool_retire_count: i32,
+ asset_mint_or_burn_count: i32,
+ redeemer_count: i32,
+ valid_contract: bool,
+ ) -> TxContent {
TxContent {
hash,
block,
@@ -108,4 +133,3 @@ impl TxContent {
}
}
}
-
diff --git a/rust/src/models/tx_content_metadata_inner.rs b/rust/src/models/tx_content_metadata_inner.rs
index 1006d6ce..2079cc95 100644
--- a/rust/src/models/tx_content_metadata_inner.rs
+++ b/rust/src/models/tx_content_metadata_inner.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,21 +11,25 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::tx_content_metadata_inner_json_metadata::TxContentMetadataInnerJsonMetadata;
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct TxContentMetadataInner {
/// Metadata label
#[serde(rename = "label")]
pub label: String,
#[serde(rename = "json_metadata")]
- pub json_metadata: Box,
+ pub json_metadata: Box,
}
impl TxContentMetadataInner {
- pub fn new(label: String, json_metadata: models::TxContentMetadataInnerJsonMetadata) -> TxContentMetadataInner {
+ pub fn new(
+ label: String,
+ json_metadata: TxContentMetadataInnerJsonMetadata,
+ ) -> TxContentMetadataInner {
TxContentMetadataInner {
label,
json_metadata: Box::new(json_metadata),
}
}
}
-
diff --git a/rust/src/models/tx_content_pool_certs_inner.rs b/rust/src/models/tx_content_pool_certs_inner.rs
index fe37504f..bcd42878 100644
--- a/rust/src/models/tx_content_pool_certs_inner.rs
+++ b/rust/src/models/tx_content_pool_certs_inner.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,6 +11,11 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{
+ tx_content_pool_certs_inner_metadata::TxContentPoolCertsInnerMetadata,
+ tx_content_pool_certs_inner_relays_inner::TxContentPoolCertsInnerRelaysInner,
+};
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct TxContentPoolCertsInner {
/// Index of the certificate within the transaction
@@ -37,16 +42,28 @@ pub struct TxContentPoolCertsInner {
#[serde(rename = "owners")]
pub owners: Vec,
#[serde(rename = "metadata", deserialize_with = "Option::deserialize")]
- pub metadata: Option>,
+ pub metadata: Option>,
#[serde(rename = "relays")]
- pub relays: Vec,
+ pub relays: Vec,
/// Epoch in which the update becomes active
#[serde(rename = "active_epoch")]
pub active_epoch: i32,
}
impl TxContentPoolCertsInner {
- pub fn new(cert_index: i32, pool_id: String, vrf_key: String, pledge: String, margin_cost: f64, fixed_cost: String, reward_account: String, owners: Vec, metadata: Option, relays: Vec, active_epoch: i32) -> TxContentPoolCertsInner {
+ pub fn new(
+ cert_index: i32,
+ pool_id: String,
+ vrf_key: String,
+ pledge: String,
+ margin_cost: f64,
+ fixed_cost: String,
+ reward_account: String,
+ owners: Vec,
+ metadata: Option,
+ relays: Vec,
+ active_epoch: i32,
+ ) -> TxContentPoolCertsInner {
TxContentPoolCertsInner {
cert_index,
pool_id,
@@ -56,10 +73,13 @@ impl TxContentPoolCertsInner {
fixed_cost,
reward_account,
owners,
- metadata: if let Some(x) = metadata {Some(Box::new(x))} else {None},
+ metadata: if let Some(x) = metadata {
+ Some(Box::new(x))
+ } else {
+ None
+ },
relays,
active_epoch,
}
}
}
-
diff --git a/rust/src/models/tx_content_utxo.rs b/rust/src/models/tx_content_utxo.rs
index f04d93c0..6fbafa42 100644
--- a/rust/src/models/tx_content_utxo.rs
+++ b/rust/src/models/tx_content_utxo.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,19 +11,28 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::{
+ tx_content_utxo_inputs_inner::TxContentUtxoInputsInner,
+ tx_content_utxo_outputs_inner::TxContentUtxoOutputsInner,
+};
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct TxContentUtxo {
/// Transaction hash
#[serde(rename = "hash")]
pub hash: String,
#[serde(rename = "inputs")]
- pub inputs: Vec,
+ pub inputs: Vec,
#[serde(rename = "outputs")]
- pub outputs: Vec,
+ pub outputs: Vec,
}
impl TxContentUtxo {
- pub fn new(hash: String, inputs: Vec, outputs: Vec) -> TxContentUtxo {
+ pub fn new(
+ hash: String,
+ inputs: Vec,
+ outputs: Vec,
+ ) -> TxContentUtxo {
TxContentUtxo {
hash,
inputs,
@@ -31,4 +40,3 @@ impl TxContentUtxo {
}
}
}
-
diff --git a/rust/src/models/tx_content_utxo_inputs_inner.rs b/rust/src/models/tx_content_utxo_inputs_inner.rs
index 41e9bd6f..e072975e 100644
--- a/rust/src/models/tx_content_utxo_inputs_inner.rs
+++ b/rust/src/models/tx_content_utxo_inputs_inner.rs
@@ -1,7 +1,7 @@
/*
* Blockfrost.io ~ API Documentation
*
- * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
+ * Blockfrost is an API as a service that allows users to interact with the Cardano blockchain and parts of its ecosystem. ## Tokens After signing up on https://blockfrost.io, a `project_id` token is automatically generated for each project. HTTP header of your request MUST include this `project_id` in order to authenticate against Blockfrost servers. ## Available networks At the moment, you can use the following networks. Please, note that each network has its own `project_id`. | Network | Endpoint |
| Cardano mainnet | https://cardano-mainnet.blockfrost.io/api/v0 |
| Cardano preprod | https://cardano-preprod.blockfrost.io/api/v0 |
| Cardano preview | https://cardano-preview.blockfrost.io/api/v0 |
| InterPlanetary File System | https://ipfs.blockfrost.io/api/v0 |
| Milkomeda mainnet | https://milkomeda-mainnet.blockfrost.io/api/v0 |
| Milkomeda testnet | https://milkomeda-testnet.blockfrost.io/api/v0 |
## Milkomeda For more information about how to use Milkomeda as well as the list of available endpoints, see the Milkomeda section.
## Concepts * All endpoints return either a JSON object or an array. * Data is returned in *ascending* (oldest first, newest last) order, if not stated otherwise. * You might use the `?order=desc` query parameter to reverse this order. * By default, we return 100 results at a time. You have to use `?page=2` to list through the results. * All time and timestamp related fields (except `server_time`) are in seconds of UNIX time. * All amounts are returned in Lovelaces, where 1 ADA = 1 000 000 Lovelaces. * Addresses, accounts and pool IDs are in Bech32 format. * All values are case sensitive. * All hex encoded values are lower case. * Examples are not based on real data. Any resemblance to actual events is purely coincidental. * We allow to upload files up to 100MB of size to IPFS. This might increase in the future. * Only pinned IPFS files are counted towards the IPFS quota. * Non-pinned IPFS files are subject to regular garbage collection and will be removed unless pinned. * We allow maximum of 100 queued pins per IPFS user. ## Errors ### HTTP Status codes The following are HTTP status code your application might receive when reaching Blockfrost endpoints and it should handle all of these cases. * HTTP `400` return code is used when the request is not valid. * HTTP `402` return code is used when the projects exceed their daily request limit. * HTTP `403` return code is used when the request is not authenticated. * HTTP `404` return code is used when the resource doesn't exist. * HTTP `418` return code is used when the user has been auto-banned for flooding too much after previously receiving error code `402` or `429`. * HTTP `425` return code is used in Cardano networks, when the user has submitted a transaction when the mempool is already full, not accepting new txs straight away. * HTTP `425` return code is used in IPFS network, when the user has submitted a pin when the pin queue is already full, not accepting new pins straight away. * HTTP `429` return code is used when the user has sent too many requests in a given amount of time and therefore has been rate-limited. * HTTP `500` return code is used when our endpoints are having a problem. ### Error codes An internal error code number is used for better indication of the error in question. It is passed using the following payload. ```json { \"status_code\": 403, \"error\": \"Forbidden\", \"message\": \"Invalid project token.\" } ``` ## Limits There are two types of limits we are enforcing: The first depends on your plan and is the number of request we allow per day. We defined the day from midnight to midnight of UTC time. The second is rate limiting. We limit an end user, distinguished by IP address, to 10 requests per second. On top of that, we allow each user to send burst of 500 requests, which cools off at rate of 10 requests per second. In essence, a user is allowed to make another whole burst after (currently) 500/10 = 50 seconds. E.g. if a user attempts to make a call 3 seconds after whole burst, 30 requests will be processed. We believe this should be sufficient for most of the use cases. If it is not and you have a specific use case, please get in touch with us, and we will make sure to take it into account as much as we can. ## SDKs We support a number of SDKs that will help you in developing your application on top of Blockfrost.
*
* The version of the OpenAPI document: 0.1.76
* Contact: contact@blockfrost.io
@@ -11,13 +11,15 @@
use crate::models;
use serde::{Deserialize, Serialize};
+use super::tx_content_output_amount_inner::TxContentOutputAmountInner;
+
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct TxContentUtxoInputsInner {
/// Input address
#[serde(rename = "address")]
pub address: String,
#[serde(rename = "amount")]
- pub amount: Vec,
+ pub amount: Vec,
/// Hash of the UTXO transaction
#[serde(rename = "tx_hash")]
pub tx_hash: String,
@@ -31,7 +33,10 @@ pub struct TxContentUtxoInputsInner {
#[serde(rename = "inline_datum", deserialize_with = "Option::deserialize")]
pub inline_datum: Option,
/// The hash of the reference script of the input
- #[serde(rename = "reference_script_hash", deserialize_with = "Option::deserialize")]
+ #[serde(
+ rename = "reference_script_hash",
+ deserialize_with = "Option::deserialize"
+ )]
pub reference_script_hash: Option,
/// Whether the input is a collateral consumed on script validation failure
#[serde(rename = "collateral")]
@@ -42,7 +47,16 @@ pub struct TxContentUtxoInputsInner {
}
impl TxContentUtxoInputsInner {
- pub fn new(address: String, amount: Vec, tx_hash: String, output_index: i32, data_hash: Option, inline_datum: Option, reference_script_hash: Option, collateral: bool) -> TxContentUtxoInputsInner {
+ pub fn new(
+ address: String,
+ amount: Vec,
+ tx_hash: String,
+ output_index: i32,
+ data_hash: Option,
+ inline_datum: Option