A schema comprises two primary components:
  • API requests required based on verification conditions
  • Grammar paths from the API responses for extracting the fields needed for verification
  • Assertion for the verification
Here is a example regarding the TikTok:
The request looks like:
curl '' \
-H 'cookie: _tt...faf' \
The response looks like:
"data": {
"user_id": 7*****************7,
"user_id_str": "7*****************7",
"odin_user_type": 12,
"create_time": 1690168843,
"app_id": 1459,
"is_employee": false,
"external_employee_platform": ""
"message": "success"
The verification involves checking whether the account creation date is prior to August 2023(timestamp is 1690848000000).
So the schema looks like:
"category": "Social",
"issuer": "Tiktok",
"desc": "TikTok is a video-sharing app that allows users to create and share short-form videos on any topic.",
"website": "",
"APIs": [
"host": "",
"intercept": {
"url": "passport/web/account/info/",
"method": "GET"
"assert": [
"key": "data|create_time",
"value": "1690848000",
"operation": "<"
"nullifier": "data|user_id_str"
"tips": {
"message": "When you successfully log in, please click the 'Start' button to initiate the verification process."
The nullifier is a required element in the schema, serving to indicate a unique identifier for the user in the data source. It is the witness and will be hashed with a random number generated by MPC in zk circuit to ensure the nullifier's value remains undisclosed to the validator. Developers can use the hash of nullifier to prevent Sybil attacks.
In zkPass dev center, we have preset schemas for user to choose and config. Developers have the flexibility to design their own personalized schemas and seamlessly integrate them into their projects. Further details can be found in the Custom Schema section, providing comprehensive information on how to create and implement customized schemas for your specific needs.
Feel free to contact us if you have any ideas