Build a Leaderless Shielded Bids Auction Reference Implementation for OTC Auction using Shutter Network

[han]

Abstract

We propose building a reference implementation for OTC auction using Shutter Network’s commit-reveal capabilities. This implementation will create a transparent, trustless environment for SAFT and locked token trading, addressing market inefficiencies while maintaining privacy and preventing information asymmetry. The goal is to drive Shutter Network’s adoption across diverse use cases and stakeholders. The system will be production-ready and support full stakeholder integration with Shutter Network’s environment.

Problem Statement

This implementation will serve as a foundation for stakeholders to integrate with and adopt Shutter Network, expanding its ecosystem and demonstrating practical real-world applications.

Current OTC Auction Problem

Propose leveraging Shutter encryption network’s commit-reveal mechanism for SAFT/Locked token OTC trading, creating a trustless trading environment.

Should it adopt it address current market inefficiencies in OTC trading while maintaining privacy and preventing information asymmetry.

the SAFT/Locked token OTC auction typically has three users: a seller, a buyer and a broker.

• The seller is selling some number of tokens for a price they have in mind
• A number of buyers will bid their price (typically there will be some negotiation) and the amount they’re willing to buy
• Brokers usually keep their clients of buyers and sellers and broker the trade in between.

Where Shutter comes into play: First off, all bids can be encrypted. This offers some key advantages:

• It will have bind auction instead of brokers having the advantage of knowing all bids where some clients could potentially change theirs bids to their advantage or collude on bid price

• Better trust setup for sellers as all bids are encrypted and timestamped

• Brokers don’t have to share their clientele with each other but can still prove they provide honest service

• Brokers have information advantage knowing all bids

• Lack of transparency in bid timestamps and order

• Trust between parties could be improved/enhanced

• Brokers must expose client relationships for trade match verification

• No audit trail

Core Features & Mechanisms

1. Encrypted Bidding
   • Timestamp verification for bid ordering
   • Binding auction mechanism
   • All bids encrypted using Shutter Network
2. Trust Architecture
   • Encrypted bids prevent price manipulation
   • Verifiable timestamp system
   • Broker blind-matching capability
3. Privacy Features
   • Bid privacy until reveal phase
   • Verifiable honest service for broker/platform

Task Scope

Phase 0: Business Development & Management

1. Product Management
   • Requirement refinement
   • Stakeholder communication
   • Feature prioritization
2. Business Development
   • Partner outreach/pitching Shutter Network
   • Integration support

Phase 1: Off-chain Implementation

1. Frontend Development
   • Basic web interface
   • User flow implementation
2. Shutter API Integration
   • API integration and testing
   • Encryption/decryption flow setup
3. OTC Trading Logic
   • Bid order creation
   • Buyer/seller order encryption/decryption ( optional based on feedback )
   • Bid encryption/decryption implementation
4. Data Storage Implementation
   • Database schema design
     • Encrypted bids
     • Decrypted Bids
     • Auction Ask
     • Actor IDs
     • Public keys of each actors
   • Data persistence

Phase 2: On-chain Implementation

1. Smart Contract Development
   • On chain attestation via smart contract replacing a database store
   • Timestamp cutoff based on chain mechanism
   • Multiple round auctions to prevent time attack (Optional)
   • Testing
2. Frontend Integration
   • Smart contract interaction
   • Testing and debugging

Success Metrics

1. Technical Metrics
   • Successful bid encryption and decryption
   • Fully functional user workflows
   • Integration with Shutter API production environment
   • Clean, maintainable open-source code
2. Integration Metrics
   • Number of successful integrations
   • Increase the usage of Shutter Network

Grant Request and Budget Breakdown

Total Budget: 5000 USDC + 600,000 SHU

• Phase 0 & 1 (Off-chain Implementation): 3000 USDC
• Phase 2 (On-chain Implementation): 2000 USDC + 600,000 SHU (vesting over 4 months)

Note: The SHU token grant (600,000 SHU) is contingent upon successful business development outcome, defined as at least one (1) platform adopting and integrating the reference implementation. If this adoption milestone is not met, the token grant will be forfeited.

License

Code will be release under MIT license or other license as deemed appropriate by DAO members

[d0z3y]

This sounds interesting, thanks for spending the time pulling it together! I do have some questions:

• If the tokens are locked, how will settlement occur? How do these markets normally ensure settlement - is it based on locking alternative collateral?
• Is the cost estimate accurate? Maybe it would be better to put this out for an RFP?
• The problem mentions stakeholders that will integrate with this. Who are they? What is the strategy for driving integrations?
• There are no hosting costs mentioned for the off chain component. Who will run and maintain this?
• There is no mention of any audit, is it required?
• Is this planned to be revenue generating?

[han]

Hi @d0z3y these are all good questions! Response below:

Revenue sharing & Network usage

This is an attempt to find another use case for Shutter Network. We all witnessed the challenging adoption process for L1/L2 platforms, despite Shutter Network’s proven feasibility on Gnosis. The goal is to find another use case for the commit reveal mechanism that will frequently use Shutter Network.

Should these OTC platforms/brokerages decide to integrate I don’t see why they don’t want to pay SHU to encrypt thier transactions. So it is also in the plan to convince them to pay SHU tokens to use this platform. 100% of transaction fees paid in SHU tokens will be paid to Shutter Network.

Settlement

Settlement will be done by the OTC broker. This is intentional. The goal is to convince brokers to use Shutter Network, not compete with them. By providing a privacy-enhancing tool, we’re offering a solution that improves their existing workflow without disrupting their business model .

Cost Estimation

The development could be open to an RFP process. The current estimation is low compared to other tasks. We’ve worked closely with an existing developer who understands the nuanced requirements. However, any dev house is welcome to provide an alternative estimate but it just might require more communication.

Hosting

No hosting costs are included. Implementation and hosting will be managed by platforms choosing to integrate Shutter Network. This approach removes integration barriers and shifts responsibility to interested adopters.

Stakeholder Engagement

I am currently pitching to a few OTC brokers and trading platforms in my network. No commitments are secured yet. This is why exactly we need to build this reference implementation or you could call it functional PoC. Right now no party has made the commitment to use Shutter Network yet but should it happen some announcements definitely should be made

[han]

Sorry I realised I forgot to answer the question about audit.

So the initial step would be storage all log and trace creating bids, reveal and sharing bids in the database.

Once it become more clear what info message is more useful for auction flow and the data strcuture become stable, It will be implemented in a smart contract