After discussions with @JakeHartnell and @orkunkl we decided to expand functionality for escrow, this new functionality is as follows:

• Recipient is now optional upon creation, this allows Escrows to be used as bounties e.g. for bug bounties etc.
• Recipient can be set by the arbiter using the new SetRecipient message
• Escrows now feature additional meta data, including a title and description. E.g. for a bounty the description may include steps needed to be valid for said bounty.

Tests are added/updated accordingly.

Feedback as always is welcome

failed to execute message; message index: 0: Error calling the VM: Error during static Wasm validation: Wasm contract has unknown interface_version_* marker export (see https://github.com/CosmWasm/cosmwasm/blob/main/packages/vm/README.md): store wasm contract failed: invalid request

What branch version works with terra network?

PR to add a simple example of implementing the cw20 receiver interface (with some added notes) because someone asked about this in Discord the other day

The current signature verification process for claiming external airdrops requires the claimer to sign an arbitrary message which cannot be performed using a ledger wallet. With the update, claimers of external airdrops will instead be signing a Bank/MsgSend for signature verification purposes, which will enable ledger users to issue airdrop claims.

Adds basic implementation of a CW20 token contract to be used for building composable, yield bearing vault. Interface and inspiration taken from EIP-4626 standard.

This vault contract is designed to allow for modification of two internal, placeholder functions (after_burn & after_mint) to add submessages that can be returned after mint/burn takes place. This allows for messages to/from the vault's ultimate yield sources/protocols that it interacts with.

There exists the ability for this contract to block deposits and withdraws globally and with address block lists. Future work could add in the option for using an approve list instead (or additionally). The global block settings and the address block lists are only allowed to be updated by the contract's admin. This admin config setting is initially set as the address that instantiates the contract (ie. the info.sender), but it can be modified later on only by existing admin.

TLDR

The goal is to adapt the EIP-4626 standard for vaults and interest-bearing tokens to CosmWasm

Background

The EIP-4626 (https://eips.ethereum.org/EIPS/eip-4626) is a standard for tokenized vaults, with the goal of increasing composability between DeFi apps, while providing a more secure and standardized interface.

Motivation

Vaults are commonly implemented in a wide range of Defi applications such as lending markets, yields aggregators, etc. These vaults are normally implemented as yield-bearing tokens and should conform with the CW20 as well. Given how widespread their use is, it would be very helpful to adopt a shared interface of this "Defi lego", to improve developer experience, forward compatibility, and security.

Next steps

If this CW standard is deemed to be useful and we agree on a high-level spec, I can bootstrap the efforts and lead the implementation. It'd be great to do this collaboratively, so any help or contributor is more than welcome :)

Currently airdrop contract supports multiple stages, It is possible that an airdrop only wants to do single stage airdrop. Best to enable this feature on instantiate.

I tried cw20-bonding and got the following error.

❯ CURVEINFO='{"curve_info":{}}'
❯ wasmd query wasm contract-state smart $CONTRACT "$CURVEINFO" --output json 
Error: rpc error: code = InvalidArgument desc = Error calling the VM: Error executing Wasm: Wasmer runtime error: RuntimeError: unreachable: query wasm contract failed: invalid request

Conditions

• Only query "CurveInfo" will cause an error.
• Doesn't happen when "CurveType" is "Constant", but happens after "Buy" for "Linear" and "SquareRoot".(Before "Buy", no error occurs.)
• cw-plus v0.10.0
• wasmd v0.20.0