Submit the application of AdMeta

[h4n0]

Project Abstract

AdMeta is a Metaverse advertisement platform that focuses on privacy-preserving.

AdMeta uses a TEE-based DID service to identify target groups for advertisers, and with the usage of zero-knowledge proof, AdMeta guarantees not to collect any user data. AdMeta builds multiple forms of ad assets (e.g. billboards, wall paintings) in Metaverse platforms like Decentraland, Bit.Country, to allow land holders to integrate our products easily. Qualified conversions let both users and publishers get rewards from advertisers.

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.

[CLAassistant]

All committers have signed the CLA.

[semuelle]

Hi @h4n0, thank you for your application! We will look into it as soon as possible.

[Noc2]

Thanks for the application. I have a few initial questions: Why do you want to use TEE as well as zero knowledge proofs? And if you plan to use zero knowledge proofs could you provide more information about the technical implementation? In general, a few projects are working on decentralized and privacy persevering ad-systems (usually not metaverse specific). The biggest issue is that it requires a lot of un-chain transactions to prove that people viewed/interacted with the ad. That’s why, for example, braver is still completely centralized. How do you plan to solve this issue (e.g. state channels?)?

[Noc2]

And I have one additional question regarding the business model, which we usually don’t try to focus on as part of the application process: Why are you focusing on metaverse, when as far as I know, no one has figured out how to decentralize regular advertisement and the regular advertisement market at this stage is much bigger/more profitable.

[h4n0]

Thanks for the application. I have a few initial questions: Why do you want to use TEE as well as zero knowledge proofs? And if you plan to use zero knowledge proofs could you provide more information about the technical implementation? In general, a few projects are working on decentralized and privacy persevering ad-systems (usually not metaverse specific). The biggest issue is that it requires a lot of un-chain transactions to prove that people viewed/interacted with the ad. That’s why, for example, braver is still completely centralized. How do you plan to solve this issue (e.g. state channels?)?

Thanks for the quick feedback.

1. About the zero-knowledge proof, my description might be a bit misleading. We use TEE to store all sensitive data, like users' personal data, behavior data, and preferences. We also do the matching between users and ads inside TEE, which ensures that no sensitive data will be exposed during the matching process. We are not planning to use any zero-knowledge proof algorithms for the first version of our product, just simply put sensitive data and data-accessing functions in TEE.
2. About the proof of users' views/clicks, we plan to make every single ad unique from each other. E.g. A company ordered 100 impressions for the same ad, and we will first generate 100 unique IDs for all 100 impressions. With these 100 unique IDs, we build a Merkle tree, which will be stored on chain. A qualified view or click of this ad will give user this ad's unique ID, and with this ID, users can claim rewards. We will simplify the whole process by using Browser extensions in Milestone 3, but the technical details remain the same.

[h4n0]

And I have one additional question regarding the business model, which we usually don’t try to focus on as part of the application process: Why are you focusing on metaverse, when as far as I know, no one has figured out how to decentralize regular advertisement and the regular advertisement market at this stage is much bigger/more profitable.

This is a good question. As you also mentioned, the brave browser tries to have a similar idea implemented in the regular advertisement market. However, as non-Web3 users are not familiar with crypto wallets, they have to provide a custodial wallet, which has lots of limitations. Also, because of the incompatibility between Web2 and Web3, they compromise their product with a centralized service.
While in Metaverse, all users have learned how to use a crypto wallet, and they won't have steep learning curves to interact with our blockchain as well, therefore it allows us to design our product in a more decentralized way, like the above answer I mentioned. Moreover, in Metaverse, the ads can be with more interactive, dynamic formats, unlike the traditional online ads. So that we can make ads fun, interesting, and we want users at least to hate ads less, or even like them ;).

[Noc2]

1. About the zero-knowledge proof, my description might be a bit misleading. We use TEE to store all sensitive data, like users' personal data, behavior data, and preferences. We also do the matching between users and ads inside TEE, which ensures that no sensitive data will be exposed during the matching process. We are not planning to use any zero-knowledge proof algorithms for the first version of our product, just simply put sensitive data and data-accessing functions in TEE.
2. About the proof of users' views/clicks, we plan to make every single ad unique from each other. E.g. A company ordered 100 impressions for the same ad, and we will first generate 100 unique IDs for all 100 impressions. With these 100 unique IDs, we build a Merkle tree, which will be stored on chain. A qualified view or click of this ad will give user this ad's unique ID, and with this ID, users can claim rewards. We will simplify the whole process by using Browser extensions in Milestone 3, but the technical details remain the same.

