Secret Network Documentation

The Staking Derivatives contract is a sample implementation designed for integration tests and as a foundation for building complex staking logic. It functions as a simplified ERC20-like token that manages balances for multiple addresses through minting and burning based on staking delegations.

Key features include:

• Simplified Token Logic: Provides queries and transfers but excludes allowances and transfer_from to focus on staking mechanics.
• Bonding/Unbonding Mechanism: Uses a 'bonding curve' model where users can bond native staking tokens to receive derivative tokens, or burn derivative tokens to initiate an unbonding process.
• Exit Tax: Supports an owner-configurable exit tax. For example, if a 2% tax is set, only 98% of the tokens are unbonded and returned to the user, while the remaining 2% is transferred to the contract owner's account.

This contract provides a simple implementation of the Ethereum ERC20 interface on Secret Network.

Note: This implementation is intended as a pedagogical tool to help token developers familiarize themselves with the interface. It is not recommended for use as a modern production token contract, as it does not address fundamental flaws in the original ERC20 standard that are addressed in newer standards like ERC777.

The Secret Network build process uses multi-stage Docker builds to produce various deployment artifacts. Depending on your needs (running a full node, deploying to mainnet, or local development), you should target one of the following build outputs:

• release-image: A complete Docker image containing everything required to run a full node.
• build-deb: A Debian (.deb) package for system-level installation.
• build-deb-mainnet: A Debian package specifically configured for mainnet deployment.
• compile-secretd: An image containing only the compiled enclave and secretd (the core component of Secret Network), useful if you do not need the full node stack.
• build-localsecret: A specialized setup for local development that includes a faucet server and health check mechanisms.

The Crypto Verify Contract is a utility contract used to demonstrate and perform cryptographic signature verification within CosmWasm. Currently, it supports ECDSA Secp256k1 parameters.

To use the contract, you must provide the Message, Signature, and Public Key as serialized byte slices. The contract returns a boolean value indicating whether the verification was successful.

The v1.7 upgrade introduces several key features:

• Consensus Seed Rotation: Ability to rotate the consensus seed during network upgrades.
• Expedited Governance Proposals: A faster proposal type with the following initial parameters:
  • Minimum deposit: 750 SCRT
  • Voting time: 24 hours
  • Voting threshold: 2/3 'yes' to pass
  • Note: If an expedited proposal fails to meet the threshold within the shorter duration, it converts to a regular proposal and restarts voting under standard conditions.
• Auto-restaking: An opt-in feature for automatic compounding of staking rewards.
• Light-client validation for blocks: Protects against private data leaks via offline fork attacks and allows contracts to rely on trusted block heights and block times.

The v1.12 upgrade introduces several critical fixes and features:

• Admin Management: Fixes the hardcoded admins feature and adds hardcoded admins as per proposals 269 and 270.
• PFM Fix: Resolves a bug in the Packet Forwarding Module (PFM) that caused it to drop packets for IBC contracts (introduced in v1.9).
• IBC Update: Updates IBC to version v4.5.0.
• CosmWasm Admin Support: Adds admin to WasmMsg::Instantiate in cosmwasm-std. This enables contracts to specify an admin address during the instantiation of other contracts.

Go-CosmWasm provides Go bindings to the CosmWasm smart contract framework. It allows developers to compile, initialize, and execute CosmWasm smart contracts directly from Go code.

As of version 0.7.0, it supports CosmWasm 0.7.0 and any compatible smart contracts.

The CosmWasm VM is an abstraction layer built around the Wasmer VM. It is designed to expose the necessary functionality to run CosmWasm contracts in a high-level manner. It serves two primary purposes:

1. Efficient Unit Testing: Providing a way to write and run tests for CosmWasm contracts.
2. Public API: Serving as an API for running contracts in other environments, such as go-cosmwasm.

It includes necessary glue code for typical operations, such as filesystem (fs) caching.

The Escrow contract is a single-use contract designed to hold native tokens. It enables an arbiter to release tokens (either the full amount or a fraction) to a pre-defined beneficiary.

Key features include:

• Arbiter Control: An arbiter manages the release of funds to the beneficiary.
• Timeout Mechanism: If an optional timeout is reached, tokens can no longer be released to the beneficiary and must instead be returned to the original funder.
• Continuous Funding: Native tokens can be added to the contract at any time without errors or loss of access.

Note: This contract is intended as a tutorial example. For production environments, it is recommended to use a single contract to manage multiple escrows with global configuration, rather than deploying a new contract instance for every escrow.