ICDevs.org Bounty #21 - QuickStart - Actor Model - 200, 100, 50 ICP Prizes

Our first QuickStart bounty has produced four sample dapps so far. You can see the entries below. We are also excited to announce our second QuickStart bounty:

CB-elite - key value store - https://forum.dfinity.org/t/icdevs-org-bounty-20-quickstart-dapp-scaling-with-canisters-200-icp-100-icp-50-icp-multiple-winners/11756/23?u=skilesare

Iceypee - shared canisters - https://forum.dfinity.org/t/icdevs-org-bounty-20-quickstart-dapp-scaling-with-canisters-200-icp-100-icp-50-icp-multiple-winners/11756/19?u=skilesare

GLdev - storage and indexing across container - ICDevs.org Bounty #20 - QuickStart Dapp - Scaling With Canisters - 200 ICP, 100 ICP, 50 ICP - Multiple winners - #15 by GLdev

Hoosan - auto scaling node - ICDevs.org Bounty #20 - QuickStart Dapp - Scaling With Canisters - 200 ICP, 100 ICP, 50 ICP - Multiple winners - #10 by hoosan

QuickStart Dapp - Scaling With Actors - #21

Current Status: Discussion

  • Open for submission - (04/26/2022)

  • Closed

Permenant Link

Bounty Details

  • Bounty Amount: 200 ICP First Prize, 100 ICP Second Prize, 50 ICP Third Prize

  • Project Type: Single Contributor/Team

  • Opened: 04/26/2022

  • Time Commitment: Weeks

  • Project Type: Sample App

  • Experience Type: Intermediate - Motoko; Intermediate - Rust; Intermediate - Web


This bounty gives the opportunity to

  • learn motoko

  • learn rust

  • learn how scaling works

  • learn how to use canisters to create canisters

  • learn about the actor model

  • learn how clients access the Internet Computer

The goal of this bounty is to produce a sample application on the Internet Computer.

Goal: Demonstrate the actor model on the internet computer using a multi-canister architecture

Create a practical dapp that demonstrates the actor model of programming such that a system produces “actor” canisters that can interact in a meaningful and productive manner.

Reach goal 1: Create a system of trust such that all crated actors can inherently trust each other.

Reach goal 2: Create a multi-tenant system that supports multiple actors on one canister to reduce costs, but can “spin out” the actor once it reaches a certain size/value.

Example A: Create a token that has no ledger but trades value between trusted actors such that no tokens can be created or destroyed.

Example B: Create a social application where each “space” can be spun out to its own canister once it has been vetted by the community.

Example C: Create a defi marketplace that spins out a new actor for each asset traded such that all functions of the marketplace are contained inside the actor.

Your application can be written in either motoko, rust, or azel. Further, a motoko and rust version can be submitted as separate entries by the same person/team.

The code must be opensourced using the MIT License.

To submit for this bounty you should:

Create a github repo with your sample application and post the link to either the (dev forum post) or the (ICDevs.org dscvr portal)[DSCVR].

We will start selecting prize winners by May 12th, 2022. Submission will stay open until we believe we have a sufficient number of sample applications. Multiple prizes may be awarded for submissions that reach a sufficient level of completeness.

Bounty Completion

Once your app is complete and submitted, it will be judged on the following criteria:

  • How relevant is this sample dapp for the community?

  • How well is the sample dapp’s functionality presented?

  • Does this sample dapp help me to build enough? Can I use the sample dapp for a real project?

  • How well was the sample dapp written?

  • How many goals were reached?

Bonus considerations:

  • Are there tests?

  • Is the documentation provided (readme file on github) sufficient?

  • A user interface of some kind is highly encouraged so that users of your sample application can get a visual view of how your application works.


The bounty was generously funded by the DFINITY Foundation. Additional donations that fund the administration of these bounties can be sent to ICDevs.org. All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to [email protected]. More information about how you can contribute can be found at our donations page.

Other ICDevs.org Bounties

Can I ask for a clarification of the second goal or some kind of example of:
Create a multi-tenant system that supports multiple actors on one canister to reduce costs, but can “spin out” the actor once it reaches a certain size/value.

Isn’t each canister only able to hold one actor? And if you mean like a middleman/state canister that keeps a list of actor classes and keeps track and manages the actors (not considering the middleman as an actor here); do you mean when the middleman canister runs out of space it scales itself or do you mean it watches for the actors and if they run out of space, it automatically creates an extension of that actor?

I guess to follow up, for a canister holding multiple actors in a list, do you know if it actually hold the actor (so it’s storage is equal to all the actors storage it holds) or are they just references? I did a test by checking statuses of the actors and it seems like the storage space doesnt add the entire storage of a created actor but just wondering if anyone knows for certain.

1 Like

I think this may be as easy as having the actor capable of holding assets/info for multiple entities in a triemap [principal, data] and having an authorized list where functions check the caller. When the canister gets too big it ejects a principal into their own canister with only their principal authorized on the canister, but all the rest of the code the same. It is a bit of mix of actor model and scaling with canisters. It isn’t required for the challenge, but a reach goal!


Ah I see, thank you!