Product Idea - Secret Market

One of the topics discussed recently has been the issue of paywalls. This post describes the problems, and proposes a creative solution that can be turned into a sustainable product for users of the network. I’d love to get some feedback on the idea, refine it, and eventually support anyone that wants to pick it up and build it.

The Problem

Consider the case of a contract offering some asset or content for sale. The contract would set a price in SCRT, sSCRT, or any other SNIP-20 (sETH, sWBTC, etc), and once it received those funds from some sender, it would then send some other funds/NFT/asset to the sender in exchange.

While non-trivial, a very dedicated attacker can create a private fork of the chain where they would send a forged message to the contract with more SCRT than they have in reality (i.e. mainnet). A contract accepting SCRT as payment will then release the funds on sale to the attacker. One example of such a contract is sSCRT, which allows users to deposit SCRT in exchange for sSCRT. These “stolen” tokens can in turn be “sold” to an AMM pair (SecretSwap, SiennaSwap) or an auction to “steal” any number of other tokens, which can in turn be used to steal other assets down the line (such as NFTs).

This sounds scary at first, but it actually isn’t at all, and is the same case in any blockchain out there. The trick is that those assets aren’t real, because they only have value when owned on mainnet. That’s kind of the whole idea of decentralized consensus.

That being said, the issue begins when the content held by the selling contract is a secret in itself. Imagine you wanted to put a private key to some encrypted file up for sale in the Secret Network. Say you offered it in exchange for 2 sETH. An attacker wouldn’t need to pay you, they would just need to trick the contract (with great technical effort!) into giving away the secret.

While this approach is difficult and expensive to execute, it will eventually be worth it for someone to do it, if something valuable enough was put on sale.

The Solution

Fortunately there is a really simple solution to this, which i think can be turned into its own platform, and generally feels closer to how trading valuables works in real life.

The selling contract would allow buyers to deposit funds from any number of payment options listed by the seller in the contract initialization. The seller would then be able to see which addresses have deposited payments for the secret asset. Then, seeing that the deposits have really been made on mainnet, the seller would be able to send an approval transaction with the list of approved buyer addresses. The contract would send the payments made by those buyers to the seller’s account. (it’s important that the approval message contains the address of the buyer, and maybe even the address of the selling contract itself, which would be verified in the contract, to protect against cross-contract replay attacks). That’s all we need to prevent off-chain attacks, as the seller would act as its own contract’s oracle, regarding the state of the chain. You can also automate the sale using a bot acting for the seller. The approved buyers would then be allowed to query the contract for the secret product (using viewing keys for example) and users not approved for the purchase would be able to withdraw their deposit. The contract could also allow the seller to blacklist or whitelist addresses if they want to.

We can then build a UI for this product which would allow a workflow similar to that of platforms that allow artists to accept commissions or sell a limited amount of artifacts to buyers that offer to but them. Put up something for sale, name your minimum prices, review buyers, approve whoever you like, etc. You could even allow buyers to add notes to their deposits which the seller can review. Then tick a checkbox for approved buyers and approve them by clicking a nice big “Approve” button.

Whoever sets this up as a service with a nice UI and everything, can monetize it by setting a small fee (some % of the approved purchases, i.e. the sellers profits) which contracts initialized by the UI would know and send some funds to each time purchases were approved. If someone really didn’t want to pay for the convenience of the website, they could set up their own sale contract.

To recap, this is a sketch of the core functionality:

Init

{
  "title": "The answer to life the universe and everything",
  "description": "You won't believe it when you see it!",
  "product": "It's 42!",
  "whitelist": [],
  "blacklist": [],
  "prices": [
    {"token": "uscrt", "amount": 10000000},
    {"token": "secret1wuzzjsdhthpvuyeeyhfq2ftsn3mvwf9rxy6ykw", "amount": 10000}
  ]
}

Handles:

{"deposit": {"note": "Yooooo can't wait to find out that secret"}} // for SCRT purchases
{"receive": {/* SNIP-20 Receive + message has a similar format to above */}} // for SNIP-20 purchases
{"withdraw": {}} // withdraw the deposited funds, forfeit the purchase
{"approve": {"contract": "secret1asdf", buyers: ["secret1dude", "secret1whatshername"]}}

Queries:

{"offers": {/* seller authentication */}} // get buyer list with used payment method
{"redeem": {/* buyer authentication */}} // Try to read the purchased secret

Again, would love to hear your feedback, how we could make this work with NFTs (CC @baedrik) and not just static secret strings, and what other improvements can be made to the concept. Thanks!

9 Likes

I love it! It should be easy to implement and provides a valuable service.

With regard to incorporating NFTs, it would be relatively trivial to utilize an NFT as the product being sold. During the init, the seller would specify the NFT contract that manages the token he wants to sell so that the paywall can do a RegisterReceiveNft. The seller would then send the already minted NFT to the paywall contract using SendNft, and the paywall contract would transfer the NFT to the approved address once the seller approves it.
You could even automate the init and transfer like OTC auctions do if you wanted to use a factory to instantiate the paywall contract. First the UI, grants the factory transfer approval on the NFT you want to sell, then it calls the CreatePaywall handle of the factory, which will init the paywall contract, and transfer the NFT to the paywall contract automatically.
To accept an NFT as payment would mirror how it would work using SNIP-20s. When instantiating, the seller would list the NFT contract and token_id it should accept as payment, and during the init the paywall registers with the NFT contract so that it will be notified via ReceiveNft once a buyer Sends the NFT to the paywall

2 Likes

That sounds good!

