Rarible

TLDR: Design a JS SDK for Rarible protocol

This is a proposal to begin work on the architecture, design, and dev experience for a JS SDK of the entire Rarible Protocol Flow. This interface will be used by developers to quickly integrate the protocol into their apps, while abstracting most of the complex logic that can happen under the hood.

In one week we’ll thoroughly digest existing resources and documentation, work along side other ecosystem developers, prepare the interface for the protocol according to the feedback received, and specify all the endpoints that would be created on a subsequent engagement.

Problem / Opportunity

The Rarible Protocol currently does not have an official SDK, so by having this dev tool ready it will be easier for dApp devs to interact with Rarible protocol.

dOrg DAO is specialized in building Web3 integrations and tooling, and various of our stake holders are interested in building on top of the Rarible. By creating this SDK, high-caliber projects will be able to tap into the protocol to develop their specific NFT usecases.

Funding Milestones and Payments

The following is an estimate based on the scope of work as currently understood and can change upon revision by mutual consent of the parties.

Estimated Timeframe: 1 week

Deliverables: Research & Interface (~50 hours)

• Architecture: Initial interface for the protocol, covering the entire Rarible Protocol Flow, which covers the following: Creating ERC721/1155 Asset Metadata and Calling the Mint function, Asset Discovery, Creating a sell order, Accepting a buyer/bid order, Order Discovery, Matching Order, Updating/Canceling an order, API Reference
• Work with other ecosystem developers to best polish the end-user’s experience
• Describe the development roadmap for a subsequent engagement to develop the SDK.

We can think of this interface as the set of specifications that describe the inputs, outputs, and behaviors of all the functional elements of the Protocol Flow. Therefore, the engagement involves architecture, conceptualization, and analysis so that the protocol can be abstracted into something robust that you can easily interact with. For illustration purposes, if we were to design an interface for a microwave, we’d deliver the specification of each of the “buttons” to set cooking time, start, stop, set mode(heat, defrost), etc. Consequently, the details of how the microwave increases the temperature of your food, turns on the lightbulb when you start it, or rotates the microwave dish would not be part of the interface itself, and they’d be developed on future engagements considering the proposed roadmap. Once the SDK fully built, its implementation will look like the two code snippets we’ve posted above on this thread. The snippet code below is an accurate representation of what a part of the deliverable interface would look like. type Metadata = { name: string; description: string; image: Blob; external: string; animation: Blob; attributes: { key: string; trait_type: string; value: string; }[]; };

type Address = string;

type AccountPercentage = { account: Address; value: number; };

interface RaribleSDK { constructor(config: { ethereum: EthereumProvider; api: APIProvider; subgraph: SubgraphProvider; }): void;

mint( to: Address, metadata: Metadata, creators: AccountPercentage[], royalties: AccountPercentage, signatures: string[] ): LazyMintResult;

mint( to: Address, metadata: Metadata, creators: AccountPercentage[], royalties: AccountPercentage, signatures: string[], lazy: false ): MintResult; }

Finally, for comparison of what to expect as a tangible interface deliverable for this first phase, here is OpenSea’s SDK Interface: https://github.com/ProjectOpenSea/opensea-js/blob/84a4e811e020e98945749157075514047079bc72/lib/seaport.d.ts#L6

Payment terms

6K USD equivalent. 20% will be paid upon delivery in RARI on xDAI, the remaining will be paid in DAI via the escrow service on xDAI. The escrow payment will be made using RaidGuild’s new SmartInvoice.

dOrg LLC will be a service provider of the Rarible DAO and will report taxes accordingly. Legally compliant invoices will be issued accordingly before funds get distributed to our team.

• Registered Legal Entity: dOrg LLC
• Registered Address: 76 St. Paul St, PO Box 369, Burlington, VT 05402
• Tax ID: 84-2930500

Use of funds

Funds will be used to pay experienced developers and builders from dOrg DAO (https://dorg.tech). RARI token will be used to pay builders directly involved with the project, and 10% of the total amount will be airdropped to dOrg DAO Reputation Holders.

Team Members

dOrg is a Web3 Developer DAO that has worked with top projects like Balancer, The Graph, Aragon, Badger, Gnosis, ParaSwap, and more. The project will initially be executed by the following dOrg members. However, dOrg is designed to flexibly bring on the right expertise at the right time, so other developers will likely get involved over time.

Roberto Henríquez (Media#2944) - PM

Carlos Febres (carlosfebres#8099) - Full Stack

Ben Walker (benefacto19#4368) - Web3 Integrations

Accountability & Quality Assurance

dOrg utilizes the following processes to keep all parties accountable in the course of execution:

• Project Manager is responsible for keeping the project on track and should be interfaced through for any issues regarding scope, roadmap, risk, payments, etc.
• Weekly Syncs to share updates, discuss blockers, and realign priorities.
• Discord Channel for ongoing updates and support
• Github Project Board for continuous deliverable tracking
• Feedback Threads to asynchronously collect community feedback as we build

In order to ensure that all deliverables satisfy project requirements without issue, dOrg:

• Carefully assigns proven builders with the relevant expertise
• Utilizes modern testing frameworks and testnet lifecycle simulation
• Performs internal code reviews before handoff and other key milestones Despite these efforts, dOrg is not able guarantee that all code will be perfect. Web3 is still an emerging field with a high level of risk and complexity. dOrg is not responsible for any bugs or technical failures that may result from its services. The Client is responsible for consulting with the relevant security experts before taking high risk systems live.

Why should Rarible DAO fund this?

What is the benefit to RARI token holders? How will this help grow the ecosystem, or bring value to them? We believe that, in Web3, improvements to the developer experience drive ecosystem growth. With more teams able to build fast and prototype on top of the protocol, we’ll be able to see even wider adoption and innovation. We need an SDK; By abstracting the complex logic of the protocol (ExchangeV2, IPFS pinning, API calls, Test environments, etc) devs will be able build on top of a simple, intuitive interface. We will support ecosystem cross-pollination and distribute protocol stakeholdership to a group of awesome Web3 Specialists by airdropping 10% of the RARI token received to the 50+ members of the dOrg DAO.