Tracking the origin of whisky

​Adelphi operates a distillery that is committed to sustainable practices and maintains high quality standards throughout their production process. In order to uphold these values, they leverage blockchain technology to securely store and track information related to their production process.
We track each and every finished bottle of whisky and see each bottle as a unique asset and, through the use of QR barcodes and other smartphone scannable technology, deliver individual data to our customers that interacts with our bottles. This allows the story of your bottle of whisky to be told directly to you, because we can prove every step along the manufacturing process (thanks to the blockchain!), allowing you to discover the provenance of your bottle of whisky right back to its origin, building trust in our process and strengthening your knowledge of your whisky.
 - Adelphi in their website​
To meet their needs for transparency, traceability, and accessibility, Adelphi opted to implement blockchain technology for storing their productive process information. They chose Cedalio, because it facilitates faster development cycles, obviates the need for development expertise in Blockchain or Smart Contracts, and allows them not to worry about gas fees.

High level architecture
A Server to Server architecture was deemed suitable in this case, with Cedalio connected directly to the client's ERP, enabling only ERP users to write information while permitting all users to read it through our GraphQL API.

For adding information, the ERP user must log in using a wallet that corresponds to the schema owner's wallet. Future versions will enable the addition of other wallets for performing operations.
Defining the Data Schema with GraphQL
The data schema was defined by mapping all productive processes and identifying the parameters to be captured in each step of the process. The process was divided into three main stages and input and output parameters were captured for each stage. 
A GraphQL schema was then created to represent each stage of the productive process along with the input/output parameters. The Stage type stores the static fields for each stage, while the dataset type defines the fields that change between input and output. 
This adaptable schema can be easily applied to other productive processes.
type ProductiveProcess @model{
  period: Period!
  milledDate: DateTime!
  mashDate: DateTime!
  mashing: MashingStage
  wash: WashStage
  spirit: DestilingStage
}
​
type Period @model{
  startDate: DateTime!
  endDate: DateTime!
}
​
type MashingStage @model{
    productiveProcess: ProductiveProcess
    startTimestamp: DateTime
    endTimestamp: DateTime
    input: MashingDataSet
    output: MashingDataSet
}
​
type MashingDataSet @model{
    WaterLitres: Float
    flourRatio: Float
    maltWeight: Float
    mashVariety: String
    WaterSproutTemp: Float
    processWaterMeterReading: Float
}
​
type WashStage @model{
    productiveProcess: ProductiveProcess
    startTimestamp: DateTime
    endTimestamp: DateTime
    finalGravity: Float
    fermentationTime: Int
    washValvesClosed: Boolean
    washCausticCleaned: Boolean
    input: WashdataSet
    output: WashdataSet
}
​
type WashdataSet @model{
    washbackTemp: Float
    washSampleTemp: Float
    washVolumeCharged: Float
    washTemperatureTimeOff: Int
}
​
type SpiritStage @model{
    productiveProcess: ProductiveProcess 
    startTimestamp: DateTime
    endTimestamp: DateTime
    spiritChargedVolumeCharged: Float
    spiritChargedValvesClosed: Boolean
    foreshotsStartTime: Int
    timeOnSpirit: Int
    hydrometerTimeOnSpirit: Int
    temperatureTimeOnSpirit: Float
    timeOffSpirit: Int
    hydrometerTimeOffSpirit: Int
    temperatureTimeOffSpirit: Float
    timeStillOff: Int
    hydrometerTimeStillOff: Int
    temperatureTimeStillOff: Float
}
Deploying the schema with our studio
Using the Studio, they created their application and deployed the decentralized database. After that, they were ready to interact directly with it using the provided endpoint.
All operations and activities are monitored through the deployments and operations section.
Interacting with the database
This flow represents the interaction between their backend and the database:
A flow that represents the interaction between the Final User and our gateway.
1.​Authentication: log in with a wallet so Cedalio can verify your identity and return a JWT.
2.GraphQL Request: run a mutation to save new information that creates a request to the gateway.
3.On-chain access control validation: when the gateway receives the information it validates the smart contract containing the ACLs to see if the user has the correspoding permissions to execute the operation
4.Execute the operation: when it is validated, the request is processed and the data is stored in in the database. 
5.Store on-chain the mutation evidence: the operation is appended in the operations log and committed in the smart contract living in the network that was selected in the deployment process.
6.Monitor using the Studio: interact with the data and operations that are run server to server using the provided endpoint
The final product
By using Cedalio, Adelphy has a secure and inmutable model of the full supply chain that describes the manufacture of the whisky. Using this information, clients can scan a QR code that comes in the bottle of Whisky to unlock full visibility of the bottle's journey, enabling end to end traceability.
Adelpy final product
With this product they strengthen the relationship with their clients building trust and positioning themselves as one of the most innovative brands in the space.

​
Last modified 5mo ago