Hey everyone! CoS (http://chainofsecrets.org) will be providing infrastructure services and secret contract development in support of the Gridlock project.
I specifically will be focused on working with another Enigma Collective member, @Franklin, to design and implement the secret contract. And likely getting advisory help from @Avret on the secret key share generation 
.
Based on the continued discussion, here is a draft proposal ready for on-chain governance
Draft Proposal v2
Please share your thoughts
Hi everyone! Will be working with @lauraās on the secret contract. Experienced with Python and C/C++. Learning Rust.
Have worked at two start upās before where I was involved with the data science side of the business, https://innius.com/ and https://seita.nl/. Truly excited to be a part of the Gridlock team 
I put the latest proposal on-chain in the deposit period. Do you have any input on it?
Great job on the whitepaper. Iām not sure how I personally feel about the amounts requested to be honest, but itās clear that youāve put a lot of work and effort into this.
A quick technical recommendation - I see youāre citing the work of Lindell et al. when it comes to Threshold ECDSA. Iād recommend you look at GG18 and GG20 as better implementation candidates. The first has a lot more implementations out there to use from, and the latter is simply the state-of-the-art and can add extremely beneficial features such as non-interactive threshold signing and identifying cheaters.
Thank you @Derek, this is a great improvement over the initial version. My main feedback revolves around details of the milestones + some work on go to market
Milestones:
Regarding customers / GTM:
Regarding success factor:
Not sure how the community would react to ācompletion of the projectā as a success factor. We are spending community funds to grow the ecosystem. This depends a lot on adoption and usage (imagine this being similar to Defi for Secret network ecosystem for the sake of argumentation). I think the proposal and plan lacks information on how to get adoption. I would personally vote no if we only care about finishing a product. I think one of the success factors should be the ability to raise external funding say after milestone #1.
At this point, Iām looking at this similar to a y-combinator or angel round investment proposal, because you are starting a for-profit company thatās going to also benefit the Secret Network ecosystem. Iām not sure if we have enough details.
I do want to highlight that Iām excited about the idea in general and I also think that addressing these concerns will help everyone making their decision.
Cheers
NIce @Derek
I see you have figured out some of the key aspects!!
Going to keep an eye out for Gridlock !!
Besides the points others have already raised in regards to pre-funding, I wanted to point out that at current SCRT prices that is not really significant in terms of USD.
This means you wouldnāt really be able to use these funds to fund your dev team, at least in US salary terms for a full time dev team. Unless youāre betting on SCRTās price increasing substantially in 6 months or your devs themselves are planning on holding on to that for a while in order for it to pay off.
This means that I donāt see the point of pre-funding, and it just feels like you want it now for the sake of it. As with any contract agreement, the payment should be disclosed as milestones are reached.
It is the way for my current dev job at my company, and I honestly fail to see why it should be any different for you.
That said, itās a cool feature though and clearly youāve put some thought into it, Iāll give it that.
Thank you for the thoughts @mumuse. Youāve voiced the general consensus regarding funding and weāve decided to put our SCRT funding request on hold for now.
Hello @Derek, I just want to say I like the idea a lot. What would be really powerful is if you could sign a transaction and send it anonymously to another blockchain.
To achieve that, what would you need to do? Would it require that the signed transaction is first put in a mixer and then through some interoperability protocol transferred to the corresponding blockchain? Maybe you could just use a secure connection (like Tor) and the user could transmit it themselves? What are your thoughts on this?
@transitory_system Thatās actually the easy part.
ā
At the end of the day, do most people care if they know the specific address of their funds? It all the same if a single address is used for 10 or 1000 people. The network can securely and privately store internal ledger information which means that an address used for a transaction is not associated with any single person. This provides all the benefits described above with the added guarantee of privacy by default.
I suppose that means that they could use all of the Secret Network functionality (exchange, transfer, DeFi services) using tokens from every other chain. And if they want to exit the pool, they can just point to an address they control and extract their portion (if you are able to generate a transaction that could only be used once). That is some next-level interoperability. But how do they enter the pool? They must provide some kind of proof that it was them that was responsible for a certain transaction on the other chain. So if they supply a valid signed transaction and you store their private key, you can verify that it was them that entered the pool. However, how do you know that the signed transaction is valid and final on the other chain?
Is this similar to what REN is doing with their renBTC?
Just wanted to add that we have a small PoC of something like this (signing using secret keys stored on-chain), using the same type of signatures used by Ethereum - https://github.com/enigmampc/secret-vault
This is a 2 way peg - or current swap expanded in both directions (for ETH)
@transitory_system - You are right, the possibility for interoperability is truly groundbreaking here. Regarding your concerns around a source of truth for finalized transactions, I would say that is mostly covered by existing and trusted APIs. (There are other solutions which would need review on a chain-by-chain basis) Initially, we would err on the side of caution and rely on multiple confirmations, etc. This part of the project isnāt technically complex but, unfortunately, it will require a large amount of work.
@Brendan - It is a bit different. RenBTC and TBTC (from Keep) are both mechanisms that provide cross-chain functionality by locking assets on chain #1 and using equivalent assets on chain #2. There is a ton of complexity needed to lock assets in a decentralized way and to maintain a 1:1 peg across chains. We can skip all that because we are storing the actual assets, rather than the complex locking and generating process defined above. Less complexity and the owner has more control with universal coin storage 
@Cashmaney - I like it! I missed this dev earlier, thank you for bringing it to our attention.