At Kakarot, we already have several multisigs on Ethereum mainnet using the usual Safe tool. Recently, we wanted to try out the new Starknet native Argent and Braavos solutions.
Here is our feedback.
Argent multisig solution has been introduced in an article
Last Thursday, eniwhere_ challenged me on twitter with a "wen mint" after I posted a midjourney generated image in response to a public call-out by Only Dust. Using Starksheet, I have been able to no-code deploy the collection now called the
Equilibrium develops a RPC node for Starknet and provides a Docker image to run it.
However, when it comes to running a container in production, some extra settings (like a load balancer, automatic reboot, CPU scaling, etc.) are required.
In this tutorial, I will explain how to deploy such production-grade nodes in AWS, Azure and GCP. All the files used in this tutorial are available in the corresponding repo.
Note: some of the snippets use jq for easily parsing and manipulating json data from the console. If you don't want to install it, just break the command and copy/paste manually the selected entry.
NFTs as they are know today are mostly considered as static proofs of ownership of a digital or physical assets. Recently, the emergence of dynamic NFTs (aka dNFTs, NFTs whose metadata can change over time) has been seen as a way for NFTs to bear more real-life value: NFTs evolve as life goes by. However, from the owner point of view, NFTs are still a passive asset: they don’t control how it evolves nor can’t they decide how they should look like.
Because the NFT metadata is actually produced by a function call (the output of tokenURI for instance), we propose to truly see an NFT as a contract call. Following this new approach, we define Programmable NFTs as NFTs where owners can decide which contract call their NFT makes, and Dynamic Programmable NFTs (dpNFT) as Programmable NFTs where the call parameters are dynamic. Especially, they can be the result (the output) of another dpNFT.
In this context, NFTs become a si
| %builtins output range_check | |
| from starkware.cairo.common.dict_access import DictAccess | |
| from starkware.cairo.common.alloc import alloc | |
| from starkware.cairo.common.squash_dict import squash_dict | |
| struct KeyValue: | |
| member key : felt | |
| member value : felt | |
| end |
Recently, I released a new on-chain CC0 NFT project called the co-bots. This project though had a specificity: while the minting process in on-going, and at given checkpoint, it randomly rewards on of the early adopters with a giveaway in ETH taken from the contract balance.
The launch of the project was last Friday. Right after the launch, and despite a thorough testing (both local unit-test, rinkeby and external audit of the contract) we faced a bug in the discount mechanism: holder of a previous version of the project are able to redeem a voucher for each v1 CoBots that they own.
Yes, as few as 0.1 ETH or more precisely as you can see on
the etherscan contract transaction page
for as few as 0.096212736214 ETH, most of it being the contract itself (0.075760070358 ETH), i.e. all the general
decoding functions that could be embedded once for all in a library. In other words, the image part of the cost is
only about 0.02 ETH!
Of course the gas price at the time of deploying was low (approximately 20 gwei) but even with a fairly high price (say ten times bigger) this would have resulted, for the image part, to only 0.2 ETH.
While it is quite straightforward to use the Chainlink VRF V2 oracle, the Request & Receive Data cycle is a bit less easy to use on a local network (e.g. a hardhat node for testing) when there is no Chainlink node listening to the calls.
This articles aims at giving a step-by-step guide to a working solution for unit-testing a contract using the new Chainlink VRF oracle (Chainlink actually provides an example for the VRF V1 version, see the hardhat starter kit)
| date | ||
|---|---|---|
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 | |
| 0 | 2009-Jun-08 |