The Internet Computer is a sharded blockchain platform that can scale out by provising additional subnet blockchains. Smart contracts on one subnet can seamlessly interact with smart contracts on other subnets by X-Net messaging authenticated with threshold BLS signatures. Smart contracts are WASM modules with associated memory pages (which can store up to 404GB of data), and can interact with other smart contracts by sending asynchronous messages following the actor model. We have SDKs for Rust, TypeScript, Python and Motoko, a language purposefully designed for ICP. Furthermore developers have built smart contracts in C, C++ and Haskell. Certain subnets are enabled with additional threshold crypto protocols. Currently, smart contracts can request ECDSA (over the Bitcoin curve secp256k10) signatures. This allows ICP smart contracts to securely sign transactions for other chains. Further threshold crypto protocols are currently in preparation (Schnorr and EdDSA signing, as well as vetKeys). This capability allows to send authenticated messages securly from ICP to e.g. Cosmos chains, and would be a much more efficient path than verifying BLS signatures in a Cosmos chain. However, this does not yet help to read state from other chains.

Decentralized Inscription Service [Need to check with Bob if it makes sense now] Description Ordinal inscriptions are metadata attached to a specific satoshi and are stored on the Bitcoin blockchain. The metadata is encoded in the witness data of a transaction. Usually, inscriptions are in the witness data of spending scripts of P2TR (Pay-to-Taproot) outputs. However, since the Internet Computer currently only supports threshold ECDSA signatures and not threshold Schnorr signatures, we can't inscribe using this approach. Lukily, there's also an approach using P2WSH spending scripts to encode inscriptions. Requirements Acceptance Critera References Open Internet Service for Ordinals data

Hey fellow hacker :wave: , great that you want to explore the capabilities and possibilities of the Internet Computer Protocol. We've compiled a list of resources to make starting off as simple as possible, and provide you a quick reference to find more information, tools and help. General Introduction Tweet thread sized pitch of ICP Introduction to ICP Introduction video from ETHDenver Comparison between different blockain platforms

Overview Status: Draft Project Type: Cooperative - Multiple workers can submit work, and the bounty is shared Time Commitment: Weeks Experience Level: Intermediate Size: USD 25'000 in ICP (at time of distribution) Description In order to provide more visibility of the Internet Computer DeFi ecosystem, ICRC-1 tokens and decentralized exchanges should be listed on the popular financial data provider websites of the cryptocurrency industry, such as CoinMarketCap and DefiLlama. For this, the IC ecosystem needs to define and implement standard interfaces that meet the requirements of the financial data providers. The goal of this bounty is the creation of interface standards and implementations for AMM and orderbook-based decentralized exchanges (DEXes).

Overview The work on the Bitcoin integration already does some heavy lifting for integrating other chains with the Internet Computer. Most notably, chain-key signing allows canisters on the Internet Computer to sign transactions targeting platforms that support ECDSA, and HTTPS outcalls allow to submit them without incentivizing 3rd party relayers. However, the approach to access Bitcoin state relies on a custom implementation in the Internet Computer replica software, and is as such not a scalable approach for the integration of other chains. One general pattern to allow accessing the state of other chains is to maintain a list of RPC provider services for a given chain and use HTTPS outcalls to interact with a random sample. Depending on the selection of the services and the size of the sample, there can be a high assurance of the valididty of the data if all services in the sample agree. However, with the recent development of the proof-of-stake beacon chain and the merge, there has been significant progress in the development of Ethereum light clients which allows an integration without having to trust the RPC providers. These light clients enable the verification of state and inclusion of events through the use of merkle proofs and the reliance on sync committees - a slowly changing (approx. 25h), random sample of 512 validators - to obtain block headers with BLS signatues, rather than requiring the validation of the entire blockchain. Areas for RFPs We'd like to encourage individuals and teams to explore the integration of Ethereum light clients as canisters on the Internet Computer to allow other canisters secure access to data from the Ethereum blockchain. The nascent Helios client, which is implemented in Rust, could provide a good starting point.

Motivation Ethereum Bridges like Terabethia or Omnic need EVM state or event information in their canisters. HTTPS Outcalls allow to fetch this information from JSON RPC providers like Alchemy or Infura. However, these API providers are single point of failures and can lie to canisters on the IC. An Etherum light client on the IC could be used to verify merkle proofs for state or log information retrieved from these RPC endpoints. Overview A Light client keeps track of block headers as well as the current sync committee to allow verification of arbitray EVM state or inclusion of events via merkle proofs. The sync committee is a group of 512 validators that get randomly assigned every approx. 27 hours that sign block headers via aggregatable BLS signatures. Hence, a light client needs to do the following: Keep track of the current sync committee and their 512 public keys. At least this needs to be done against multiple RPC API providers using incentivized relayers. If we trust a single API provider we haven't gained anything. Keep track of block headers (optional?). Maybe this is even not required, as we could fetch the block header only if a merkle proof requested by a client canister How can some state be verified?

Currently the Internet Computer only supports to transfer all authority by delegation. Internet Identity solves the problem partly by scoping the delegation to a particular host. However, there's no general mechanism on the IC to delegate granular capabilities between all forms of identites on the IC. In the following, we'll briefly present common specifications for capabiltiy tokens that allow granular delegation of capabilities, and discuss various aspects regarding the usage on the Internet Computer. In particular, we'll discuss UCAN CACAO Biscuit

