Building off of the previous exercise (literally!), provide account holders with additional services utilizing the banking protocol.
As you saw in Modules 1 and 2, a common pattern found in protocol architecture is layering protocols one on top of another in a protocol stack. This helps in simplifying the protocol's design by dividing each of its constituants into their own modular layers. How independent each layer is may vary, but this design lends itself well to reusing certain layers for multiple protocols (think about how multiple canisters may leverage the same Database class from Module 3).
The credit provider extends a line of credit to customers while levying higher interest rates per transaction. The shop allows vendors to stock (predefined) items in their inventory. Customers can buy items by transferring funds from their Bank accounts to the vendor’s.
You may have noticed that the original banking protocol also allows account holders to delegate a portion of their balance to be spent by another party, e.g. a third-party app. This functionality is relevant to this module.
In this exercise, you will be building an app that leverages the banking protocol in some way. Select either , and fill in each stubbed canister method.
After navigating to the bank/, let’s take a look at the code in src/creditProvider/ and src/shop.
Task: Complete the implementation of either creditProvider or shop. Feel free to add any helper modules you may need.
Either of the following tests should run to completion depending on which you chose:
dfx canister call Test runCreditProviderTest
()dfx canister call Test runShopTest
()Complete all applications under src/. See the above instructions for testing your implementation.