Trusted Forwarder: An Attribution Engine With Protection Designed For On-Chain Protocols

Limit Break Dev
Limit Break
Published in
4 min readFeb 5, 2024

Trusted Forwarder was built to solve two problems for Payment Processor: trade attribution for marketplaces and the ability to block hostile apps from piggy-backing on the open Payment Processor protocol in order to vampire attack creators or the protocol itself. However, the Trusted Forwarder truly stands on its own as a creator-friendly product worthy of its own post, as it can solve these problems for any open, on-chain protocol. The use of Trusted Forwarders to get attribution for dApps leveraging protocols is straight forward. The remainder of this article will focus on how Trusted Forwarder can protect a protocol team from failure.

Case Study

To demonstrate how Trusted Forwarder can be applied to protect any open, on-chain protocol, we will do a case study on a fictitious protocol team.

Scenario —The Rise and Fall of SpaceDock Protocol

A young project team launches the SpaceDock protocol and application. SpaceDock allows users to:

  • Deposit and lock up coins and receive a transferrable claim NFT
  • Claim their funds and an allocation of free mystery NFTs reflecting the value of the deposit and length of the lockup period
  • Share an additional allocation of free mystery NFTs with the dApp in appreciation of building and maintaining SpaceDock

SpaceDock builds a user-friendly dApp to interface with their on-chain protocol. Everyone loves the free mystery NFTs. The floor price of the reward NFTs skyrockets and the SpaceDock team begins to earn a stockpile of valuable NFTs. The future looks bright!

Recognizing an opportunity to make money, a newly formed international business called Sharpen builds a front-end application on top of the SpaceDock protocol in order to farm mystery NFTs. Sharpen operates in a jurisdiction lacking legal restrictions on crypto. By layering in additional incentives, Sharpen vampire attacks the SpaceDock team, which is powerless to react due to legal and regulatory constraints. A once promising Web3 company goes out of business while Sharpen capitalizes on SpaceDock’s unprotected protocol and thrives.

How SpaceDock Could Have Protected Themselves

The SpaceDock team’s business failed because their protocol was too open and was easily vampire attacked by other dApps. The SpaceDock team should have blocked deposits and withdrawals that did not originate from their own Trusted Forwarder instance. Had they done so, they could have required an additional App Signer implemented by their dApp to authorize all deposits and withdrawals and ensure that only their dApp could be used to interact with their protocol. The architecture is shown below.

Securing Protocols Using Trusted Forwarders With dApp Co-Signing

User Retention

On-chain protocols are publicly viewable and typically verified for public view. Copycat apps may arise to try to steal users from your own protocols. Building a strong mechanism to retain users in the presence of copycat protocols is critical. Each product is a bit different, so rather than advise on the specific approach to retaining users, we’ll explain how copycats are discouraged for Creator Token Standards and Payment Processor protocols.

By default creator tokens protect NFT creators from hostile exchange protocols by blocking all other protocols besides Payment Processor. Payment Processor is highly aligned with the needs of the vast majority of creators, so there is little incentive to whitelist any other exchange protocol. By design, Payment Processor is meant to allow the creator to build a completely private exchange if they wish to control the entire experience, or select specific distribution partners, or leave trading of their work to general purpose public exchanges. The choice is entirely up to them. By restricting hostile exchanges and empowering creators to oversee the marketplace experience for their collectors, the Creator Token Standards and Payment Processor includes robust defenses against copycats, as the majority of the creator community would have to be sold on the idea of actively whitelisting the other protocol.

Further Reading

Check out Limit Break’s Github or erc721c.com for developer and creator guides to Trusted Forwarder.

Limit Break’s Creator Advanced Protection Suite (Creator Token Standards, Payment Processor (V1 & V2), Trusted Forwarder) and related services and protocols (collectively “Tools”) are made available on an as-is basis and Limit Break disclaims all representations and warranties, express or implied, in connection with use of these Tools. Users bear all responsibility for ensuring the proper and legal use of these Tools and should exercise best judgement and caution where appropriate when deploying them. Limit Break does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised or offered by a third party using the Tools, and will not be a party to or in any way be responsible for monitoring any transaction between users and any third-party providers of products or services deploying the Tools. Use of the Tools is subject to the licenses under which such Tools are made available in all respects.

--

--

Limit Break Dev
Limit Break

Limit Break devs live by a code: be the best and ship, ship, ship!