The problem endorse.fun (Ethereum Endorsement Service) solves

endorse.fun solves several problems in the Web3 social space:

• Finding, recognizing & rewarding Web3 users and contributors: endorse.fun makes it easy to see, find, recognize, and reward meaningful Web3 contributors by encouraging users to endorse and tip each other.
• Fragmentation in Social Proof: Current social platforms and professional networks are fragmented and often not interoperable, making it difficult to accumulate and display social proof across platforms.
• Applications need multiple ways of verifying, identifying, and efficiently rewarding their users for their contributions. → endorse.fun is another solution that gives applications a way to validate web3 contributors.
• Simplifying process for authentic and meaningful tips within the decentralized ecosystems.
• Low Visibility for New Entrants: New entities and contributors often struggle to gain visibility and establish credibility in a saturated market without an established network.
• Bootstrapping a system where individuals (or groups or projects) can earn money and gain a reputation, and establishing a dynamic money flow between participants.

Challenges we ran into

We encountered two challenges worth mentioning.

• The first challenge is related to the Airstack API, which we use for Social profile discovery (ENS, Farcaster, Lens). The API gives all addresses of a specific social identity that was searched for. This means, it also gives the custodial Farcaster user address and non-evm addresses connected to the Farcaster account (Solana). One of our requirements here was, to limit the endorsements and donations to addresses owned by the user (non-custodial). To achieve this, we are resolving the user address in the following order:
  1. We use the ENS address if available.
  2. We use the Lens address if available.
  3. We filter out all non-evm and Farcaster custodial addresses and use the first connected address that is still left. The reasoning behind this is, that we assume the user is in possession of all the accounts he has connected to his Farcaster account.
• The second challenge is related to performance, UX and API key security. To optimize the load times, reduce server load and secure our external services API keys, we used React server components inside Next.js together with caching fetch query requests. Established social profiles do not change often, so we use a revalidation time of 1 day for these requests. For querying our subgraphs on The Graph Network, we use a revalidation time of a 1 minute, so we don't serve old/stale data to the users. We will adjust these values as we gather more data points and user feedback.