Sponsored Transaction enabled auction

[DOBEN]

Task description

Motivation: Some use cases came with the request to have an example of how to implement a sponsored transaction mechanism on a CIS2 token so that the CIS2 token can be used as a payment token (without acquiring any CCD from an exchange to cover transaction fees).

Some scenarios requested:

• A marketplace wants to allow users (without going through an exchange to acquire CCD in their wallet) to be able to pay for an item with a given CIS2-Token.
• Some reward tokens have been airdropped to user's addresses. Without going through an exchange to acquire CCD in their wallet, the platform wants to add some utility to the reward token for their users.
• A web2/3 company (and its users) are uncomfortable with the fluctuating nature of cryptocurrency. They don't want to hold CCDs in their wallet at all. The web2/3 company wants to offer their services in exchange for receiving a stablecoin e.g. (EUROe) and allow users (without holding CCD in their wallet) to be able to pay for their services in a stablecoin.

The task is to have a simple auction dApp that can hold several items. Everyone can create an item to be auctioned. Users can bid for an item by paying with a given cis2Token via the sponsored transaction mechanism.

Sub-tasks Smart contract state layout:

 items: mapping (u16 -> ItemState)
 cis2_contract: ContractAddress,
 itemCounter: u16,

Smart contract ItemState(state (e.g. sold, active), highest_bidder, highest_bid, item_name, endTime, startTime):

Functions in auction contract:

• [x] addItem (can be called by anyone and the ItemState has to be provided as an input parameter. Some sanity checks will be done.)
• [x] view (returns the state content), viewItemState (returns the state of a specific item).
• [x] bid (The inputParameter to the bid function is equivalent to the OnReceivingCis2Params. This function is not directly invoked by the user but rather the onCis2Received hook function as specified in the cis2 standard. The flow is that the user invokes the permit entry point in the cis2_contract first which transfers the new bid amount to the bid function in this auction contract. The AddtitionalData in the payload part of the PermitParam includes the item_index so that the bid function can retrieve the user's intended item_index as well. The bid function logic contains the following main tasks:
  • checks that only the cis2_contract (hard coded in the state) can call into this hook.
  • updates the itemState if the newest bid is higher than the stored bid for a given item.
  • refunds the old_bidder with old_bid.
  • rejects the transaction if some sanity checks fail. ).
• [x] auction_finalize (can be called by anyone for a specific item after the auction has ended, the item will be marked as sold and the amount of highest_bid cis2-tokens as specified in the ItemState will be transferred to the auction creator).

Additional modification in the cis2-token contract:

• [x] Add sponsored transaction mechanism to cis2-multi token contract example.
• [x] mint(receiverAddress) function (Unprotected, will airdrop a specific amount of cis2-tokens to the receiverAddress).

Front end + Back end part of dApp:

• [x] Add front-end part of dApp
• [x] Add back-end part of dApp

[limemloh]

To me, it seems the bid entry point is not really needed, since onCis2Received is the entry point for making the bidding. Users can use permit or transfer directly on the token contract instead.

[DOBEN]

@limemloh The bid and onCis2Received entry points were consolidated into one entry point.