Thanks for the reply. Could you update the application accordingly? If you have a unique id for every impression (=transaction), this will very quickly become very expensive and doesn’t sound scalable to me on a blockchain (even on polkadot) or maybe I’m missing something here.

[h4n0]

1. About the zero-knowledge proof, my description might be a bit misleading. We use TEE to store all sensitive data, like users' personal data, behavior data, and preferences. We also do the matching between users and ads inside TEE, which ensures that no sensitive data will be exposed during the matching process. We are not planning to use any zero-knowledge proof algorithms for the first version of our product, just simply put sensitive data and data-accessing functions in TEE.
2. About the proof of users' views/clicks, we plan to make every single ad unique from each other. E.g. A company ordered 100 impressions for the same ad, and we will first generate 100 unique IDs for all 100 impressions. With these 100 unique IDs, we build a Merkle tree, which will be stored on chain. A qualified view or click of this ad will give user this ad's unique ID, and with this ID, users can claim rewards. We will simplify the whole process by using Browser extensions in Milestone 3, but the technical details remain the same.

Thanks for the reply. Could you update the application accordingly? If you have a unique id for every impression (=transaction), this will very quickly become very expensive and doesn’t sound scalable to me on a blockchain (even on polkadot) or maybe I’m missing something here.

Thanks, I'll update it.

One impression/click unique id does not necessarily mean a claim transaction. We recommend users collect a certain amount of ids and claim them one time. Also because of the transaction fee, users will tend to collect and claim ids as many as possible, to be more economical. Because the reward of one impression ad could be probably less than the transaction fee for claiming, and we will of course leverage the transaction fee and the minimum reward amount.

In addition, the Merkle tree claiming method I mentioned in my previous answer ensures we store only the Merkle root in each impression ad, and the complete Merkle tree will be stored offchain, just for Merkle proof generation. To verify if one unique id is part of the Merkle tree, the time complexity is O(lgn), where n is the number of ads, therefore scalable is not a big issue so far. We will consider to optimize our current algorithm later, e.g. record users' uid when claiming and distribute rewards periodically (like per day, per week), to reduce the onchain execution time.

[Noc2]

Thanks for the quick reply. Regarding an additional manual claim process, this sounds like it also creates a few additional problems. For example what if users don’t claim their rewards. Do advertisement firms in this case also need to wait for the payment? Anyway, in general, I would be willing to go ahead with milestone 1 at this stage. My main concern regarding milestone 2 + 3 is that they are protocol specific. For example is decentraland fully open source? Are there potentially other projects you could support? The faster way to get the necessary approval would probably for now to just apply for milestone 1 and we sign a follow up grant, once you implemented this milestone.

[h4n0]

Thanks for the quick reply. Regarding an additional manual claim process, this sounds like it also creates a few additional problems. For example what if users don’t claim their rewards. Do advertisement firms in this case also need to wait for the payment? Anyway, in general, I would be willing to go ahead with milestone 1 at this stage. My main concern regarding milestone 2 + 3 is that they are protocol specific. For example is decentraland fully open source? Are there potentially other projects you could support? .

Thanks, yes we will refine our protocol in detail. Decentraland is just used for demo, and we are not a product only on Decentraland. We also contacted Bit.Country, which has onboarded on Kusama, and they showed great interest in our products as well. Our goal is to provide our API and it will be used by any new Metaverse platforms.

The faster way to get the necessary approval would probably for now to just apply for milestone 1 and we sign a follow up grant, once you implemented this milestone

This sounds good to us. We can just apply for milestone 1 for now. How should I change my current application? Should I just remove the milestone 2 and 3?

[Noc2]

Yes, that would be the easiest

[h4n0]

Thanks for the suggestions and questions!
I removed the milestone 2 and 3 parts, and added a sum of them in the section "Further Plans"

[Noc2]

Thanks a lot! Happy to go ahead with it.

[mmagician]

I have a few questions:
First, regarding your comment:

just simply put sensitive data and data-accessing functions in TEE.

