You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new claim method adds the following arguments:
requestID - The same (dropId, requestID) pair cannot be claimed more than once. This replaces the previous protection on the contract, which prevented the same (claimId, msg.sender) pair from claiming more than once. The reason we have done this is so that a single drop can be used to distribute tokens to the same user multiple times. This is important for gaming use cases such as XP grants.
signer - Dropper v0.2.0 uses ownership of Terminus tokens by signers to determine if signatures are valid proofs that a certain caller can claim a given drop. Since any signer holding the Terminus token specific to a drop can claim as part of that drop, the caller needs to specify which signer signed their authorization as part of the claim method. In Dropper v0.1.0, there was a single signer for each drop at any given time, which is why this argument was not needed in the claim method for that implementation.
In general, with Dropper v0.2.0 we want the contract to be the source of truth about:
Who can authorize claimants to receive tokens from drops (at the API level).
Whether a drop is active or not.
In the present version of the API, we use a secondary (Terminus address, Terminus tokenId) pair to determine who can post authorizations to the API. In the version for Dropper v0.2.0 we will use the same (Terminus address, Terminus tokenId) pair that is used to designate authorized signers on the smart contract.
We will not store any information about whether Dropper v0.2.0 drops are active or not at the API level. That behavior will depend only on the state of the smart contract (unlike the current Dropper v0.1.0 API).
authorized_calls
My preference would be to add a general AuthorizedCall model which would correspond to the following response schema on the Dropper v0.2.0 equivalent of /drops/batch:
There would be an enum on valid contract_type values, with each value corresponding to the appropriate authorization check based on the on-chain state of the contract.
This implies a model similar to this for AuthorizedCall (i.e. the authorized_calls relation in the database):
We may want to make a joint index on some or all of the indexed columns above (e.g. (chain_id, contract_address, contract_type) could be a joint index).
Authentication on POST endpoint
The API endpoint where administrators POST authorizations for drops will check the Authorization header of each request for a message signed by an account which bears the same Terminus token that acts as the authorization token for the drop with the given dropId.
The text was updated successfully, but these errors were encountered:
Authentication should be based on Moonstream accounts. For each authorized_calls row, we should store a Moonstream user ID representing the authorizer. This is the only approach that generalizes to arbitrary contract calls. Eventually, we will add a subscription check when a user POSTs an authorization to the API.
We should probably put contract information in a separate table (shitty working name: authorized_call_contracts) so that we don't duplicate, (chain_id, contract_address, contract_type) a crazy amount in the authorized_calls table.
New contract type: raw. Empty method. method_args will contain "calldata". Arbitrary contract calls.
Currently, the
/drops
endpoints on Engine API only support Dropper v0.1.0.Now that Dropper v0.2.0 is on the
main
branch of this repository, we need to support signatures for the new contract on the API, as well.Changes to database and API
Current schemas
The Dropper API is consumed mainly via the
/drops/batch
endpoint, which returns responses in this format:The data is stored in the following Postgres relations (represented here by SQLAlchemy models):
How Dropper v0.2.0 differs from Dropper v0.1.0
The biggest change from v0.1.0 to v0.2.0 is in the signatures of
claimMessageHash
andclaim
.The new
claim
ABI is:The new
claim
method adds the following arguments:requestID
- The same(dropId, requestID)
pair cannot be claimed more than once. This replaces the previous protection on the contract, which prevented the same(claimId, msg.sender)
pair from claiming more than once. The reason we have done this is so that a single drop can be used to distribute tokens to the same user multiple times. This is important for gaming use cases such as XP grants.signer
- Dropper v0.2.0 uses ownership of Terminus tokens by signers to determine if signatures are valid proofs that a certain caller can claim a given drop. Since any signer holding the Terminus token specific to a drop can claim as part of that drop, the caller needs to specify which signer signed their authorization as part of theclaim
method. In Dropper v0.1.0, there was a single signer for each drop at any given time, which is why this argument was not needed in theclaim
method for that implementation.In general, with Dropper v0.2.0 we want the contract to be the source of truth about:
In the present version of the API, we use a secondary
(Terminus address, Terminus tokenId)
pair to determine who can post authorizations to the API. In the version for Dropper v0.2.0 we will use the same(Terminus address, Terminus tokenId)
pair that is used to designate authorized signers on the smart contract.We will not store any information about whether Dropper v0.2.0 drops are active or not at the API level. That behavior will depend only on the state of the smart contract (unlike the current Dropper v0.1.0 API).
authorized_calls
My preference would be to add a general
AuthorizedCall
model which would correspond to the following response schema on the Dropper v0.2.0 equivalent of/drops/batch
:There would be an enum on valid
contract_type
values, with each value corresponding to the appropriate authorization check based on the on-chain state of the contract.This implies a model similar to this for
AuthorizedCall
(i.e. theauthorized_calls
relation in the database):We may want to make a joint index on some or all of the indexed columns above (e.g.
(chain_id, contract_address, contract_type)
could be a joint index).Authentication on POST endpoint
The API endpoint where administrators POST authorizations for drops will check the
Authorization
header of each request for a message signed by an account which bears the same Terminus token that acts as the authorization token for the drop with the givendropId
.The text was updated successfully, but these errors were encountered: