fix file comments

examples/examples/benchmark_bulk_xt.rs

@@ -15,9 +15,6 @@
 
 //! This example floods the node with a series of transactions.
 
-// run this against test node with
-// > substrate-test-node --dev --execution native --ws-port 9979 -ltxpool=debug
-
 use kitchensink_runtime::{AccountId, BalancesCall, RuntimeCall};
 use sp_keyring::AccountKeyring;
 use substrate_api_client::{
@@ -26,8 +23,10 @@ use substrate_api_client::{
 	Api, SubmitExtrinsic,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 // Define an extrinsic signer type which sets the generic types of the `GenericExtrinsicSigner`.
 // This way, the types don't have to be reassigned with every usage of this type and makes

examples/examples/check_extrinsic_events.rs

@@ -22,8 +22,10 @@ use substrate_api_client::{
 	Api, GetAccountInformation, SubmitAndWatch, TransactionStatus, XtStatus,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 type Hash = <AssetRuntimeConfig as Config>::Hash;
 

examples/examples/compose_extrinsic_offline.rs

@@ -14,7 +14,7 @@
 */
 
 //! This example shows how to use the compose_extrinsic_offline macro which generates an extrinsic
-//! without asking the node for nonce and does not need to know the metadata
+//! without asking the node for nonce and does not need to know the metadata.
 
 use kitchensink_runtime::{BalancesCall, RuntimeCall};
 use sp_keyring::AccountKeyring;
@@ -25,8 +25,10 @@ use substrate_api_client::{
 	Api, GetChainInfo, SubmitAndWatch, XtStatus,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 #[tokio::main]
 async fn main() {

examples/examples/contract_instantiate_with_code.rs

@@ -24,8 +24,10 @@ use substrate_api_client::{
 	SubmitAndWatch, XtStatus,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 #[allow(unused)]
 #[derive(Decode)]

examples/examples/get_account_identity.rs

@@ -33,8 +33,10 @@ type BalanceOf<T> = <<T as pallet_identity::Config>::Currency as Currency<
 type MaxRegistrarsOf<T> = <T as pallet_identity::Config>::MaxRegistrars;
 type MaxAdditionalFieldsOf<T> = <T as pallet_identity::Config>::MaxAdditionalFields;
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 #[tokio::main]
 async fn main() {

examples/examples/get_blocks_async.rs

@@ -30,8 +30,10 @@ async fn main() {
 	println!("Please compile this example with `--no-default-features` for it to run properly.")
 }
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 #[cfg(not(feature = "sync-examples"))]
 #[tokio::main]

examples/examples/get_storage.rs

@@ -25,8 +25,10 @@ use substrate_api_client::{
 	Api, GetAccountInformation, GetStorage,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 type AccountInfo = GenericAccountInfo<
 	<AssetRuntimeConfig as Config>::Index,

examples/examples/print_metadata.rs

@@ -18,8 +18,10 @@
 
 use substrate_api_client::{ac_primitives::AssetRuntimeConfig, rpc::JsonrpseeClient, Api};
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 #[tokio::main]
 async fn main() {

examples/examples/staking_batch_payout.rs

@@ -24,8 +24,10 @@ use substrate_api_client::{
 
 const MAX_BATCHED_TRANSACTION: u32 = 9;
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 pub type EraIndex = u32;
 

examples/examples/subscribe_events.rs

@@ -26,8 +26,10 @@ use substrate_api_client::{
 // Replace this crate by your own if you run a custom substrate node to get your custom events.
 use kitchensink_runtime::RuntimeEvent;
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 #[tokio::main]
 async fn main() {

examples/examples/sudo.rs

@@ -29,8 +29,10 @@ use substrate_api_client::{
 	Api, GetAccountInformation, SubmitAndWatch, XtStatus,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 // Define an extrinsic signer type which sets the generic types of the `GenericExtrinsicSigner`.
 // This way, the types don't have to be reassigned with every usage of this type and makes

examples/examples/transfer_with_tungstenite_client.rs

@@ -27,8 +27,10 @@ use substrate_api_client::{
 	Api, GetAccountInformation, SubmitAndWatch, XtStatus,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 fn main() {
 	env_logger::init();

examples/examples/transfer_with_ws_client.rs

@@ -27,8 +27,10 @@ use substrate_api_client::{
 	Api, GetAccountInformation, SubmitAndWatch, XtStatus,
 };
 
-// To test this example in CI, we run it against the Substrate kitchensink node. Therefore, we use the AssetRuntimeConfig
-// ! Careful: Most runtimes uses plain as tips, they need a polkadot config.
+// To test this example with CI we run it against the Substrate kitchensink node, which uses the asset pallet.
+// Therefore, we need to use the `AssetRuntimeConfig` in this example.
+// ! However, most Substrate runtimes do not use the asset pallet at all. So if you run an example against your own node
+// you most likely should use `DefaultRuntimeConfig` instead.
 
 fn main() {
 	env_logger::init();