Starknet Burner is a web/mobile wallet for Starknet that works as a plugin for Argent-X

Objectives

The goal of the ticket is to build and integrate an argent-x contract with a plugin

Success Criterias

the following must be done

• [x] create a plugin, if possible as a separate library
• [x] integrate the plugin in the argent-x contract
• [x] make sure we can sign or store some sort of session token.

Additional Information

for now it does not have to be a fully EIP-712 like token that we would sign. The primary goal is to have something working

Objectives

Currently the extension only supports CallContract and GetBlock for the provider. The goal of the issue is to make sure the whole interface is fully managed.

Success Criterias

In order for the task to succeed, provider should implement

• [x] getClassAt
• [x] getEstimateFee
• [x] getStorageAt
• [x] getTransaction
• [x] getTransactionReceipt
• [x] invokeFunction
• [x] deployContract
• [x] declareContract
• [x] getCode
• [x] waitForTransaction

Additional Information

N/A

Objectives

Because (1) we do not want to be confused for the burner wallet by Austin and also because (2) we do not want to be confused for a wallet since we do not manage any account, I would like to remove all references to the work wallet from the project

Success Criterias

There are a few things we will have to discuss

• [x] rename burner/wallet to burner/sandbox or burner/iframe or whatever makes more sense. The reason I am considering these names is because at some points we might want to have a burner/serviceworker for instance and/or a burner/thirdparty
• [x] change vercel configuration to rely on the new naming convention
• [x] search for wallet throughout the burner directory and change it to something more relevant. In the case of the extension, I think we should simply name it burner

Objectives

The wallet should provide different views depending on its state. To begin, we will consider 3 states:

• The initial state that we will call the STATE_UNINITIALIZED state. It is a transient state so it should only display some sort of spinner. It happens when there has never been any sessionKey. If that is the case, the sessionkey will be generated with starknet.js and a script that looks like below. sessionKey should be stored in localStore with the bwsessionkey.

import { ec } from 'starknet';
import { toBN } from 'starknet/utils/number';

const sessionKey = `0x${ec.genKeyPair().getPrivate().toString(16)}`;
const keypair = ec.getKeyPair(toBN(sessPrivateKey));
const sessionPublicKey = ec.getStarkKey(keypair);

Note that the keypair and sessionPublicKey can always be regenerated and do not need to be stored.

• The 2nd state will be called STATE_INITIALIZED. It should provide a view with (1) a QRCode containing https://drone.blaqkube.io/?s=0x... where 0x... is actually the public key associated with the sessionkey (be careful, the session key should NEVER be shared. It should also have a button to fetch the content of https://drone.blaqkube.io/token/0x... that will contain the signed session key. There are 2 ways to transition to the INITIALIZED state: (1) You could come from UNINITIALIZED or (2) you could run an action that would be ACTION_REINITIALIZE

• The 3rd state would be will be called STATE_LOADED. It would assume (1) there is a session stored in bwsessionkey and (2) there is a bwsessiontoken both loaded in the localstore. bwsessiontoken is actually a JSON.stringify of the following structure:

{
  sessionPublicKey: "0x...",
  account: "0x...",
  expires: 1658875466,
  contract: "0x...",
  token: ["0x...", "0x..."]
}

Success Criterias

The success criterias should be the following:

• [x] there should be some state in the component that would represent the application state
• [x] when the wallet loads for the first time, the state should be the following:
  • if there is no bwsessionkey is should move to UNINITIALIZED
  • else if there is no bwsessiontoken is should move to INITIALIZED
  • else it should move to CONNECTED
• [x] the view for UNINITIALIZED should be a spinner. the app should generate a sessionkey and transition to INITIALIZED
• [x] the view for INITIALIZED should be a QRCode with https://drone.blaqkube.io/?s=0x... . and a button to getch the content of https://drone.blaqkube.io/token/0x...
• [x] the view for CONNECTED should be something like that: (1) to start we would not need to display ETH ; (2) the 0x... would actually be the account address and a click on it would copy it on the clipboard ; (3) the icon would be a JazzIcon or a Blockie depending what suits you the best. See an example below:

Additional Information

We will discuss the issue

Objectives

create an sample application that use Argent-X and Braavos and we will be able to move to the burner-wallet

Success Criterias

• [x] create a new directory named starkpilled at the root directory of the project that will be based on Next
• [x] install get-starknet and starknet (i.e. starknet.js) with the project
• [x] add some logic to connect to the wallet with get-starknet. A very basic example looks like than:

import { getStarknet } from 'get-starknet';

export const connect = async () => {
	let starknet = getStarknet();
	console.log('connect...');
	if (!starknet.isConnected) {
		await starknet.enable();
	}
	if (starknet.selectedAddress) {
		const account = starknet.account;
		return account;
	}
	return;
};

• [x] Add 2 input fields, one that will content to that will be the address to transfer token to; the second will contain amount that is a number with default 1 that defines the number of stark pills to send
• [x] Add 3 buttons: (1) Cancel with reset the form; (2) Faucet will set the to to the faucet address, i.e. 0x05a87f6bec0b6121e55f291f8e06e6149accd706fb43c725a7f1fd3f3f62aadf and (3) send will send the token to the address. Note that on goerli, Starkpills are 0x05a87f6bec0b6121e55f291f8e06e6149accd706fb43c725a7f1fd3f3f62aadf.

import { Contract } from 'starknet';
import erc20_abi from 'erc20_abi.json';

