EDS - Add BurnMintFactory support - #855
Conversation
Invalid CODEOWNERS file detected - @friedemannf.1 error(s) were found in the CODEOWNERS file. See the workflow summary and PR annotations for more information. |
| } | ||
|
|
||
| resp, err := f.daRegistryClient.GetBurnMintFactoryWithResponse(ctx, daRegistry.GetBurnMintFactoryRequest{ | ||
| InstrumentId: daRegistry.InstrumentId{ |
There was a problem hiding this comment.
/burn-mint-factory endpoint - currently returns issuer-credentials: [] because it doesn't accept a holder parameter so had to resort to /mint/v0/request.
So once we start supporting issuerRequirements, holderRequirements how do we plan on getting those values?
There was a problem hiding this comment.
IIUC the plan is to add full support for credentials to the BurnMintFactory endpoint eventually, this will not stay that way.
Until then, the urlRequests type should provide a workaround
|
|
||
| // TODO: for backward-compatibility, use poolOwner as receiver if not specified | ||
| if receiver == "" { | ||
| receiver = f.poolOwner |
There was a problem hiding this comment.
Wondering about the poolOwner fallback here. If I'm following right, receiver/sender aren't the mint destination (that's set on-ledger from the CCIP message), they tell DA's backend whose blocklist shards / credentials to resolve. So if receiver is empty and we fall back to poolOwner, the on-ledger checkBlockList/credential checks would validate poolOwner instead of the actual receiver meaning a blocklisted or uncredentialed receiver passes because poolOwner is clean.
Wouldn't that defeat the whole point of the field once blocklist/holderRequirements are enabled?
There was a problem hiding this comment.
Yeah, this is really just to keep the current behavior in case a client isn't updated yet to pass the additional fields.
On-chain that isn't how the blocklist/credentials works though - the registry will always check the actual holder of the minted output. I.e. if we make the API request for poolOwner and then try to mint to the actual receiver, the worst that could happen is that the mint will fail - it will not just pass because of missing/wrong blocklist shards/credentials being provided.
| Outputs: []daRegistry.MintOutput{ | ||
| { | ||
| // TODO: Amount should be taken from message.TokenTransfer, but would have to be properly scaled by the TP's decimals | ||
| Amount: "1.0", |
There was a problem hiding this comment.
are the disclosed contracts/contexts ever amount dependent? tried calling with various amount value but got the same result
There was a problem hiding this comment.
It seems they are not, but the field is there and it might be used some time in the future
# Conflicts: # go.mod # go.sum
2 participants
This adds proper support for getting disclosures for a token pool's factory from an URL backed by either the Token Standard or the DA Registry Backend API.
TransferFactoryandBurnMintFactoryinto a singleFactorysetting, now that they have equal fieldsurlRequestsfactory type for the BurnMint factory that uses the DA Registry/mint/requestand/burn/requestinstead of/burn-mint-factoryurlRequeststype uses two different endpointssenderandreceiverfields to the OpenAPI spec wherever neededsenderandreceiverparties when querying the disclosures, as the backend has to return the correct values in its choice context, depending on these parties (e.g. blocklist, or preapprovals)senderandreceiverin all requests to EDS