# What is Fetcch? Overview of Fetcch

Fetcch Pull Payment Connectivity Network

Blockchain technology, with its transformative use cases such as cross-border transactions, Instant settlement, ownership of funds, and many more has redefined our understanding of modern transactions. While its capabilities are vast and groundbreaking, it isn't without its shortcomings. Unlike traditional payment systems that seamlessly integrate both push and pull transaction mechanisms for efficiency and convenience, blockchain grapples with the notable absence of pull payments. In contrast, the absence of pull payments in blockchain hampers users from setting up regular bills, creates hurdles for businesses trying to achieve streamlined transactions, and stalls automated transfers, among many such challenges. Additionally, the decentralized payment landscape is fragmented because of the nature of blockchain infrastructures deterring mainstream adoption. Complex wallet addresses, varying from one blockchain to another, have hindered the seamless transfer of assets and led to user confusion. Such limitations have led some to naively deem blockchain as a failed endeavor. Yet, we firmly believe that blockchain is a technology with a transformative potential, which remains untapped due to these constraints. ### What is Fetcch? Fetcch is a pull payments layer that makes blockchain transactions smoother and more intuitive. By enabling wallets and applications to send chain-agnostic transaction requests directly to the user's endpoint, it brings a touch of the ease and simplicity we're used to with traditional online payments. The benefits of this are numerous. Users get a more streamlined payment experience, similar to the familiar Web2 payment gateways and Point of Sale systems. This not only improves the user experience but also has the potential to boost transaction volumes. Fetcch is designed to integrate seamlessly with various platforms, including payment gateways, wallets, exchanges, e-commerce sites, and crypto banking. In an environment where blockchain often appears intricate, Fetcch simplifies transactions for users. We're on a mission to simplify transaction UX for end users. To further this vision, Fetcch introduces Universal Transactional Identities. Instead of users having to navigate a labyrinth of multiple addresses, this feature grants them a unified identity, like "deep\@gnosis" or "mandar\@metamask". This innovation streamlines cross-chain transactions, enhancing the user experience even more. # Overview Instead of the traditional approach in blockchain where the sender initiates the transaction, with Pull Payments, the tables are turned. Imagine you've availed a service and instead of sending the money directly, the service provider sends you a detailed payment request. The receiver sets up this request, pre-filled with all transaction specifics, and dispatches it to the sender’s wallet, functioning much like a straightforward notification.

Pull Payments