const starkpillAddress = `0x05a87f6bec0b6121e55f291f8e06e6149accd706fb43c725a7f1fd3f3f62aadf`;
export const send = async (to: string, amount: number) => {
	let currentAccount = await connect();
	if (!currentAccount) {
		// error
		return;
	}
	const starkpillAddress =
            '0x7a1a9784591aad3cc294ed3d89fa45add74e96e8c20e46a21153a6aa979a9cb';
	let erc20 = new Contract(erc20_abi, starkpillAddress, currentAccount);
	try {
		let tx = await erc20.transfer(to, [amount, 0]);
	} catch (e) {
		// error
		return;
	}
};

• [x] (optional) you can check the current network is goerli and display an error if that is not the case
• [x] (optional) you can detect changes in the account/network and display the account in the application.

Additional informations

• the abi file is localted in drone/src/abi/erc20_abi.json

Objectives

The objective of this milestone is to have a full example of the burner wallet working from a separate app. We might want to have it in a separate repository. We are bullish on Starkpilled : a protocol that would allow people to send STRK to people they like for nothing..

Prerequisites

the 0.3.0 milestone should be completed and the wallet published on npmjs.

Success Criterias

the following must be covered:

• [x] We should be able to connect to the burner wallet
• [x] We should be able to recognize/capture an address from a QRcode
• [x] The app should be a PWA working on iPhone and Android
• [x] We should be able to Grant pills from some outside signed message (check a Faucet)
• [x] We should have a good documentation explaining how to use the wallet

Objectives

The welcome of the burner wallet by the community and the many conversations at the encode club Paris Hackathon in July 2022 that the burner wallet have won, raised the expectation bar a lot. 💯 to everyone who helped with it.

The short term roadmap will focus on:

• leveraging the work done on the session key. we will however revisit the security model with (1) an re-architecture based on a iframe/sandbox ; (2) the addition of control over the contract in the plugin and (3) additional control flows involving 2 session keys
• helping dapps, expecially mobile dapps to benefit from the burner. Good candidates are games and social experiments
• audit the code to make sure this is okay to go live with the wallet.
• rewriting the wallet part in React to help people that would contribute. (Event if I remain convinced that svelte is a better choice).

On the other hand drone that will remain pretty much the same for now, since we understand the concern of wallets like Argent-X to control what it is running.

Success Criterias

The goals as we can imagine it for now is:

• [x] move the burner into an iframe with a clear interface
• [x] the injection of window.starknet.burner so that the burner wallet can be used by starknet-js
• [x] the move of as many as possible of the features of the burner in vanilla js to help with future ports/implementations
• [x] the rewriting of the burner in ReactJS
• [x] a better documentation
• [ ] a good set of tests

Objectives

improve the component so that it can be used from reactjs

Success Criterias

here we should

• [ ] be able to access the burner from a reactjs application
• [ ] be able to interact with the burner from a reactjs application

Additional Information

We can find some resources to do that, including:

• react-svelte by Rich Harris
• pngwn/svelte-adapter

Objectives

the burner wallet should be splitted into 2 components: (1) the extension will be a javascript-only component that would be registered in window.starknet and be available through starknet.js; (2) the wallet will manage the EC key in the localstorage and provide an UI. This 2nd component will be executed in an iFrame.

Success Criterias

This would be the first part of the project, it should:

• [x] implement a simple UI "the wallet" that won't provide much magic for now except that it should be able to receive messages from the parent frame and mock answers
• [x] implement the extension with the various components that are required, including the account, provider and signer
• [x] register the extension in the right global variable so that it can be accessed by starknet.js

Objectives

this task should create the script/doc to grant access and use a session token to the account created #18

Success Criterias

The goal is to have the right commands

• [x] have a script to create the token
• [x] have a script to use the token
• [x] have everything well documented

Additional Information

this issue should only conver the manual management of those scripts.

Objectives

The goal is to remove the script from plugin/py and replace it with a set of Go commands. It should also use a previously deployed argent-x account rather than the openzeppelin account.

Success Criterias

In order for the task to succeed, we should be able to check:

• [ ] check if by any chance you can run the command from the account you have just created.
• [ ] deploy and initialize a new account from a oneliner
• [x] remove the dependency to the OpenZeppelin account

Objectives

There are several reasons behind this exploration. One being security and the fact that dedicated workers should only be called by the script that has initiated it. The second being that the worker lifecycle could expand beyond the scope of a page reload.

Success Criterias

here again, we do not want to implement this in the burner for now but to explore the idea. What we need to check is:

• [ ] create a dedicated worker from the extension and describe worker reload lifecycle. What is the scope of a variable, especially when dealing with page refresh
• [ ] explore the possibilities to store data in localStore/sessionStore depending on the security/incognito options
• [ ] explore the possibilities to store data in an encrypted cookie or any alternate mecasnism

Objectives

We would like to know if there is a way to add the wallet on the same origin as the application. The motivations are beyond the scope of that issue and will be discussed. Anyway the goal of that PR is to see if we can move a NextJS app as a pure static app (i.e. no api) on a subdirectory of another app and load it in the iframe.

Success Criterias

The objective here is just to know if that is feasible. We would need:

• [x] to see if we can package any react app in '/burner' and not '/' for a website
• [x] what is required in the iframe to open `/burner'
• [ ] see if we can access the sessionStore in incognito mode if the iframe content is on the same origin as the main app.

Additional Information

That would be interesting to check if anyone has done something like that already and if not, why?