This contract aims to equip developers with a pre-configured smart contract that streamlines implementation and conforms to the standard Provenance layout. With only the need to add or modify endpoints and integrate their logic, developers can focus on their contract's core functionalities. Additionally, the accompanying documentation and tests provide clear examples for proper documentation practices.
This contract was inspired by the metadata-bilateral-exchange and similar contracts.
In the template contract, two crucial concepts that every developer should aim to comprehend are the incorporation of Fees to monetize their contract and the standard structure of the contract.
Fees offer a straightforward method for contract developers to receive funds. If a fee lacks a recipient, it will be routed directly to Provenance foundation. However, if a recipient is specified, the fee will be split evenly, with 50% going to the foundation.
Our contract has been carefully crafted with a modular design, allowing developers to seamlessly integrate their own functionalities without compromising the core components of the smart contract. All message handling follows a consistent pattern: messages enter through the entry points specified in contract.rs, then handed off to their message router, and ultimately are processed by their respective module's handler.
Within this module, you can find all the entrypoints that are invoked by wasmd. Each entrypoint first validates the incoming message before forwarding it to its corresponding message router.
This set of modules comprises the fundamental components that every contract utilizes to define types and messages.
A module used for defining events that will be emitted during contract state modification.
These modules encompass the complete implementation for the various endpoints corresponding to each message variant.
Acting as an intermediary between the contract and its stored state, this module offers a layer that streamlines storage for developers.
A set of modules to assist in testing the smart contract.
This group of modules is used to provide additional tools and helpers for the contract.
The template contract enables all three transaction entry points. These transactions allow the user to manipulate contract and blockchain state with messages.
These message variants are utilized in the construction of the contract and to activate the instantiate entry point.
A default instantiation message that provides and demonstrates commonly used setup functionality.
- owner: The address of the account that will own the contract.
- fee: A fee to be applied when instantiating the contract.
- action: This will always have a value of "instantiate".
This transaction does not emit any events.
{
"default": {
"owner": "tp1y8e0lvgek8em05mpxk8veqfyz9tzwphylq7hxr",
"fee": {
"recipient": "tp1y8e0lvgek8em05mpxk8veqfyz9tzwphylq7hxr",
"amount": {
"denom": "nhash",
"amount": "1000000000"
}
}
}
}
The execute message variants encompass the various methods through which users can interact with and modify the contract. These variants activate the execute entry point.
This transaction will change the owner of the contract to the provided address.
This message variant will fail if the sender is not the current owner of the contract.
- new_owner: The address of the contract's new owner.
- action: This will always have the value of "change_owner".
- change_owner:
- previous_owner: The address of the previous owner.
- new_owner: The address of the new owner.
{
"change_owner": {
"new_owner": "tp1ek77wghn0n9lc7x2uycgh697sjc7fvy995keun"
}
}
The migrate message variants enable the developer to make their contract future-proof by providing the ability to upgrade it in multiple ways.
A default instantiation message that provides and demonstrates commonly used migration functionality.
- None
- action: This will always have a value of "migrate".
- None
{
"default": {}
}
The migrate message variants allow the users to quickly obtain contract information.
The QueryVersion message will return the contract's current version.
- None
{
"query_version": {}
}
{
"data": {
"contract_version": {
"contract": "template",
"version": "1.0.0"
}
}
}
The QueryVersion message will return the contract's current owner.
- None
{
"query_owner": {}
}
{
"data": {
"owner": "tp1y8e0lvgek8em05mpxk8veqfyz9tzwphylq7hxr"
}
}
The following is a list of plugins that we used to increase our development productivity:
- rust-analyzer
- crates
- CodeLLDB
- Better TOML
- Error Lens
We are extremely grateful for all the contributions and suggestions made by the following users: