Completed: ICDevs.org - Bounty #26 - ICRC-1 Motoko - up to $10k

Developers Bounties
1

Motoko ICRC-1 Motoko - #26

Current Status: Discussion

  • Discussion (08/14/2022)
  • Ratification
  • Open for application
  • Assigned
  • In Review
  • Closed

Official Link

Bounty Details

  • Bounty Amount: $5,000 USD of ICP at award date - $5000 USD of ICP Match Available
  • ICDevs.org DFINITY Foundation Grant Match Available: $5000 USD of ICP at award time - (For every ICP sent to 4dc0678d04c632921a7e5b913a4e3f185a3b48e2da6cba71f4be1e86272a789b, ICDevs.org will add $40 USD of ICP at award date to the bounty, up to the first 125 ICP donated, After 125 ICP, donations to the above address will add .25 ICP to this issue and .75 ICP to fund other ICDevs.org initiatives)
  • Project Type: Team
  • Opened: 09/04/2022
  • Time Commitment: Weeks
  • Project Type: Library
  • Experience Type: Intermediate - Motoko;

Description

This smart contract is a base implementation of an ICRC-1 fungible token.
This bounty gives the opportunity to

  • learn motoko
  • learn about fungible tokens
  • learn about actors and archiving data
  • learn about ICRC-1

This bounty seeks to have a Motoko version of an ICRC-1 token built and available to the community.

Requirements:

  • Must implement all ICRC-1 functions
  • Must provide an archive scheme similar to the ICP ledger for active archiving and scalability. This includes building the archive node and implementing a query_blocks schema even though it hasn’t been finalized by the working group yet.
  • The constructor should allow for easy configuration of the metadata, name, symbol, and total supply. It should also be able to set up a minting account that can mint by sending from and burn by sending to the address.
  • The token should expose any functions needed by the DFINITY Rosetta implementation such that a rosetta node can be populated from the server.

To apply for this bounty you should:

  • Include links to previous work writing tutorials and any other open-source contributions(ie. your github).
  • Include a brief overview of how you will complete the task. This can include things like which dependencies you will use, how you will make it self-contained, the sacrifices you would have to make to achieve that, or how you will make it simple. Anything that can convince us you are taking a thoughtful and expert approach to this design.
  • Give an estimated timeline on completing the task.
  • Post your application text to the Bounty Thread

Selection Process

The ICDevs.org developer’s advisors will propose a vote to award the bounty and the Developer Advisors will vote.

Bounty Completion

Please keep your ongoing code in a public repository(fork or branch is ok). Please provide regular (at least weekly) updates. Code commits count as updates if you link to your branch/fork from the bounty thread. We just need to be able to see that you are making progress.

The balance of the bounty will be paid out at completion.

Once you have finished, please alert the dev forum thread that you have completed work and where we can find that work. We will review and award the bounty reward if the terms have been met. If there is any coordination work(like a pull request) or additional documentation needed we will inform you of what is needed before we can award the reward.

Bounty Abandonment and Re-awarding

If you cease work on the bounty for a prolonged(at the Developer Advisory Board’s discretion) or if the quality of work degrades to the point that we think someone else should be working on the bounty we may re-award it. We will be transparent about this and try to work with you to push through and complete the project, but sometimes, it may be necessary to move on or to augment your contribution with another resource which would result in a split bounty.

Funding

The bounty was generously funded by the DFINITY Foundation. If you would like to turbocharge this bounty you can seed additional donations of ICP to 4dc0678d04c632921a7e5b913a4e3f185a3b48e2da6cba71f4be1e86272a789b. ICDevs will match the bounty $40:1 ICP for the first 125 ICP out of the DFINITY grant and then 0.25:1 after that. 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 donations@icdevs.org. More information about how you can contribute can be found at our donations page.

FYI: General Bounty Process

Discussion

The draft bounty is posted to the DFINITY developer’s forum for discussion

Ratification

The developer advisor’s board will propose a bounty be ratified and a vote will take place to ratify the bounty. Until a bounty is ratified by the Dev it hasn’t been officially adopted. Please take this into consideration if you are considering starting early.

Open for application

Developers can submit applications to the Dev Forum post. The council will consider these as they come in and propose a vote to award the bounty to one of the applicants. If you would like to apply anonymously you can send an email to austin at icdevs dot org or sending a PM on the dev forum.

Assigned

A developer is currently working on this bounty, you are free to contribute, but any splitting of the award will need to be discussed with the currently assigned developer.

In Review

The Dev Council is reviewing the submission

Awarded

The award has been given and the bounty is closed.

Matches

DFINITY Foundation Grant: - $5000 USD of ICP at award date

Other ICDevs.org Bounties

6 Likes
3

I would like to take on this bounty if it hasn’t already been assigned.

I don’t have any public work to share just yet. If that’s a deal breaker I understand.

4

@tomijaga os working on it and has made good progress. Perhaps you can help?

1 Like
5

No worries! I was building a canister for @Pwoseidon so I figured I’d ask. Glad to know someone is working on a formal template.

1 Like
6

Here’s the repo with the implementation: GitHub - NatLabs/icrc1: A full implementation of the ICRC-1 fungible token standard

There are still a few things I haven’t implemented: like the archive canister’s capacity management.

It could be a good starting reference for the canister you are building. There is also a link to the typescript implementation in the readme. If you find anything that you would like improved, let me know.

2 Likes
7

Awesome! Thank you. I’ll take a look this evening; and I will definitely reach out if I have any feedback.

2 Likes
8

Is there a reason why applicants don’t apply publicly on forum; but through sideways and get accepted, seemingly, non-transparently?

3 Likes
9

The lack of book keeping is really just an issue of capacity. I’m currently exploring a funding mechanism that would allow ICDevs to hire a community manager to get that all cleaned up a bit.

In this particular case @tomijaga had already completed another bounty and expressed interest through the forum(pm) and I just didn’t update the public thread.

2 Likes
10

Since canisters can now make HTTP calls, archive canisters could easily use Arweave for cheap long term storage.

Could be an interesting option to the long term storage issue

11

Hey @tomijaga , just trying to “reverse engineer it” to figure out what youre doing and I was wondering, you have an archive canister for unlimited transaction history but the balance counts stored in STmap of your utils.mo, it is limited to whatever storage one canister gives you. Is this correct?

image
image1225×555 49.3 KB

12

Why use arweave when ICP storage is so cheap? 1GB of transaction data is a lot and to keep it native and accessible to other IC canisters is only $5/year.

1 Like
13

This is how the current ICP ledger works as well. Balances are kept on the ‘head’ canister and ‘old’ transactions get moved to an archive canister that can fill up and then a new one is created.

If you look at the ICP code there is a limit on the number of accounts that can hold ICP if it gets over a (very large number) it actually deletes the smallest balances.

1 Like
14

Arweave costs about the same, but you’ll get storage for “minimum 200 years”.

Who knows if it would survive 200 years, but if your 1 GB is stored 2 years for $5, that’s cheaper than spending $10 for 2 years

:man_shrugging:t4:

1 Like
15

The ability to look up and verify an old transaction is likely necessary for most tokens. There are a number of payment flows that work by verifying that info. The ICP canister only holds the 2000 latest transactions, so if you have any kind of async workflow you need access to retrieve the transaction. Even if you had a dependable HTTP gateway to arweave that you could use HTTP outcalls to you’d be looking at cycle costs on the order(total estimate here) of at least 100,000x the cycle cost of a cross canister call and likely a number of rounds of consensus.

There are likely scenarios where storing data off chain on arweave or ipfs might be ok, but in most cases, you are severely limiting composability. It should be an anti-pattern for the IC. If you can store the data on the IC, and the unit economics come anywhere close to working in the medium term, you should store it on the IC. You leave yourself open to serendipity and use cases that you can’t imagine now. Moving it off the IC severely limits that capability.

16

I hope this is only relevant specifically for token transaction history, otherwise the high cost sounds like a major issue. It would force IC to be a closed system, pretty much making it pointless to have outbound HTTP calls if they’re so expensive

(I just looked it up and it’s 2.275 USD to store 1 GB on Arweave. Def a good deal for some use cases)

17

I’m confused dude — I thought the IC supports HTTP calls, but based on what you’ve said here, it sounds extremely inefficient and costly =\

Hmmmm…

18

Probably important to remember that this is base cost to store on Arweave. After that you have to figure out what you’re going to do with it. Does Arweave offer any sort of computation capability? If not, what chain do you go to for that and how much cost to make it work.

1 Like
19

I imagine it will be very expensive relative to a cross-canister call. Instead of just routing a message across a subnet you will have 13 computers make an outgoing HTTP call and then process whatever result is returned, then run a program to sync the responses and ensure a cohesive answer.

According to https://internetcomputer.org/docs/current/developer-docs/deploy/computation-and-storage-costs/ a cross net call’s flat fee is 260,000. So an HTTP out call is 1,538x for just the flat fee. The per byte for HTTP out calls is 100M per byte, but the xcanister is 1,000 per byte. So your bytes are 100,000x more expensive. Perhaps @dieter.sommer can give us an update on what the final costs ended up being as this was rolled to production…these were numbers from a beta discussion.

2 Likes
20

Yea good point — I think it’s primarily for storage but it can do some cool things too haha

:pray:t4::relaxed:

1 Like
21

Ahh I see, that is interesting. Yea I understand that numbers extremely massive. Now thats in rust with very little canister instruction limit right? On a motoko canister, if one were to do some operations on every single balance atomically the actual limit of balances would be limited, no?