Skip to content

Latest commit

 

History

History
42 lines (26 loc) · 1.88 KB

0000-referral-query-id.md

File metadata and controls

42 lines (26 loc) · 1.88 KB
Raw
  • TEP: 0 (don't change)
  • title: Referral code in Query ID
  • status: Draft
  • type: Contract Interface
  • authors: Denis Subbotin, Oleg Andreev
  • created: 26.12.2023

Summary

This is a proposal to split Query ID in two halves: the referral code and arbitrary app-specific data.

Motivation

Standard way to self-identify apps that initiate transactions makes it easier to operate referral and profit-sharing programs and gather usage statistics in off-chain context.

Guide

Applications and services may self-assign unique identifiers to disambiguate their application from others. We suggest using CRC32 code:

crc32('tonkeeper') = 0x546de4ef
crc32('dedust') = 0xc671412d

In privacy-preserving applications users may expect absence of any referral codes. In such cases apps may offer an option to leave the referral code as all-zeros or use other app’s well-known identifier at random.

Specification

Split 64-bit Query ID in two halves:

  • First 32 bits (high bits) identify the author of the transaction: dapp or wallet that originates the message to the TON network. You SHOULD use CRC32 code of a fully-specified string describing your application.
  • Second 32 bits (low bits) are reserved for arbitrary use: identifying individual queries in smart-contracts, random nonces etc.

Drawbacks

This proposal splits the space of possible identifiers in two equal halves. If one's application needs a longer than 32-bit identifiers for the queries, part of the referral code space must be used.

There is no authentication of the referral code, so this data cannot be trusted: anyone can use anyone else's referral code.

Rationale and alternatives

The suggested proposal is simple and easy to follow, making statistics and referral programs easy to operate.