All application-specific pallets for encointer
a substrate pallet to perform encointer ceremonies
A substrate pallet for encointer communities and managing their meetup locations
a substrate pallet to perform encointer ceremonies
a balances module that supports multiple communities and demurrage
a registry for classifieds from community members, linking to IPFS
A digital personhood verification oracle with XCM support. See the README.md on the stale demo branch for more info: https://github.com/encointer/pallets/tree/demo/xcm-personhood-oracle-and-sybil-gate-template#encointer-pallets
You can automatically update the WeightInfo definitions by running the benchmarks in an encointer-node with the
script in the node's repository: ./scripts/benchmark_runtime.sh and uncommenting the line with
frame-weight-template-full-info.hbs (see the script's documentation).
- There is a know issue with serializing u-/i128 in the json-rpc crate, see (paritytech/substrate#4641). This affects us predominantly when serializing fixed point numbers in the custom RPCs. There is a custom serialization shim as a workaround for that issue in ep-core, which can be used as custom serde attribute like:
#[cfg_attr(feature = "serde_derive", derive(Serialize, Deserialize))]
#[cfg_attr(feature = "serde_derive", serde(rename_all = "camelCase"))]
pub struct BalanceEntry<BlockNumber> {
/// The balance of the account after last manual adjustment
#[cfg_attr(feature = "serde_derive", serde(with = "serialize_fixed"))]
pub principal: BalanceType,
/// The time (block height) at which the balance was last adjusted
pub last_update: BlockNumber,
}We also apply substrate's standard of serializing with camelCase.
Major version must increase for polkadot-sdk release upgrades as these are always breaking changes. For convenience, all crates in this repos shall have the same major version.
We bump minor crate versions separately and tag the repository with the highest crate version
motivation: git blame should show on crate directory level if there was a change. This way, browsing the repo on github really shows when a certain pallet or crate has been touched. Even if it's only adjustments for upstream upgrades, just bump crate versions to the newest, which will be tagged globally
Pallet repo version does not need to be aligned with neither node or parachain (or runtime) crate versions - although this has been the case in the past.
use cargo-release we exclude non-public crates explicitly in tomls
cargo install cargo-release
# check workspace dependency tree
cargo tree --workspace -i ep-core
# add --execute if you're sure
cargo release publish -p ep-core -p encointer-primitives -p pallet-encointer-scheduler -p pallet-encointer-balances -p pallet-encointer-communities
cargo release publish -p encointer-ceremonies-assignment -p encointer-meetup-validation -p pallet-encointer-ceremonies -p pallet-encointer-bazaar -p pallet-encointer-reputation-commitments -p pallet-encointer-faucet -p pallet-encointer-treasuries -p pallet-encointer-democracy
cargo release publish -p encointer-rpc -p encointer-balances-tx-payment -p encointer-balances-tx-payment-rpc-runtime-api -p encointer-balances-tx-payment-rpc -p pallet-encointer-bazaar-rpc-runtime-api -p pallet-encointer-bazaar-rpc -p pallet-encointer-ceremonies-rpc-runtime-api -p pallet-encointer-ceremonies-rpc -p pallet-encointer-communities-rpc-runtime-api -p pallet-encointer-communities-rpc -p pallet-encointer-treasuries-rpc-runtime-api -p pallet-encointer-treasuries-rpc