Could you explain how you are planning to do this? Will you require each user to own their own TEE-capable device? How else would your users submit their sensitive data to the "TEE-blockchain" - since all Tx's are, by blockchain's nature, public? Is there any encryption of in-flight data happening anywhere, and if so, could you describe this in more detail?

Also, your architecture diagram still contains the zero knowledge proof component, I suggest you update that please, if it's no longer part of your design.

[h4n0]

I have a few questions: First, regarding your comment:

just simply put sensitive data and data-accessing functions in TEE.

Could you explain how you are planning to do this? Will you require each user to own their own TEE-capable device? How else would your users submit their sensitive data to the "TEE-blockchain" - since all Tx's are, by blockchain's nature, public? Is there any encryption of in-flight data happening anywhere, and if so, could you describe this in more detail?

Sure. We'll use the TEE solution from IntegriTEE, who is also the technical partner of Litentry. This solution builds a side-chain beside a parachain, which is also a Substrate based blockchain network. The difference is, side-chain nodes are all TEE capable computers (in this case Intel SGX computers are used). All transactions that happen on parachain will be synced on side-chain. User will encrypt their sensitive data first(probably not by themselves but via our app), and send transactions to our parachain, who then "forward" this encrypted data to the side-chain (Technically speaking, it's not forwarding, but pooling from side-chain). On side-chain, these data will be decrypted for further proceeding.

And by means of this, sensitive data, the matching process and the claiming process won't be exposed in our parachain, because all these are on side-chain. Parachain only receives the result if execution is successful or not, which will be again public.

Also, your architecture diagram still contains the zero knowledge proof component, I suggest you update that please, if it's no longer part of your design.

Thanks for the correction. I've updated the source of the diagram and it should be correct now.

[mmagician]

User will encrypt their sensitive data first(probably not by themselves but via our app)

How exactly will that happen? How do you ensure that only the TEE has the keys to decrypt the user's data, and that users don't need to trust your app (you could just be encrypting with your own keys, for example, and that way have access to all of users' data).

[h4n0]

User will encrypt their sensitive data first(probably not by themselves but via our app)

How exactly will that happen? How do you ensure that only the TEE has the keys to decrypt the user's data, and that users don't need to trust your app (you could just be encrypting with your own keys, for example, and that way have access to all of users' data).

There is an asymmetric RSA key pair in TEE network, which is called the shielding key, and private key is shared between TEE nodes, while public key is known for everyone. Our app will use the public key of the shielding key to sign for users' data, and the TEE workers can decrypt it with the private key of the shielding key.

[mmagician]

Okay, that makes sense. Thanks for the clarification!

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[semuelle]

Hi @h4n0. Would you mind providing an update on your grant work? According to the roadmap, you were planning to deliver M1 in January. We are not strict with delivery deadlines, but if your work is significantly delayed due to unforeseen circumstances, you should submit an amendment with an updated timeline.

[h4n0]

Hi @h4n0. Would you mind providing an update on your grant work? According to the roadmap, you were planning to deliver M1 in January. We are not strict with delivery deadlines, but if your work is significantly delayed due to unforeseen circumstances, you should submit an amendment with an updated timeline.

Hi @semuelle , thanks for the reminder. We are still working on our product. As all of us are currently working as part-time on AdMeta, the timeline will not be exactly like what we mentioned.

[semuelle]

Hey @h4n0, not a problem. Could you modify the duration of the milestones in the contract to reflect a more realistic timeline then, so that we have an idea of what to expect?

[h4n0]

Sorry for the late reply.
Sure, I've created a new PR updating the duration to 6 months. Please have a look.

[alxs]

Hey @h4n0, checking in again. Could you please submit another amendment, or let us know in case you're no longer interested?

[h4n0]

Hi @alxs .

Thank you for the check up. We have finished most parts of our milestone 1 and now are preparing for testing, docker and deployment.

I'll therefore update the plan and inform you once everything is ready.

[alxs]

@h4n0 friendly reminder

[h4n0]

Hey @alxs

Thanks for the reminder. I would apologize again, as I'm still working on the documentation and articles we promised in the list, I hope I can finish it in two weeks.

Cheers

[alxs]

Sounds good @h4n0. In that case, we look forward to receving your delivery.