Content
@
0 reply
0 recast
0 reaction
horsefacts
@horsefacts.eth
The great and powerful @ilemi has suggested (strongly, several times) that we tack on cast hash to the frame tx calldata attribution suffix. This adds 20 bytes of extra calldata, but would identify the cast, author, frame, and client that originated a tx. What do you think? Two considerations: Adding more calldata costs a negligible amount more on L2s, a meaningful amount more on L1 Using a cast hash requires joining in other attributes offchain to work out author/frame/client
17 replies
3 recasts
54 reactions
horsefacts
@horsefacts.eth
I think this is probably a better idea than the original attribution format, but am interested to hear from both frame builders and data wizards!
2 replies
1 recast
16 reactions
ilemi
@ilemi
YESSS ITS HAPPENING 🔥🔥🔥🔥
0 reply
0 recast
1 reaction
Tony D’Addeo
@deodad
iirc, the current attribution can tell you what client the user completed the transaction from attributing to a cast is also useful but does lose this original meaning
1 reply
0 recast
2 reactions
Corbin Page 👑🎩
@corbin.eth
Support it for /degengame. 👍 We prefer to track metrics onchain where possible vs. tracking on the backend.
0 reply
0 recast
3 reactions
Vladyslav Dalechyn
@dalechyn.eth
the first thought I have that this can be used for onchain FID gateways. the second thought I have that this can be easily manipulated, just add the bytes you want to "fake" at the end of calldata and here you go. can we trust this attribution? the next thought I have that we can make this trusted by having App Clients to sign the attribution data along with the data itself. this would result in 32 bytes (signature suffix) + 20 bytes (attritubion suffix). Since every App Client has a FID, they also have the private key to sign attribution with. Their corresponding addresses derived from the public key can be stored onchain (in a separate contract?) and derived from the "client" stated in the attribution field. so that contracts can: 1. Get the [pos:pos+52] bytes of calldata; 2. Get latest (4?) bytes to retrieve client FID; 3. Get client signer address; 4. Check that ecrecover of signature at[pos:pos+32] matches with signer; 5. Get [pos+32, pos+52] of trusted attribution data.
1 reply
0 recast
2 reactions
Sanjay
@sanjay
I like it
0 reply
0 recast
1 reaction
Paul Cowgill
@paulcowgill
yes, please!
1 reply
0 recast
1 reaction
Ivan 🎭
@soquger
Just tipped you +100 🔥 FIRE. Check your balance.
0 reply
0 recast
0 reaction
L3MBDA
@l3mbda
seems to me cast hash’s the secret sauce for frame to adventures!
0 reply
0 recast
0 reaction
hussain8792🎭
@hussain8792
+100 🔥 FIRE tip dispatched. Do check your balance.
0 reply
0 recast
0 reaction
Watson 66
@harr
Thanks 😊 done ✅ All friends Always smile okay done ✅ so nice very good and all friends Happy Tuesday everyone have done ✅
0 reply
0 recast
0 reaction
Sanwal
@sanwal12
Wow
0 reply
0 recast
0 reaction
Nikita Truzhenikov | 🐹
@truzhenikov
Hey there! I think @ilemi's suggestion to add cast hash to the frame tx calldata attribution suffix sounds pretty interesting and could be really helpful in identifying the origin of a transaction. However, I can see how adding more calldata might impact costs differently on L1 and L2. It's definitely something to consider and weigh the pros and cons of!
0 reply
0 recast
0 reaction
Sayyam🎩👒🔵🎩
@sayyamu
Super
0 reply
0 recast
0 reaction
Naeem Ul Hassan 🎩🎩👑🎩
@naeemulhassan
🌹🌷💐Behind your progress is your hard work, which is a beacon for us🌎🌍🌏
0 reply
0 recast
0 reaction
