Ethereum ERC20 compliant smart contract for the AMBY Social Token.
In its initial version AMBY is nothing more than a token of appreciation meant to recognize contributions to the Ambianic project in a public, permanent, measurable and non-repudiable way. It has no other initial intrinsic or intended value.
There is an active community discussion how to utilize AMBY tokens in the future within the community network. We would like to create a Web 3 decentralized incentive system (ref: 1, 2, 3) for all participants: maintainers, contributors, and end users. Eventually we would move towards a self sustaining crypto governance system such as a DAO that incentivizes fairly contributors of various kinds joing in early and later stages of the project: users, developers, testers, researchers, marketers, influencers, advisors, governers and other yet to be discovered roles adding true value to the ecosystem.
There are a number of friction points with the traditional startup founding and scaling cycle. This video by the co-founder and CEO of Coinbase is a great summary on the topic.
When it comes to Open Source projects, the issues of funding and sustainability are even more pronounced.
In this great a16z blog post, Jesse Waldem correctly points out what many of us have experienced first hand through involvement in previous Open Source projects over the years.
Open source code has enabled trillions of dollars to be generated by software companies that use it, but the communities that develop that code typically haven’t had a means to capture much of the value directly. That’s because there is a major difference between open source code libraries, which can be easily copied, and networks that form around running open source code as a service. An open source library is an empty blueprint. It’s dead code, until it’s run as an instance and is filled with data, users or both, forming a network or service.
Ambianic is an Open Source project. That's a deliberate choice aligned with our belief that transparency is crucial to build long lasting trust with contributors and end users.
However Ambianic is also a growing community of peers who collaborate on research, development, training and deployment of useful AI models (such as person fall detection) without sharing any private home data. This is a very different type of community structure than a typical Web 2 hub-and-spoke organization that collects private data from its end users (sometimes without permission) into a central storage system to then mine it, anazyze and sell to third parties.
Here is a great blog post by Chris Dixon at a16z who summarizes why Web 3 matters.
Consumers are becoming alert to the risks of centralized Web 2 cloud companies collecting their private data. Governments around the world are also putting increasing pressure on Web 2 companies to stop collecting private user data. This shifts AI research and applications from centralized Web 2 infrastructure and tooling towards decentralized and privacy preserving Web 3 alternatives.
There are 3 pillars of the Ambianic ecosystem that we think will require Web 3 incentives for long term sustainability:
- Local AI labeling by end users on their private data
- Local on-device AI training on user owned devices with user private data
- Federated Learning across participating devices owned by cohorts of users who wish to collectively improve a specific AI model (e.g. fall detection, license plate recognition, classifying bird species).
If you would like to take part in this discussion, now is a great time to join our public slack space.
The initial version of this smart contract was derived from OpenZeppelin's excellent workshop on Managing Smart Contract Upgrades.
Check out this folder to your local environment, and run:
npm install
All necessary configuration variables are sourced through a .env file at the root level of this folder.
Create a .env file and make sure it defines the env required variables. Your .env should look like this:
MNEMONIC=<your Ethereum DEVELOPMENT account hardware mnemonic or software private key>
INFURA_API_KEY=<key to an Infura project under your control>
DEFENDER_TEAM_API_KEY=<Defender API key with permissions to interact with Admin>
DEFENDER_TEAM_API_SECRET_KEY=<secret key corresponding to the team API key above>
Some resources to help you get each of this:
- MNEMONIC:
- INFURA_API_KEY:
- DEFENDER Team API keys: https://docs.openzeppelin.com/defender/guide-upgrades#create-defender-team-api-key
To deploy the initial version on Rinkeby Test Net simply run:
npx hardhat run --network rinkeby scripts/deploy.js.
If it succeeds, the script will print the address of your contract (aka the Proxy) to the console. Write down that address, as it is the one through which you'll manage your contract from now on.
In scripts/upgrade.js, replace the proxy address with the one you got from the initial deployment script above, then run:
npx hardhat run --network rinkeby scripts/upgrade.js
Go to rinkeby.gnosis-safe.io and create a multisig. Then copy its address and, in scripts/transfer-ownership.js, replace the gnosisSafe variable with your own multisig address. Be EXTRA CAREFUL in this step, if you call this script with the wrong address, you'll lose control of your contract's upgrades. Run:
npx hardhat run --network rinkeby scripts/transfer-ownership.js
Note: we're working on letting you create Safe multisigs from Defender, so stay tuned for simplifications of this step! :-)
Take a look at scripts/propose-upgrade.js. The main moving parts are: the address of your contract (aka Proxy), the version of the contract you want to upgrade to, and the proposal metadata object where you can set title and description attributes to provide a high level overview of what you're trying to accomplish with this upgrade. Make sure all of those point to the right stuff and then run:
npx hardhat run --network rinkeby scripts/propose-upgrade.js
If the script succeeds, you'll get a proposal URL printed to the console. Navigate to that link and you'll see the upgrade proposal in Defender, ready to approve and/or execute.