What is an NFT? An NFT or Non-fungible Token is a record on a blockchain which is associated with a particular digital or physical asset. The unique digital representation on a blockchain allows proving ownership and trading of NFTs. The potential application space of NFTs is huge, and we are currently in the early experimentation phase. NFTs on the Internet Computer The Internet Computer brings a lot of potential for NFTs. For digital assets like images, sound clips, or videos, the entire assets can live on-chain, and can be included in on-chain games or metaverse experiences. Furthermore, we can imagine dynamic NFTs that change based on data. Although there are many applications of NFTs, for many of them the defining characteristic is their permanence and immutability (or evolution according to predefined rules). Some of the design decisions of the Internet Computer, such as the the reverse gas model and the upgradablity of canister smart contracts, require the NFT developer to be mindful of details that do not apply to other smart contract platforms.

Overview Status: Open Project Type: Traditional - One worker contributes, and one worker is paid Time Commitment: Weeks Experience Level: Intermediate Size: Description Acceptance Criteria

Overview Status: Open Project Type: Traditional - One worker contributes, and one worker is paid Time Commitment: Weeks Experience Level: Intermediate Size: USD 5'000 (client) + USD 2'500 (canister) in ICP (at time of distribution) Description One of the advantages to deploy a service on a blockchain platform is to be able to receive payments without the usage of a 3rd party service provider. In order to simplify the development of services that want to receive payments, we need libraries that can be integrated into client software and canisters. The base ICRC-1 standard supports the client-orchestrated transfer/notify flow, i.e. the client (payer) transfers the token to service-designated subaccount and notifies the service (payee) about the transfer. This process should abstracted by a library.

Hey fellow devs, I want to introduce a new initiative we are experimenting with: Grant RFPs and Bounties The goal of the initiative is to provide additional incentives to build public open source infrastructure on top of the Internet Computer. Grant RFPs A Request for Proposal (RFP) is a call for a grant proposal dedicated to a specific topic RFPs can be rather broadly scoped, and the applicants are expected to outline their proposals in the grant application. We'll start by using the well-known DFINITY Developer Grants process for this, but we might set up a dedicated process if it turns out useful. The first RFPs are focused on the new unique capabilities that the Internet Computer is getting:

The problem We have lots of tooling built by the community but it is hard to find. While this might be less of an issue for very active developers who monitor the forum and Discord, and are well connected on Twitter, newcomers are having a hard time. We need to think about a scalable way to make developer tools, libraries and so on discoverable. During the last months a lot of developer tooling with potential to increase productivy has been released, e.g. connect2ic by AstroX ic-kit by Psychedelic canister-sdk and ci-tools by InfinitySwap Libraries for logging, the usage of stable memory, distributed transactions, and many more Agents in all kinds of programming languages

Description The maximum size of an ingress message to the Internet Computer is currently limited to 2 MB. Larger files have to be scliced into chunks and assembled in the backend. The certified asset canister supports this via the following interface: type BatchId = nat; type ChunkId = nat; type Key = text; type Time = int; type CreateAssetArguments = record { key: Key;

Reverse an array import Array "mo:base/Array"; func reverse<A>(xs : [A]) : [A] { let size = xs.size(); Array.tabulate(size, func (n : Nat) : A { xs[size - 1 - n]; }); };

@startuml actor User as U "U"->"App": Login "App"->"App": Create session key pair priv/pub "App"->"identity.i0.app": Open window /#authorize "U"->"identity.i0.app": Web Authentication "identity.i0.app" -> "II Canister" "identity.i0.app" -> "App": InternetIdentityReady "App" -> "identity.i0.app": InternetIdentityAuthRequest with pub

Discussion moved here: Spec: Rendered/Github Presentation and discussion in Indy Contributors Call Approach We started with implementing relevant changes to indy node. Although the NYM transaction is defined in Plenum we did not need to change Plenum yet, because the validation is not performed for some reason. Clients (e.g. Indy SDK and Indy VDR) need (at least) to support the new buildNymRequest and buildGetNymRequest. This is an API change. In addtion a new DID focused API layer might be included or left to resolver library sitting on top of the client software. In order to have a working PoC, we wrote a small server to resolve and update DIDs based on the current indy sdk and custom buildNymRequest and buildGetNymRequestfunctions.

Author Start Date: 2020-02-05 Status Status: PROPOSED Status Date: 2021-09-02 Status Note: Summary

Indy SDK and Indy VDR How do we handle changes? nym_request_v2 Breaking API change? Adding additional parameters at the end of the signature and setting to None if not delivered? New NYM Operation and new build_nym_request New Get Nym New API?

The client is an SDK that creates hash or signature chains. Chains are uniquely identified by source + type. Source is given by a DID. The SDK keeps track of the necessary context (e.g. previous hash per chain/type). The SDK itself does not care about persisting the data points or transferring them to the cloud. This should be the job of client where the SDK is used/embedded. Transport could be done via HTTP(S) or MQTT. The general idea is inspired by https://developer.ubirch.com/utp.html https://github.com/ubirch/ubirch-protocol System Requirements We need a confirmation/receipt from the log server in or

We are exploring decentralized and self-sovereign identity systems for people, organizations and things based on open source technologies. In this challenge you'll explore the technology stack and think about use cases. You'll be using https://github.com/bcgov/issuer-kit a demo application provided by the Province of British Columbia in Canada. Your challange will be the following Provide a high-level overview of the application/system Try to get the application running and issue a credential to a smartphone wallet* Describe a use case for this technology that would require another type of credential. How would you evaluate the use case? Bonus Challenge: Adapt the application to issue this type of credential or describe how you would proceed Prepare either a brief written documentation or a small presentation/demo to document your work.