Qualified users are sent a weekly airdrop


DIMO Registry

The DIMO Registry contract interface is used to verify the user has minted their Vehicle NFT. The ownerOf() function is called to get the address of the vehicle ID. We pass in the user's wallet address and check that it matches with the associated vehicle ID's owner.

Chainalysis Oracle

Sanctioned wallets are not ellgible for rewards. We use the isSanction(address addr) function to ensure that illegal wallets do not receive any DIMO. The ABI for the Oracle is

		"inputs": [
				"internalType": "address",
				"name": "addr",
				"type": "address"
		"name": "isSanctioned",
		"outputs": [
				"internalType": "bool",
				"name": "",
				"type": "bool"
		"stateMutability": "view",
		"type": "function"

The Chainalysis oracle is available on multiple EVM-compatible networks and can be seen here

Diminishing Rewards

The initial weekly reward amount is 1,300,000 DIMO and decreases by 15% per year. Tracking time reliably and doing math involving floats is not ideal in EVM; To get around this limitation we implement a weekly transaction to manage state as a heuristic.

updateWeek() must be called prior to batchTransfer() in order to update the amount of weeks that has passed since genesis of the rewards contract. Number of weeks that have passed is calcualted by block.timestamp - rewardsGenesisTime divided by 7 days.

dimoTotalSentOutByContract is used to keep track of the amount of dimo that has been sent to elligible users. Whenever the batch transfer takes place, we check to ensure the calculated sum of rewards does not exceed the total weekly amount.


This contract from OpenZeppelin is used to implement roles in the rewards contract. Eventually an Oracle will be used to run rewards autonomously, and at that point a new role will be required to prevent just anyone from accessing the necessary functions.



(address indexed _user, uint256 _amount_);

Emits when a user receives DIMO from this contract


(address indexed _to, uint256 _amount_);

Emits when a user did not meet the eligibility requirements


To implement future features for posterity, we are using the Universal Upgradeable Proxy Standard, aka EIP 1822. This pattern is a standard for proxy contracts which is universally compatible with all contracts, and does not create incompatibility between the proxy and business-logic contracts. This is achieved by utilizing a unique storage position in the proxy contract to store the Logic Contract’s address. A compatibility check ensures successful upgrades. Upgrading can be performed unlimited times, or as determined by custom logic. In addition, a method for selecting from multiple constructors is provided, which does not inhibit the ability to verify bytecode.

Last updated