A detailed example on how it works
This document outlines the end-to-end process—from user interaction to secure computation and data storage—detailing all participants, attributes, and the workflow.
It demonstrates how the Dapp leverages the Intract Protocol to securely compute Twitter-based rewards without exposing sensitive user data.
The Problem Statement
Situation
Context A user logs into a decentralized application (Dapp) using their wallet. The Dapp runs a points system to reward users for posts that generate high engagement on Twitter.
Challenge The user wants to prove their Twitter engagement (for rewards) without revealing their Twitter ID or exposing the actual posts.
Assumptions It is assumed that the user is signing up on the Intract Protocol for the first time, during which their key pair is generated and permissions are set.
Solution
Overview: The Dapp leverages the Intract Protocol, which integrates components like ITCC, IAMS, IIM, and ISS, to execute a permissionless, secure computation. This ensures that sensitive data (Twitter ID and posts) is never directly exposed to the Dapp.
Key Features:
Data Privacy: Users’ Twitter data remains encrypted and private.
Decentralized Security: Utilizes cryptographic key pairs and secure multiparty computation (MPC) via Lit Protocol.
Seamless Integration: Dapp integrates via an SDK, simplifying the adoption of the Intract Protocol.
Detailed Workflow
Key Participants
Dapp (D): The decentralized application that registers on the Intract Protocol and requires the computed results.
User (U): The end user who logs in with their wallet and authorizes data processing without disclosing sensitive details.
Intract TEE Compute Cluster - (ITCC) aka TRUSTED EXECUTION CLUSTER (TEC) Executes the compute job, decrypts tokens using its private key, fetches data, runs the context model, and encrypts results.
Intract Access Management Service (IAMS) aka SECURE ACCESS MANAGER (SAM) Manages user authorization and OAuth integration with Twitter.
Intract Ingestion Module (IIM) aka DATA INGESTION ENGINE (DIE) Schedules and initiates the ingestion jobs based on user permissions and selected recurrence.
Intract Storage Service (ISS) aka ENCRYPTED STORAGE SERVICE: Stores encrypted data securely for future reference.
Key Parameters
Compute Algorithm/Context Model (CM): The algorithm defined by the Dapp to process tweets and compute a user’s reward score.
User Private/Public Key Pair: Generated upon first signup; the private key remains on the user’s machine while the public key is shared across the network.
Dapp Private/Public Key Pair: Used for secure communication and data encryption/decryption with the Dapp.
TEC Private/Public Key Pair: Implemented using Lit Protocol to enforce MPC and validate decryption requests.
Final Workflow
Dapp Registration & Setup:
The Dapp registers on the Intract Protocol, obtaining its private and public keys.
A new context model (CM) is created and verified.
The Dapp integrates the protocol using the provided SDK.
User Login & Initiation:
The user logs into the Dapp with their EVM wallet address.
The Dapp presents a button labeled "Calculate Tweet Bonus using Intract Protocol."
Redirection & Key Generation:
On clicking the button, the user is redirected to the Intract Protocol portal (e.g.,
keys.intract.io).A public/private key pair is generated for the user if not already created (private key remains on the user’s machine).
Permission Request:
The user authorizes Intract Protocol to:
Fetch, encrypt, and store all tweets.
Allow the Dapp to securely execute the compute model on the tweets, receiving only the computed result (no raw data or Twitter ID).
The user is prompted to connect their Twitter account via OAuth.
OAuth & Data Encryption:
The Twitter OAuth service provides a token to IAMS.
IAMS encrypts the token with ITCC's public key and stores it along with details (user public key, platform, token grant date, token expiry date, etc.) in the OAuth table.
Job Scheduling & Data Ingestion:
Based on the user-selected recurrence, IAMS instructs IIM to schedule an ingestion job.
IIM creates a compute job with parameters including OAuth details, user public key, app ID, and compute model.
Computation & Secure Processing:
ITCC receives the job and:
Uses its private key to decode the OAuth token.
Fetches user data (tweets) via the IIM-provided module.
Runs the context model (CM) on the data to compute the final result (R).
Encrypts the processed data using the ITCC public key along with additional parameters provided by Lit Protocol.
The encrypted decryption parameters are then re-encrypted with the user’s public key.
Storage & Result Delivery:
The processed and encrypted data is stored by ISS in a secure third-party service (e.g., AWS).
A pointer to this data is maintained by ISS.
The final result (R) is encrypted using the Dapp’s public key and sent to the Dapp.
ISS also stores a reference (including OAuth table primary key and decryption parameters) for future use.
User data (Twitter credentials, raw tweets) is never stored in plaintext.
Only the computed result is shared with the Dapp, ensuring privacy.
Advantages of This Flow
Data Privacy & Security: Users can leverage their social media engagement without compromising their personal data.
Decentralized Verification: The use of cryptographic keys and secure computation ensures that only authorized computations occur.
Ease of Integration: Dapps can integrate with the Intract Protocol using a straightforward SDK, reducing development overhead.
Scalability: The modular design (with separate components for ingestion, computation, and storage) allows for easy scaling as user demand increases.
Considerations & Future Enhancements
Optimizations:
Automate re-keying or periodic reauthorization for returning users.
Optimize the context model for performance as data volume grows.
Additional Work:
Explore enhancements in error handling and recovery processes.
Integrate additional social media platforms to broaden the scope of rewards.
Last updated