-
Notifications
You must be signed in to change notification settings - Fork 7
feat: add horizon types to tap_graph #270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
19f140c to
f323ed7
Compare
Signed-off-by: Gustavo Inacio <[email protected]>
f323ed7 to
b7bd0da
Compare
Pull Request Test Coverage Report for Build 13020749107Details
💛 - Coveralls |
| sol! { | ||
| /// Holds information needed for promise of payment signed with ECDSA | ||
| /// | ||
| /// We use camelCase for field names to match the Ethereum ABI encoding | ||
| #[derive(Debug, Serialize, Deserialize, Eq, PartialEq)] | ||
| struct ReceiptAggregateVoucher { | ||
| /// Unique allocation id this RAV belongs to | ||
| address allocationId; | ||
| // The address of the payer the RAV was issued by | ||
| address payer; | ||
| // The address of the data service the RAV was issued to | ||
| address dataService; | ||
| // The address of the service provider the RAV was issued to | ||
| address serviceProvider; | ||
| // The RAV timestamp, indicating the latest TAP Receipt in the RAV | ||
| uint64 timestampNs; | ||
| // Total amount owed to the service provider since the beginning of the | ||
| // payer-service provider relationship, including all debt that is already paid for. | ||
| uint128 valueAggregate; | ||
| // Arbitrary metadata to extend functionality if a data service requires it | ||
| bytes metadata; | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gusinacio could you just explain why this needs to be abi encoded, presumably because this is interacting with a contract. Would be great to be able to make the link here. Can also do it in a subsequent PR if you wanna explain here quickly 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definition of encodeType.
https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator
https://docs.rs/alloy/latest/alloy/sol_types/macro.sol.html
sol macro generates the encodeType for EIP712, it doesn't use serde and at the time, there was no way to "rename camelCase" like we do in serde
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like it still doesn't have that alloy-rs/core#570
v2feature flag (unstable for now)For now, handling both receipts is delegated to the lib user but serialization might be added in a future PR.