Comment on page
Whitelisted attributes: Make, Model, Year
DIMO unlocks a digital story of a vehicle’s life by creating an on-chain open Vehicle ID of a car. As vehicle data is sent to the DIMO network, it is linked as vehicle lifecycle history. Not just a url to a jpeg of your vehicle, it’s a key to ownership records and selected driving data.
At any point in time, the owner of the asset can access the vehicle's data, analyze , delegate or grant access to a 3rd party for users like insurance, accident reconstruction, carsharing, pre-sale inspection, and more.
As an open and extensible building block, further data can be attached over time, increasing the value of the vehicle ID as a digital asset.
This contract represents a vehicle owned by a DIMO user. To keep the tree structure hierarchical, a vehicle can only be minted under a
In order to ensure data consistency, prevent users from minting unwanted or inappropriate vehicles, some precautions are taken and must be followed by the users. The minting function only accepts calls from authorized addresses, and metatransaction is the mechanism employed to allow users to mint their vehicles with the following steps:
- 1.The user accesses the DIMO app to request to mint their vehicle.
- 2.The user signs a typed structured message with the following information:
- Manufacturer node: token Id associated to the manufacturer of the vehicle.
- Owner: the address of the user.
- Make: the manufacturer of the vehicle.
- Model: the model of the vehicle.
- Year: the year the vehicle was made.
- 3.The request is submitted to the server that will perform verifications to ensure the given information matches the user’s data.
- 4.The server sends a transaction to the
Vehiclecontract invoking the function
mintVehicleSigncontaining the information above along with the
bytesof the signature submitted by the user.
- 5.The contract performs the following instructions:
- 1.Verifies if the
- 2.Recreates the user’s message with the same information passed as arguments.
- 4.Verifies if the signer recovered matches the owner candidate of the vehicle.
- 5.Mints the
Vehiclenode to the user.
Permissions — that is, "who is allowed to do this thing" — are incredibly important in the world of device and vehicle ownership. The access control of asset may govern who is able to read data from your device or write data to your device, or to execute an over the air update.
Vehicles in particular have a complex relationship model. Your vehicle lien holder, your dealer, or even your family each have their own set of things they can and cannot do with a vehicle.
While the simplicity of ownership can be useful for simple systems or quick prototyping, different levels of authorization are often needed. An account may be able to transfer a vehicle for sale, but not unlock the doors.
In essence, we will be defining multiple permissions, each allowed to perform different sets of actions. Instead of granting admin access everywhere - you will use, for example,
unlock:doorsin some places, and
claim:rewardsin others. Separately, you will be able to define rules for how accounts can be assigned a permission, transfer it, and more.
While the infinite customization of permission based access control is useful for making sure we can support any interaction model required by the application, it is in many times beneficial to roll up permission sets into roles.
This allows 3rd party developers building on DIMO to define their own role with an associated permission set...Fleet Manager, Lien Holder, etc.
The contract admin creates the privileges, which are saved as straightforward
integers. The contract just keeps track of the associations between privileges and NFTs and determines whether a user has a certain privilege for an NFT; it does not hold any privilege logic.
It is important to notice that the user does not create new privileges; they are just allowed to set them for another user. Only a contract admin can create, enable, and disable privileges. This way, we can put out of action an obsolete privilege and also make new privileges available to be used by everyone at once.
To set a privilege, the user must observe the following:
- Be the owner or approved by the NFT owner
- The privilege must be enabled
Once the rules above are met, the user can call the functions
setPrivilegescontaining information about the privilege they want to set, the NFT, the user, and the expiration of this privilege. Note that, in order to revoke a privilege, the same function can be called with expiration set to zero.
For security concerns,
Vehicle IDholders are now prevented from transferring their NFTs. To assure data consistency, however, several safety measures had already been taken. We want to make sure that all privileges are reset after the
Vehicle IDhas been transferred to a new user to prevent unauthorized access to your vehicle. The NFT version is mapped for this and updated anytime a transfer occurs in the contract. It always consults the most recent NFT version when someone inquires about a user's privileges.