When the sender spots this notification in their wallet, they can conveniently open it, review the outlined details, and with a quick confirmation, approve the payment. What’s fascinating is the way the payment is then processed. The system pulls the mentioned amount from the sender’s account, but it’s done with the the sender’s authority. Moreover, the evolving landscape of digital wallets is making this process even slicker. The upcoming auto-approve feature in many wallets promises to streamline this further. Regular or trusted transactions can be set to get approved automatically, minimizing the need for manual checks each time. In simple terms, Pull Payments lets the receiver start the payment process while the sender still has the final approval. This creates a clear and easy way for both sides to handle transactions. * Chains Fetcch's pull payments layer is catered to a wide range of blockchains including major EVM Chains, Solana, Aptos, SUI, Fuel, Near, and several others. # How it works? # Specification The core of pull payments lies in the payment request. This request is essentially a list of transactions approved by the receiver and sent to the sender (or initiator). Let’s understand it like this: Pull payments operate like a digital version of sending a bill. Think of it like receiving an online invoice. The receiver creates an invoice (payment request) detailing the amount for specific items (token transfers). This digital invoice supports various systems, be it EVM or non-EVM blockchains, and can recognize addresses and protocols like ENS, SOL, APT, UNSTOPPABLE, etc. (Powered by Fetcch’s Identity Layer) The sender then gets the invoice, reviews it, and approves the payment. It's a straightforward and efficient way to handle transactions. These transaction Requests can either be simple payments or can also execute a complex multistep transaction. They will be completely blockchain agnostic and enable payment gateways, point-of-sale systems, or any commerce platform to start accepting guaranteed crypto payments with very little integration. It can also be used by dApps to execute transactions without directly connecting to a wallet, so any dApp that can only be used for a single transaction can reduce the complexity of connecting to a wallet. As transaction requests are transmitted over HTTPS, we have a 100% guarantee that all network packets will be received by the end-user, we can also improve the current mobile wallets to a desktop dApp experience. dApps can directly send transaction requests to a mobile-based wallet, it can execute that transaction and dApps will be notified that the transaction is completed, so there is no overhead of a websocket connection dropping off. # How is it stored? Let's delve into the storage and structure of transaction requests to understand how they're stored and verified: **1. Structure of Transaction Request** Transaction requests can reside in one of three states: * **Fulfilled:** This state is achieved once a user has successfully paid a transaction request. * **Pending:** This is the state when a transaction request is freshly created but hasn't been processed by the user. * **Expired:** A transaction request transitions to this state when the current time surpasses its set expiration time. **2. Storage Mechanism** For ensuring security and traceability: * Every version undergoes a `SHA-256` hashing process. * If the second version of a transaction request is absent, a placeholder `null` SHA-256 hash (e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855) steps in. * These hashes are then funneled into a merkle root generator function. The resulting merkle root is diligently stored on the target blockchain. This setup empowers users to authenticate whether their off-chain transaction requests are legitimate. **3. Verification Process** For payment platforms like wallets, there are a couple of options: * **Trust Offchain Data:** Platforms can choose to rely on offchain data, but they should be fully aware of the associated risks. * **Verify Offchain Data:** If platforms opt for verification: * They can solicit a proof from the offchain server. * Using the acquired proof, they can invoke the `verifyMerkleProof` function on their provider's contract. * By submitting the proof alongside the owner's address, they'll receive a straightforward `true` or `false` response, denoting the validity of the transaction request.
Note: Change transaction requests to pull payments In essence, this framework ensures both the integrity and traceability of transaction requests, offering users and platforms a secure and transparent experience. # Pull Payments Flow Here's a breakdown of the sequential actions taken by the receiver and sender to facilitate a smooth transaction: ### **Receiver's Workflow**
1. **Transaction List Compilation**: * Generates a list encompassing detailed transactions. * **Specification**: Primarily token transfers leveraging ERC (or corresponding token standards) protocols. 2. **Payment Request Configuration**: * Instigates a `PaymentRequest` object derived from the transaction list. * Incorporates transaction metadata such as token type, quantity, and intended beneficiary. * Uses a private key to digitally sign the request, confirming its authenticity. 3. **Engagement with the Fetcch Network**: * Transmits the `PaymentRequest` to the Fetcch Network using a designated API endpoint. * **Consensus Phase**: The network conducts a swift consensus check to prevent any unauthorized actions. * **Data Storage**: Initially, the request is archived in a local distributed repository. * **On-Chain Integration**: Post verification, the request is bundled with similar ones and inscribed onto the target blockchain, ensuring efficient fee management. 4. **Notification to Sender**: * Sender (Initiator) is notified of the payment request through one or more of the channels, listed below * **Push Mechanisms**: Utilizing Google/Apple Notification Services. * **Server Intercommunication**: Deploying webhooks for seamless server-to-server relay. * **Synchronous Communication**: Through websockets ensuring real-time notification dispatch. ### Sender’s Workflow
1. **Payment Request** : * Captures the incoming alert regarding the payment request through designated notification channels. * Extracts and deciphers the `PaymentRequest` payload to assimilate the transaction prerequisites. 2. **Authentication and Authorization**: * Confirms the details and signs the transactions on the blockchain. 3. **Transaction Confirmation**: * Upon successful validation and recording of the transaction on the blockchain, a transaction hash is generated as a unique identifier. * Updates the payment request with the generated transaction hash * **Integrity Verification**: Fetcch's backend compares the transaction hash with the original `PaymentRequest` to validate the asset exchange and to preclude any unauthorized alterations. 4. **Notification Dispatch to Receiver**: * Receiver is notified of the completion of the payment request through one or more of the channels, listed below * **Push Mechanisms**: Utilizing Google/Apple Notification Services. * **Server Intercommunication**: Deploying webhooks for seamless server-to-server relay. * **Synchronous Communication**: Through websockets ensuring real-time notification dispatch. # Security # Storage What are the security guarantees for storage Pull payments are stored on Fetcch network and then to settled to respective blockchains ### Encryption All of the pull payments are only visible to the concerned parties (sender and receiver), wallets/applications can read the payment request only if they have the permission from the concerned user itself. We use HMAC based encryption algorithm for encrypting important data with a secret key. Private pull payments are going to be live on Fetcch network in coming months, this requests will be fulfilled through some kind of a stealth address. ### L1 Accepted There is a slot where data is accepted on L2 but is yet to be settled on an L1, data till then is considered as **L2 Accepted** and after it is settled on L1 then it is considered as **L1 Accepted** If a data is L2 Accepted then there are more chances of it being L1 Accepted than being dropped, it depends on the blockchain that we are settling on, some blockchains take more time than others. Also some blockchains are more costly than others, we have a lot of gas optimizations done for these blockchains to lower the costs # Cross Chain Pull payments are chain agnostic, User A can request token on Chain A to User B and User B can decide to pay them token on Chain B, now its upto the Fetcch settlement layer to settle those tokens fastly and securely There are some security points that we need to care about ### Bridge Security Fetcch Settlement Layer is live on some EVM blockchains but for other blockchains we fallback to other bridges like Wormhole, Connext etc Security of cross chain transactions depends on the bridge that we are using for that particular payment. You can check security for Fetcch Settlement Layer here # Use Pull Payments
The Pull Payments system is revolutionizing how we think of blockchain based transactions, pivoting from the conventional 'push' to a more controlled 'pull' mechanism. This setup brings forth a range of applications, not just limited to direct payments. Let's explore some of the key ways in which Pull Payments can be harnessed: ### **Direct Payments (Pay)** 1. **User-centric Control**: * Unlike traditional methods where one pushes money, Pull Payments allow the receiver to send a request to the payer. This places the user at the center of the transaction, giving them more control and making the process more intuitive. 2. **Enhanced Security**: * Each payment request is digitally signed, ensuring the authenticity of the request. This reduces the risk of fraudulent requests and provides an additional layer of security to the transaction. ### **Other Integrations** 1. **Subscription Services**: * Pull Payments can be seamlessly integrated into subscription-based platforms. Instead of users manually renewing, service providers can send periodic payment requests, ensuring uninterrupted service and easier management for businesses. 2. **Invoicing and B2B Transactions**: * Businesses can use Pull Payments for sending digital invoices, streamlining the B2B transaction process. This digital transformation not only speeds up transactions but also minimizes errors inherent in manual processes. 3. **Cross-chain Transactions**: * With the inherent support for cross-chain interoperability, Pull Payments can facilitate transactions across multiple blockchains. This feature is especially crucial in a decentralized ecosystem where assets are spread across different chains. 4. **E-Commerce Integrations**: * Online retailers can incorporate Pull Payments for checkout processes. When a customer is ready to checkout, instead of inputting payment details, they can simply approve a payment request sent by the retailer. By integrating Pull Payments, businesses and individuals alike can reap the benefits of a more streamlined, secure, and efficient transaction system. As the payments landscape continues to evolve, such innovations play a pivotal role in shaping the future of online transactions. # Overview The decentralized payment landscape has been plagued by various challenges, deterring mainstream adoption. Complex wallet addresses, varying from one blockchain to another, have hindered the seamless transfer of assets and led to user confusion. Additionally, cross-chain transactions have been difficult, risky, and required users to navigate unfamiliar processes.
Addressing this, Fetcch's Identity Layer introduces the concept of Universal Transactional Identities (UTI). This system consolidates diverse blockchain addresses into a unified format, denoted as `username@wallet`. With UTIs, a user might have a singular identity such as "deep\@gnosis" or "mandar\@metamask", facilitating consistent interactions across various blockchains. This UTI framework doesn't merely simplify the user experience but is underpinned by robust technical architecture, optimizing decentralized transactions and setting a new standard in interoperable digital identities. **Chains Supported** Fetcch's indentity layer is catered to a wide range of blockchains including major EVM Chains, Solana, Aptos, SUI, Fuel, Near, and several others. # How it works? # Specifications Fetcch's Identity Layer offers a Unified Address System that merges numerous blockchain addresses into a singular, chain-agnostic identity. By using easily recognizable identifiers like "satyam\@metamask", users can effortlessly represent their identities across multiple platforms like Ethereum, Polygon, Solana, and BSC. With a staunch commitment to universal protocols, Fetcch Identities seamlessly integrate with the DID (Decentralized Identifier) standard, ensuring broad recognition and interactivity. Above all, emphasizing user-centricity, Fetcch guarantees full ownership through its non-custodial framework. *Let’s take a closer look on the Idenitifiers:* #### **Identity Structure** Fetcch Identity's construct revolves around three core components: * **Identifier**: Essentially, it's the unique tag picked by users, like "satyam" in "satyam\@metamask". * **Delimiter**: Represented by "@", it acts as a bridge between the identifier and the provider. * **Provider**: Refers to the specific blockchain or platform linked with the user, say "metamask" in the provided example. #### **Address Framework** With Fetcch Identity, users can tie multiple addresses, segmented into: * **Default**: The go-to address for all activities triggered by the user. * **Secondary**: Steps in as a backup, ensuring actions don't hit a roadblock when the default isn't usable. #### **Identity Configuration** Alongside the address setup, Fetcch Identity boasts an 'Identity Config', enhancing user flexibility: * **Transaction Paths**: Users can set preferred transaction routes. Take "forcedSameChainPayment" - if turned on, it sidesteps bridge routes, tapping into secondary addresses when needed. * **Token Choice**: For cross-chain transactions, the default pick is a stablecoin. Yet, users can tweak this based on their leanings. In essence, these technical specs of Fetcch Identity are engineered for simplicity and efficiency, ensuring users navigate without a hitch. # How is it stored? Fetcch Identities are stored using an efficient onchain storage system that ensures verifiability, interoperability, and minimal gas costs. This approach enables Fetcch to cover the gas expenses for users, contributing to a seamless experience. ### Storage Structure
1. **Versioned Format**: Identities are stored in a version-based format, such as v1, v2, etc. This allows tracking of historical changes to identities, ensuring changes adhere to protocol rules. 2. **Content Identifier (CID)**: The metadata of each identity is stored using a CID from IPFS or Arweave. This CID provides a reference to the offchain location of the identity's metadata. 3. **Default Address**: The default address associated with the identity is stored as bytes. 4. **Secondary Addresses**: An array of secondary addresses related to the identity is stored as bytes. 5. **Timestamp**: The timestamp indicating when the identity was created. 6. **Merkle Root**: For each identity version, a Merkle root is generated. This root serves multiple purposes: 1. It enables verification of whether an address is part of an identity by generating Merkle proofs. 2. It verifies the validity of identities obtained from offchain sources. ### Storage Process 1. **User Interaction**: Wallets initiate either a POST or PATCH request to `/v1/identity` to create or modify identities. 2. **Private Data Encryption**: Fetcch encrypts private data within the identity and stores all data on decentralized storage platforms like IPFS or Arweave. 3. **Proof Generation**: Necessary proofs for the identity, requests, and address books are generated. These proofs contribute to the overall integrity and security of the identity. 4. **Data Sequencing**: All required data, including metadata, proofs, and roots, are organized into a sequence, ensuring coherent and structured storage. 5. **Regular Onchain Updates**: At regular intervals of approximately 10 minutes, Fetcch initiates onchain transactions to update each identity present in the sequence. This keeps the onchain identity information up to date and aligned with offchain changes. This meticulous storage mechanism ensures that Fetcch Identities maintain a high degree of security, verifiability, and interoperability while effectively managing gas costs for users. For further technical details, you can refer to the associated resources. # Identity Flow Fetcch Identity Flow simplifies interactions for both DApps and wallets (providers) and users. For providers, it offers an uncomplicated pathway for setup, issuance, and management, while users experience a user-friendly journey for selection, registration, and utilization. Let's delve into these streamlined components for a clearer understanding. ### **Provider Workflow** 1. **Seamless Registration:** * Providers with verified wallets/dApps seamlessly onboard onto Fetcch. * Upon verification, they are granted a unique, alphanumeric namespace. 2. **Tailored Configuration:** * Providers customize their namespace configurations, including API keys and owner addresses. * They craft a user-friendly frontend interface for efficient identity management. 3. **Empowered Identity Issuance:** * Providers issue branded identities within their designated namespaces (e.g., username\@namespace). * This process ensures distinct and recognizable user identities. 4. **Effortless Identity Management:** * Providers effortlessly manage issued identities through chronologically validated owner signatures. * This guarantees the integrity and security of each identity's interactions. ### **User Workflow** 1. **Informed Provider Selection:** * Users make educated choices by evaluating providers based on reputation, chain compatibility, and rich feature sets. 2. **User-centric Identity Registration:** * Users request personalized identities from their chosen provider. * The provider promptly issues bespoke identities nested under its unique namespace. 3. **Seamless Identity Engagement:** * Users confidently engage with diverse identities from multiple providers. * The distinct namespace prefix simplifies the differentiation of identities, enhancing user experience. # Security # Storage ### Where are identities settled? Identities are settled on respective blockchain(s) based on its default blockchain, this is to ensure that we can verify signatures onchain and never rely on any trusted offchain party to verify those signatures. ### How to verify resolved identity? A resolved identity can be verified by generating a merkle proof for that identity through the same offchain provider and then verifying that merkle proof on Fetcch's smart contract against signed merkle root for that identity # Use Fetcch Identity Fetcch’s idenitiy layer offers several practical benefits offering users simplified processes, increased control, and enhanced convenience: 1. **Simplified Cross-Chain Management:** Users can seamlessly manage their identities across different blockchain networks, eliminating the complexities associated with handling multiple identities. This ensures a more unified and streamlined experience. 2. **User-Centric Identity Control:** Empowering users to autonomously oversee their transactions, interactions, and engagements across various wallets and applications. This approach reduces reliance on external entities, fostering greater ownership of digital identities. 3. **Personalized Wallet Identity:** The integration of preferred usernames with wallet branding creates unique and recognizable identities. This customization enables effortless use across various platforms and services. 4. **Platform Compatibility:** This solution's compatibility with different wallets and decentralized applications ensures smooth and seamless operations across various platforms. Users can engage effortlessly within the Web3 ecosystem. 5. **Simplified Payment Processes:** The Unified Transaction Identifier (UTI) feature simplifies payment processes. This simplification streamlines the sending and receiving of payment requests, thereby enhancing the overall usability of digital interactions. This solution simplifies cross-chain management, empowers user-centric identity control, facilitates personalized wallet identities, ensures platform compatibility, and enhances payment processes, all contributing to a more seamless and user-friendly experience within the blockchain landscape. # Address Books # Overview Users frequently engage in transactions with individuals within their social circles, including family members, friends, and colleagues. When users find themselves making frequent payments to the same recipients over a short period, it becomes a practical choice to store these contacts for easy access. By maintaining an address book, users can swiftly retrieve these commonly-used contacts during transactions, leading to a reduction in unnecessary clicks and enhancing the overall transaction process.
Research findings highlight the positive impact of integrating address books within payment apps. This inclusion eliminates the need for users to engage in the cumbersome process of copying, pasting, or memorizing intricate identifiers. As a result, users experience a smoother transaction process, leading to an increase in transaction volumes. This boost in user engagement and activity contributes to the growth and vibrancy of the platform. ### **Emulating Success: Web2 Address Book Implementation** The success of Web2 payment apps like Cashapp, Venom, and UPI apps is attributed, in part, to their integration of address books directly within their platforms. This strategic decision has significantly enhanced the user experience, allowing users to manage their frequently-used contacts effortlessly. However, while Web3 wallets and payment apps have adopted similar address book functionalities, the decentralized nature of the Web3 landscape presents unique challenges. ### **How can we implement it in web3?** Fetcch introduces web3 address book. Fetcch transforms the way users manage their contacts. Users gain the ability to categorize and organize their address books based on different relationships or groups. For instance, users can create sub-address books tailored to specific contexts, improving organization and user experience. We take a step forward by offering a safe way for users to share their address books with other identities or wallets. This unique feature encourages better coordination and supports joint financial efforts among users. Security is of utmost importance; Fetcch secures user address books through encryption and stores them on reliable platforms like IPFS and Arweave. The merkle root of these address books, anchored on the blockchain, gives users a way to verify their data's integrity. ### **How does this works?** We enable wallets to access global address books for a user. There can be multiple sub address books which a user can manage. So, users can manage their address books more effectively. A example, satyam\@metamask wants to segregate addresses in the address book based on categories like home, work, friends etc, they can easily create sub-address books inside their wallet which will use Fetcch APIs. Each Fetcch Identity or any other address or DID can have multiple sub-address books, like one for work, another for personal etc. This will help them segregate addresses/identities based on their relation with them. If someone wants to share their address book(s) with other identity or address, they can invite that identity/address to that particular address book, this invite can be scoped to read, read-write, so if the receiver identity accepts the request, they will now be able to see that address book All of the address books of a user are encrypted and stored on storage solutions like IPFS/Arweave and their merkle root onchain to easily verify if those books are tampered with or not. ### **Usecases** Address Book has usecases in wallet, it will improve payment experience in wallet by a lot, also various dApps can use it for identifying a user's frequently interacted address, only if user allowed it to. ### **Integration** Integration is very easy, we have APIs and SDKs that simplify the development process, checkout [here](https://docs.fetcch.xyz/how-to-integrate/quickstart), also join our discord for any assistance # Storage This is designed keeping verifiability and security at mind. We are using Merkel Trees to store address books securely onchain which focuses on verifiability as Merkel trees are know for being verifiable by generating Merkel Proofs Storage structure looks something like this:
The above diagram is for a single address book and a list of Merkel root and respective IPFS/Arweave content identifiers will be stored on-chain with respect to an address or identity. Address books can be fetched from any off-chain and can be verified against Merkel root stored on-chain, this gives the ability to users for verifying the truthness of the books themselves and not depend on any third party. Even, applications like wallets and conversation apps can verify received address books themselves on behalf of the user and make sure that user is not served incorrect data. **Who updates the Merkel root?** Owner / Users can themselves update the Merkel root of their address book but right now as we are still experimenting with our systems, only whitelisted address can update the Merkel root and we will slowly open up the access for users. **Encryption** Encryption is very important in address books as users don't want to make their contact list publicly available. We use asymmetric cryptography to encrypt address books before storing them on public storage solutions like IPFS and Blockchain # Quickstart Fetcch API contains various modules, each module has different API route and schema * Identity Module * Resolve any identity from any DID protocol like .eth, .sol, .apt, @metamask, @kana etc * Issue identity in a namespace like @metamask, @kana etc * Transaction Request Module * Request any type of transaction to any address, or DID * Websocket APIs for notifying when a request is created for an address or DID * Synchronized Address Book Module * Create books for any wallet * Share books to different wallet ### API Keys To acquire API Keys, contact @hardik\_fetcch on telegram, we will guide you through entire process and make sure you have a delight while building on Fetcch ### How to authenticate using API Keys? Add your API Key as `secret-key` in headers of every request, and request will be authenticated ### Reading Data All data is user owned and can only be accessed by the user itself by providing a signature. # SDK Quickstart Install & Instantiate Fetcch SDK We currently do have a Typescript SDK, soon we will have android & iOS SDKs ready #### Install SDK ```bash // using npm npm i @fetcch/api // using yarn yarn add @fetcch/api // using pnpm pnpm i @fetcch/api ``` #### Instantiate SDK ```typescript import Fetcch from "@fetcch/api" const fetcch = new Fetcch("SECRET_KEY") ``` # Blockchain Fetcch assigns each blockchain a custom id, as we support more chains other than EVM
BlockchainID
Ethereum (EVM)1
Polygon (EVM)2
Binance Smart Chain (EVM)3
Avalanche C-Chain (EVM)4
Optimism (EVM)5
Arbitrium (EVM)6
Solana (Solana)7
Aptos (Aptos)8
Manta Pacific (EVM) 9
# Guides # Authentication User signature is required to fetch data ### Arrange Data First, you need to arrange data which will be used to generate message ```json { "owner": "string" // can be address or DID } ``` ### Generate a message {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/authentication/generate-message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} ### Generate Access Tokens Sign the above message using the appropriate address and arrange data in below format ```json { "owner": "string", "signature": "string", "timestamp": "number" } ``` `signature` is the obtained by signing the above generated message and timestamp is also given in the response of [this](#generate-a-message) `timestamp` can't be older than 5 minutes {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/authentication" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} ### Authenticate To authenticate, just include the received `accessToken` in `headers` as `authorization` in format `bearer ${accessToken}` # Identity # How to resolve identity? {% hint style="info" %} Check [Quickstart](/how-to-integrate/quickstart) for authenticating with API Key {% endhint %} ### Using API {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity" method="get" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} ### Using SDK For [Quickstart](/how-to-integrate/sdk-quickstart) #### Call Resolve Function ```typescript const id = await fetcch.identity.resolve("satyam@metamask") // CAN ALSO DO const id = await fetcch.identity.resolve("satyam.eth") // OR const id = await fetcch.identity.resolve("satyam.sol") // EVEN OR const id = await fetcch.identity.resolve("satyam.nft") ``` # How to create identity? Create Identity under your own namespace Process of creating an identity ### Arrange Identity Arrange identity in the format ```json { "id": "string", "identifier": "string", "provider": "string", "default": { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, "secondary": [ { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean } ] } ``` ### Generate Message Using the above arranged identity, generate a message using the below endpoint and sign it using `default` address by following [guide for respective chains](/how-to-integrate/guides/utility) {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity/generate-message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} After generating message, you need to sign `message` using appropriate functions for respective chains, check our guide for each blockchain [here](/how-to-integrate/guides/utility) ### Create Identity After signing the message, add the generated signature in the [arranged identity](#arrange-identity), at `currentSignature` Now, data should look something like this ```json { "id": "string", "identifier": "string", "provider": "string", "default": { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, "secondary": [ { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean } ], "currentSignature": "string" } ``` Call **Create Identity** API #### Important Note If `default` chain is `APTOS`, then while calling this API, swap `default` address with public key of the same address, so that we can easily verify signatures {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} Identity should now be created, if faced with any error, check our [troubleshooting guide](/how-to-integrate/api-reference/troubleshooting-errors) or ask in our discord ### Resolve Identity {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity" method="get" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} # How to update identity? Process of updating an identity ### Arrange Identity Arrange identity in the format * If want to remove addresses from secondary, do not add them in the list * If want to add new addresses in secondary, add them in secondary list * If want to keep some addresses in secondary, then keep them in the data ```json { "id": "string", "identifier": "string", "provider": "string", "default": { "address": "address", "chain": number, "isContract": boolean }, "secondary": [ { "address": "address", "chain": number, "isContract": boolean }, { "address": "address", "chain": number, "isContract": boolean } ] } ``` ### Generate Message Using the above arranged identity, generate a message using the below endpoint and sign it using `default` address by following [guide for respective chains](/how-to-integrate/guides/utility) {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity/generate-message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} After generating message, you need to sign `message` using appropriate functions for respective chains, check our guide for each blockchain [here](/how-to-integrate/guides/utility) There are 2 signatures needed while updating identity * `currentSignature` - Will be signed by current (new) `default` address * `previousSignature` - Will be signed by previous (old) `default` address, only if `default` is updated * If `default` isn't updated, you need to use same signature for both `currentSignature` and `previousSignature` ### Update Identity After signing the message, add the generated signature in the [arranged identity](#arrange-identity), at `currentSignature` and `previousSignature` respectively Now, data should look something like this ```json { "id": "string", "identifier": "string", "provider": "string", "default": { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, "secondary": [ { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean } ], "currentSignature": "string", "previousSignature": "string" } ``` Call **Update Identity** API #### Important Note * If `default` chain is `APTOS`, then while calling this API, swap `default` address with public key of the same address, so that we can easily verify signatures * If `default` is changing in this request, then send previous `default` address's public key in `extraData: { publicKey: "" }` * For example * `satyam@martian` has `APTOS` has default chain * In this request, we are updating it to `EVM` * Signed message using `EVM` address will be in `currentSignature` * Signed message using `APTOS` address will be in `previousSignature` * To verify `previousSignature`, we need to have `publicKey` of the `APTOS` address, which we will send in `extraData` So now, data will look something like this ```json { "id": "string", "identifier": "string", "provider": "string", "default": { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, "secondary": [ { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean }, { "address": "address", "chain": number, "isMultisig": boolean, "isSmartContractWallet": boolean } ], "currentSignature": "string", "previousSignature": "string", "extraData": { "publicKey": "string" } } ``` {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity" method="patch" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} Identity should now be created, if faced with any error, check our [troubleshooting guide](/how-to-integrate/api-reference/troubleshooting-errors) or ask in our discord ### Resolve Identity {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/identity" method="get" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} # Transaction Requests # How to get transaction requests? Process of getting transaction requests ### Using API {% openapi src="/files/xHkDlRpIfj4yuAtwlvDR" path="/transaction-request" method="get" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2F7U1PRlaamdcCS67VTbzB%2Fopenapi.yml?alt=media\&token=b98daf06-4442-4ccf-8b08-76e32833a666) {% endopenapi %} ### Using SDK For [Quickstart](/how-to-integrate/sdk-quickstart) #### Call Resolve Function ```typescript const request = await fetcch.request.get({ id: 1 }) // OR with payer const request = await fetcch.request.get({ payer: "satyam@metamask" }) // OR with address const request = await fetcch.request.get({ payer: "0x123..." }) // OR with receiver const request = await fetcch.request.get({ receiver: "Epf12..." }) ``` ### Webhooks & Websocket Coming soon... # How to create transaction request? Process of creating a transaction request ### Arrange Transaction Request Arrange Transaction Requests in the format ```json { "receiver": "string", "payer": "string", //optional "actions": [ { "type": "PAYMENT", "data": { "token": "string", "chain": number, "receiver": "string", "amount": { "amount": "string" // in lowest denominator, "currency": "CRYPTO" } } } ], "message": "string", "label": "string" } ``` ### Generate Message {% openapi src="/files/xHkDlRpIfj4yuAtwlvDR" path="/transaction-request/generate-message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2F7U1PRlaamdcCS67VTbzB%2Fopenapi.yml?alt=media\&token=b98daf06-4442-4ccf-8b08-76e32833a666) {% endopenapi %} Sign the above-generated message using a private key for the associated EOA or Smart Wallet ### Create Transaction Request {% openapi src="/files/xHkDlRpIfj4yuAtwlvDR" path="/transaction-request" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2F7U1PRlaamdcCS67VTbzB%2Fopenapi.yml?alt=media\&token=b98daf06-4442-4ccf-8b08-76e32833a666) {% endopenapi %} ### Using SDK For [Quickstart](/how-to-integrate/sdk-quickstart) #### Creating Transaction Request ```typescript const arrangedData = {} // arranged request data const request = await fetcch.request.create(arrangedData) ``` # How to build transaction? Build Same or Cross chain transactions ### Arrange Data Arrange data in this format ```json { "receiver": "string", "transactionRequestId": number, // either transactionRequestId or receiver "payerConfig": { "payer": "string", "address": "string", "token": "string", "chain": number, "amount": number } } ``` ### Call Build API {% openapi src="/files/xHkDlRpIfj4yuAtwlvDR" path="/payment/build-transaction" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2F7U1PRlaamdcCS67VTbzB%2Fopenapi.yml?alt=media\&token=b98daf06-4442-4ccf-8b08-76e32833a666) {% endopenapi %} ## Dry Build Transaction This API will not return the actual built transaction, but will return `from`, `to` addresses and respective blockchains, so developers can build their own transaction based on the resolved addresses {% openapi src="/files/xHkDlRpIfj4yuAtwlvDR" path="/payment/build-transaction" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2F7U1PRlaamdcCS67VTbzB%2Fopenapi.yml?alt=media\&token=b98daf06-4442-4ccf-8b08-76e32833a666) {% endopenapi %} # How to resolve transaction request? Resolve a payment request Once transaction is done onchain, you need to update transaction hash for that transaction request Soon, it will be an automated process, as our workers will be able to find and match transactions for transaction requests ### Arrange Data Arrange transaction request in the format ```json { "id": number, "fromChain": number, "fromToken": "string", "transactionHash": "string", "executed": boolean } ``` ### Using API {% openapi src="/files/UROrVfbSfv6qtqrSAT5m" path="/transaction-request" method="patch" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2F5jy8PImdbktraNLuOiII%2Fopenapi.yml?alt=media\&token=c6477667-70c8-448b-ae95-decfbd594edb) {% endopenapi %} ### Using SDK For [Quickstart](/how-to-integrate/sdk-quickstart) ```typescript const updatedData = {} const request = await fetcch.request.resolve(updatedData) ``` # Address Books # How to get address books? Process of fetching address books Address books can fetched based on 2 parameters * `id` - can be `satyam@metamask`, `satyam.eth` etc * `name` (optional) - can be name of the particular address books ### Call API {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books" method="get" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} # How to create address books? Process of creating address book ### Arrange Data Arrange address book data in the format ```json { "name": "string" "addresses": { "address": "address", "chainType": "EVM" | "APTOS" | "SOLANA", "name": "string" }[], "walletIds": { "walletId": "string", "name": "string" }, "ownerId": "string" } ``` ### Generate & Sign Message Generate message using this API and above data {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books/message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} Sign the above message by following signature guidelines mentioned [here](/how-to-integrate/guides/utility/how-to-sign-messages) according to the chain you are using ### Call Create Address Book API {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} # How to share address book? Sharing address books has never been easy ### Arrange Data Arrange data in the format ```json { "toId": "string" "book": number "access": "READ" | "READWRITE" } ``` ### Generate & Sign Message Call this API to get the message {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books/request/message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} Sign the above message by following signature guidelines mentioned [here](/how-to-integrate/guides/utility/how-to-sign-messages) according to the chain you are using ### Call API {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books/request" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} ### Websockets & Webhooks Coming soon... # How to accept address book request? Accepting request to address book ### Arrange Data Arrange data in the format ```json { "id": number, // request id } ``` ### Generate & Sign Message Call this API to get the message {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books/request/message" method="post" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} Sign the above message by following signature guidelines mentioned [here](/how-to-integrate/guides/utility/how-to-sign-messages) according to the chain you are using ### Call API {% openapi src="/files/xjcYh3sZCi10eHJaNA7T" path="/address-books/request" method="patch" %} [openapi.yml](https://2219691098-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxaHazojZlIts4pidXQC6%2Fuploads%2FfnFyuZwzFVn93GBdO4kv%2Fopenapi.yml?alt=media\&token=7e1414fc-c6b1-4244-9549-9bb061a79cc5) {% endopenapi %} # Utility # How to sign messages? # EVM * We are using `ethers.js` for this particular example * Use `signer.signMessage` message from `Signer` class ```tsx const message = await generateMessage() const signer = new ethers.Wallet() const signature = await signer.signMessage(message) // OR const signature = await signer.signMessage(Buffer.from(message)) ``` # Solana * We are using `tweetnacl` and `bs58` for this particular example ```tsx import nacl from "tweetnacl" const message = await generateMessage() const keypair = Keypair.generate() // use user's wallet const signature = nacl.sign.detached(Buffer.from(message), keypair.secretKey) ``` {% hint style="info" %} Wallets have exposed functions for [signing message](https://github.com/solana-labs/wallet-adapter/blob/master/FAQ.md#how-can-i-sign-and-verify-messages) {% endhint %} # Aptos ## Aptos Signature Guide * We are using `tweetnacl` for this particular example ```tsx import nacl from "tweetnacl" const secretKey = "" const publicKey = "" // without prefix 0x const generatedMessage = await generateMessage() const message = `APTOS\nmessage: {generatedMessage.message}\nnonce: {generatedMessage.nonce}` const signature = nacl.sign.detached(Buffer.from(message), Buffer.from(message, 'hex')) ``` {% hint style="info" %} APTOS has a standard for signing message, there will be `APTOS` before message and `nonce` after message, `nonce` is provided by the generateMessage, use that as a nonce {% endhint %} # EIP-6492 Compatible Signatures Fetcch supports EIP-6492 for pre-deployed smart accounts We now support EIP-6492 for verifying signatures of pre-deployed smart accounts, as a dev, you have to generate a signature that is EIP-6492 compliant, which will be sent as a normal signature to APIs Below are the steps to make your normal signature EIP-6492 compliant ### Steps 1. Sign the message from that pre-deployed smart account's owner EOA 2. We will need few data along with signature for signature generation 1. **Deploy Calldata** - Transaction data for deploying the smart account 2. **Factory Address** - Smart account factory contract 3. **Magic Suffix** - `6492649264926492649264926492649264926492649264926492649264926492` 3. Use `AbiCoder` in `ethers` for encoding all of the data 4. ``` const signature = coder.encode(['address', 'bytes', 'bytes'], [ ``` ```typescript factoryAddress, calldata, signature ]) + magicSuffix ``` 5. Use the generate signature in Fetcch API to authenticate tasks ### Reference * [EIP-6492](https://eips.ethereum.org/EIPS/eip-6492) # How to generate & verify proofs for identity? Coming soon...
# API Reference # Troubleshooting Errors Error commands in Fetcch API | Command | Description | Troubleshooting | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | IncompleteArgs | Required arguments not found in URL or Body parameter | Check request body if method is POST/PATCH or URL param if request method is GET | | WrongArgs | Wrong arguments are found in URL or body parameter | Remove those arg from URL or body parameters | | ObjectAlreadyExists | Object already exists in the network | Try changing arguments | | ObjectNotFound | Object does not exists in the network | Try creating that object first, or chaning arguments | | ObjectNotCreated | Object cannot be created in the network | Change arguments, there must be an error in the arguments | | ObjectNotUpdated | Object cannot be updated in the network | Change arguments, there must be an error in the arguments | | SecretKeyNotInHeaders | Secret key doesn't exist in the headers | add `secret-key` in headers | | WrongSecretKey | using invalid `secret-key` | use valid `secret-key` | | RequestObjectWrong | address book request is invalid | use correct format and values for address book request | | ProviderNotOnChain | provider doesn't exists onchain | contact us if provider not onchain | | NotAbleToParseTx | not able to parse transaction receipt | retry transaction or contact us | | IdAndIdentifierNotSame | `id` and `identifier` are not same | use same `id` and `identifier` | | IdAndProviderNotSame | `provider` and provider in `id` is not same | use same `provider` and in `id` | | ExtraDataIsRequired | `extraData` is required for updating or creating identity if default address is APTOS | add `extaData` | | AddressDoesNotExistsOnIdentity | address doesn't exist on a specified identity | use different address | | AddressNotExists | address doesn't exist on any identity | use different address | | CannotGenerateMerkleTree | cannot generate merkle tree for a specified identity | use different identity or contact us | | CannotGenerateMerkleProof | cannot generate merkle proof for specified identity | use correct address to generate proof against | | IdentityObjectWrong | identity object has invalid values or missing required values | use valid values and keys in identity object | | InvalidAddress | address is invalid for a blockchain | use valid address | | ChainNotSupported | chain is not supported yet by Fetcch | contact us to support that chain | | InvalidSignature | signature is invalid for a blockchain | use our guides to generate valid signatures | | InvalidIdentifier | `identifier` is invalid | follow fetcch guidelines for generating identifier | | NonceNotExist | `nonce` doesn't exist in a generated message for identity | regenerate message | | InvalidENS | ENS is invalid | follow ENS guidelines | | ENSDoesntExist | ENS doesn't exist | recheck if ENS exists | | PayerNotSame | payer is not same as mentioned in transaction request | resend correct payer | | CannotBuildTransaction | some issue while building transaction | retry again few minutes or contact us | | AggregatorNotWorking | aggregator is not working | retry again few minutes or contact us | | RouteNotSupported | `fromChain` to `toChain` route isn't supported | contact us and we will add that route on priority | | Aptos + \* | Aptos related error | follow correct aptos docs | | FromChainNotEVM | `fromChain` is not EVM | change `fromChain` to an EVM compaible chain | | FromChainAndToChainAreSame | `fromChain` and `toChain` are same for cross chain transactions | change `fromChain` or `toChain` | | FromChainNotSolana | `fromChain` is not solana | change `fromChain` to Solana | | Solana + \* | Solana related error | follow correct solana docs | | EVM + \* | EVM related error | follow correct evm docs | | InvalidId | `id` is invalid | follow fetcch guidelines for `id` | | ProviderSecretKeyWrong | `secret-key` and `provider` aren't same | change `secret-key` or `provider` | | ProviderAndIdentityDelimiterNotSame | `id` 's delimiter and `provider.delimiter` are different | both delimiter should be same | | RateLimited | rate limited because can't have more than 5 unresolved transaction request between a pair of address or id | try again after 30mins or after resolving some transaction requests | | InvalidTokenAddress | token address is invalid | use correct token address | | TransactionAmountNotEqual | transaction amount is not equal to transaction request amount | use correct transaction | | WrongTransaction | transaction is invalid used for resolving transaction request | use correct transaction | | CannotUploadToIpfs | cannot upload to ipfs | try again after few minutes or contact us | # @fetcch/resolve-names Open source SDK for resolving DIDs to addresses Resolve various DIDs like `.eth`, `.sol`, `.arb`, `.bnb`, `.apt`, `@kana` and many more using a single SDK ### Installation Install `@fetcch/resolve-names` with package manager ```bash NPM npm install @fetcch/resolve-names YARN yarn add @fetcch/resolve-names PNPM pnpm i @fetcch/resolve-names ``` ### Usage #### Resolve Name ```typescript import { resolve } from "@fetcch/resolve-names" const resolver = new Resolve({ eth: "ETHEREUM_RPC_URL", pol: "POLYGON_RPC_URL", ... sol: "SOLANA_RPC_URL" }) const id = await resolver.resolve("satyam@kana") // OR const id = await resolver.resolve("satyam.eth") ``` ### Important Links * [Github](https://github.com/FetcchX/resolve-names) # FAQs **What is the timeline to integrate Fetcch?** Depends on what module you are integrating * Identity - 3-6 Days * Transaction Requests - 1 Week * Synchronized Address Books - 1 Week **Which programming languages do we support?** Our API is language agnostic, so as a developer you can use any programming language, but we do have SDKs in **Typescript** **Is Fetcch decentralized?** Fetcch is a sufficiently decentralized protocol, we have all of the data stored on blockchains, but more decentralization is always better, keep an eye out :eyes: **How is Fetcch different than other identity and payment solutions?** * A single identity can represent users across all of the blockchains