Funding Trading Bridge Smart Contract

The Funding Trading Bridge Smart Contract exists to convert funds from one denomination to another, allowing for each denomination to dictate a precision by which its coin is valued. It is designed with CosmWasm and utilizes ProvWasm to target the Provenance Blockchain for its deployment.

Status

Documentation

This repository publishes code documentation at the following location: Documentation

Technical Overview and Setup

This contract is designed to facilitate movement of funds from two different restricted Markers:

• The first marker is the "deposit marker." This marker should be a coin that is distributed from some external system. This marker can be defined with the contract in the following ways:
  • If the marker is configured with the allow_forced_transfer option, the contract can simply be given the ACCESS_TRANSFER permission for this marker.
  • If no forced transfers are allowed, the required_attributes feature of markers can be used to ensure that the contract can move funds from the accounts involved with the marker.
  • An Authz Grant can be leveraged to temporarily grant the contract access to transfer funds from the marker.
• The second marker is the "trading marker." This marker should be a coin that is primarily managed by the contract. To ensure that the contract functions correctly, the contract must be given the following permissions to this marker:
  • ACCESS_MINT (to create new tokens when the deposit coin is added to the contract)
  • ACCESS_WITHDRAW (to move newly-minted tokens to accounts after they add their deposit coin)
  • ACCESS_TRANSFER (to transfer both the deposit and trading denoms from accounts as they interact with the contract)
  • ACCESS_BURN (to destroy any trading tokens that the contract receives from accounts).

Once the contract is instantiated and the marker permissions are properly configured, the contract will function to essentially convert the "deposit marker" denom to the "trading marker" denom.

Instantiation

To instantiate the contract, use the standard CosmWasm instantiation functionality after fetching the .wasm file for the latest release from this repository's release section. Use the json version of the InstantiateMsg struct; the file details the various fields and their descriptions.

Execution Routes

The contract's various execution routes and their usages are as follows. View the Msg Definitions and inspect the ExecuteMsg struct to see their parameters and descriptions.

• admin_update_admin: This route allows the current admin of the contract, who is established at instantiation, to choose a new account address to be the admin.
• admin_update_deposit_required_attributes: This route allows the contract admin to choose a new list of Provenance Attributes that must appear on accounts that invoke the fund_trading route.
• admin_update_withdraw_required_attributes: This route allows the contract admin to choose a new list of Provenance Attributes that must appear on accounts that invoke the withdraw_trading route.
• fund_trading: This route allows an account possessing an amount of deposit denom to have its denom traded for an amount of trading denom. It automatically converts the values to the proper precision and ensures that any values that cannot fit into the trading denom's precision remain in the account.
• withdraw_trading: This route allows an account possessing an amount of trading denom received from the contract to return it to the contract and receive its equivalent in the deposit denom. It automatically converts the values to the proper precision and ensures that any values that cannot fit into the trading denom's precision remain in the account.

Query Routes

The contract's various query routes and their usages are as follows. View the Msg Definitions and inspect the QueryMsg struct to see their parameters and descriptions.

• query_contract_state: This route returns the internal contract state, which dictates the denoms specified by the contract, its name and version, as well as other metadata.