Do you think it is a good idea to have both kinds of sales in the same contract? I think it would add a lot of complexity to maintain both flows in one contract.
Perhaps we can have a “information-paywall” and an “nft-paywall”, and have the factory contract manage multiple types of paywall contracts (or just have multiple factory contracts?).

Maybe an alternative would be to always use the NFT as you describe, but the paywall contract would have two modes:

  1. Sell the NFT to only one buyer. Approving multiple buyers is an error.
  2. Sell access to the private information in the NFT. Querying the sale contract (the redeem query in my sketch) queries the NFT. The NFT forever stays owned by the sale contract.

This would add some complexity for people that want to sell a secret to whoever pays enough, as they would have to mint a Secret NFT, but it would give the NFTs more exposure, and we could probably make the UI around it user-friendly anyways (maybe let the factory have the option of minting the NFT for the user).

3 Likes

One thing to consider is that when the auction is updated to work with NFTs, it will need to have an option at the time of auction creation to indicate if the NFT contains a secret that has value outside of the actual token (will need to think of a better way to phrase that for the UI lol). And in those cases it will require the same approval process. So a lot of paywall functionality will have to be dev anyway for that planned upgrade. I almost wonder if it would make sense to include the different types of fixed-price paywalls (multiple and single-buyer) just by implementing it as a general fixed-price NFT marketplace to be launched from the same page as NFT auctions. And then encourage using NFTs to hold informational paywalls so that it can just use the same contracts

1 Like

Hi there!
We have been working on such a product - information (not NFTs) paywall for a couple of months already,
and took the idea far beyond of what you described here :slight_smile:
We have been almost done with all the functionality of the smart contracts, and will pass to the tests phase very soon.
We are extremely excited to deliver the product ASAP!!
And hope to have your support to grow together the Secret Network! :rocket: :rocket: :rocket:

P.S. Do you mind to upgrade secret network’s fork of the core cosmwasm packages to 0.13.2 (latest) versions? HIGHLY LIKELY :slightly_smiling_face:

3 Likes

Baedrik, can you elaborate on how you envision what you described? I don’t think it’s a good idea to have the same contracts for both sealed-bid auctions and the paywalls we describe in this thread, but i agree that for better discoverability and user experience, they should ideally be presented as two different options in the same UI, or linked from each other. The more i think about it the more i think that they will probably share a lot of code eventually. Even if they end up being developed by a different team, they can live together as two complementary options.

1 Like

Hello James Oaks! :smiley:
We’d love to hear more details about what you’re developing, either here or in private if you’re not ready to share details in a public chat yet (say, a telegram or discord group with Baedrik, myself, and some of our coworkers?).

It sounds like what you’re building is designed with CosmWasm enabled networks in general in mind? I’m curious to hear if (and how) your current project hides the content on sale for everyone except the buyers. Secret Network’s fork of CosmWasm 0.11 has a few modified* and disabled** APIs which will probably force you to change some of your code to accommodate those differences, and in exchange provides fully encrypted inputs, outputs, and storage. On top of that, maintaining privacy invariants requires some extra care, as i described in my original post, and as you can read more about in our privacy model.

* notably contract calls require the code hash as well as the contract address, used to verify that the right contract is being executed.
** iterating storage, migrations, admins, history, disabled either due to technical limitations (storage is encrypted which makes iteration impossible) or due to security considerations (we found the built-in migration mechanism to be a security risk for users)

As for updating our network to also support the latest cosmwasm runtime, we want to and 100% intend to do that, but we still have not started working on it. Due to the added complexity involved with our implementation, adding the support isn’t as easy as just changing some Go functions, but involves re-implementing around 50% of the CosmWasm code to work with a different Wasm engine inside the intel SGX environment. We don’t have an exact plan for when we will make the update so if you want to build on SN in the forseeable term, you’ll have to work with our current version of the runtime.

1 Like

I just mean that any general SNIP721 marketplace (including auctions) will need to include this paywall functionality to protect users whose NFT being sold contains secret information. So if people start using NFTs to hold the secret information, they’ll likely have a choice of paywalls they can use just by using an existing NFT marketplace (assuming all the marketplaces implement paywalls as they should). So it might just naturally drive people to use NFTs for secrets

2 Likes

Our product - DexMarket is developed on Secret Network.

We will create a discord server and share with you guys our product’s main features and concepts, let’s try to think together and decide a mainstream line that will best suit Secret Network’s community’s needs. :cowboy_hat_face:

Got you regarding the upgrades, it is not urgently required, let it go naturally :wink:

2 Likes

sounds good :grinning_face_with_smiling_eyes:
You can find Baedrik and me in the Secret discord server, and feel free to also send invites to everyone on the Enigma team.

1 Like

This is super exciting! What content type are you prioritizing for your go to market?

This can be positioned as an alternative to substack, which is used by a lot of crypto blogs

1 Like

Hello! Basically, any 3rd party company can build a personalized UI Frontend for any type of content utilizing our product! The unique techniques used provide flexibility and usage universality. As you may have seen, we had sent a detailed description of the product in our grant application from 25th April. We value your feedback, so let me know what you think! :slightly_smiling_face:

2 Likes

hi James. is your product planned to be made open source? e.g the paywall part
quite a teasing you made with your ‘usage universality’, im curious to learn more about your solution. the grant application isnt public, right? or i didnt spot it
Sounds great!

1 Like

Hi, we appreciate your interest :slight_smile:
the codebase currently is in advanced stage, however it is not public yet,
as well as the grant application.
We will publish the code and a pilot application version very soon!

2 Likes