Payment construction endpoint #2702

paweljakubas · 2021-06-10T12:16:05Z

Issue Number

Overview

POST transactions/construct in swagger
Api.Types reflecting things added in swagger
add Api skeleton
unit tests for Api.Types, Malformed
extend Transaction interface by adding mkUnsignedTransaction
fill in implementation of Cardano.Api.Server and Cardano-Wallet function implementing 'payments' functionality
prepare first integration testing

Comments

paweljakubas · 2021-06-10T16:52:46Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+    , withdrawal :: !(Maybe ApiWithdrawalPostData)
+    , metadata :: !(Maybe (ApiT TxMetadata))
+    , mint :: !(Maybe (ApiT W.TokenMap))
+    , delegation :: ![ApiMultiDelegationAction]


@Anviking does it make sense? see ApiMultiDelegationAction - Natural will stand for soft index of stake key. Thanks to that we could in one tx realize several join/leave pool actions. Maybe it could help with portfolio recreation, reduce needed roundtrips, etc.

I think [ApiMultiDelegationAction] as a raw/manual/low-level kind of multi-delegation api would be really nice. Joining (ApiT PoolId) Natural makes sense to me.

But instead of Leaving (ApiT PoolId), we should presumably have Leaving Natural. We don't have to specify a pool id when we de-register a stake key, but we do need to know which stake key we want to deregister.

And I think we currently use the terminology Join and Quit, so why not stick to it?

(I just realised I didn't plan for the DelegationState to validate (several) user-provided multi-delegation actions, but it would be nice to support, and I don't see how it could be problematic.)

But it does mean that, as said, the delegation actions need to be validated by the DelegationState eventually.

And for now, I guess you would have to start with only supporting key 0 or maybe even a single action, when implementing it.

thanks for the look. Now I have :

data ApiMultiDelegationAction = Joining (ApiT PoolId) Natural | Leaving Natural

rvl

Looks great @paweljakubas

rvl · 2021-06-24T07:04:42Z

lib/core/src/Cardano/Wallet/Api/Link.hs

+    (notSupported "Byron")
+    (notSupported "Shared")


Perhaps add a TODO: ADP-909 comment or something - These wallet types should be supported in the final version.

rvl · 2021-06-24T07:10:21Z

lib/core/src/Cardano/Wallet/Api/Server.hs

+    let toAddressAmount (ApiPaymentAddresses content) =
+            addressAmountToTxOut <$> content
+        toAddressAmount (ApiPaymentAll _) = undefined -- this will be tackled when migration is supported


Let's make sure our app doesn't implode when the user finds an implemented feature.
Can we use HTTP 501 instead of undefined or error, wherever possible?

Suggested change

let toAddressAmount (ApiPaymentAddresses content) =

addressAmountToTxOut <$> content

toAddressAmount (ApiPaymentAll _) = undefined -- this will be tackled when migration is supported

let toAddressAmount (ApiPaymentAddresses content) = pure (addressAmountToTxOut <$> content)

toAddressAmount (ApiPaymentAll _) = liftE ErrTemporarilyDisabled -- TODO: this will be tackled when migration is supported

rvl · 2021-06-24T07:11:22Z

lib/core/src/Cardano/Wallet/Api/Server.hs

+            { txWithdrawal = wdrl
+            , txMetadata = md
+            , txTimeToLive = ttl
+            --, txDelegationAction -- this will be tackled when delegations are supported


Suggested change

--, txDelegationAction -- this will be tackled when delegations are supported

, txDelegationAction = Nothing -- TODO: ADP-909 this will be tackled when delegations are supported

rvl · 2021-06-24T07:22:15Z

lib/core/src/Cardano/Wallet/Api/Server.hs

+        pure (mkApiCoinSelection [] Nothing md sel', fee, blob)
+
+    let txSerialized = ApiSerialisedTransaction (ApiBytesT $ convertToBase Base64 blob)
+    pure $ ApiConstructTransaction txSerialized apiSelection (Quantity $ fromIntegral fee)


I think it would be nicer if there were a separate:

mkApiConstructTransaction :: sel -> fee -> Either ErrMkTx ApiConstructTransaction

Currently W.constructUnsignedTransaction is getting the reward account XPrv, but only the XPub is necessary for the TxBody, right?

indeed, in the end XPub is needed.

rvl · 2021-06-24T07:24:36Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+    , withdrawal :: !(Maybe ApiWithdrawalPostData)
+    , metadata :: !(Maybe (ApiT TxMetadata))
+    , mint :: !(Maybe (ApiT W.TokenMap))
+    , delegations :: !(Maybe [ApiMultiDelegationAction])


I forget, why did we have Maybe [ApiMultiDelegationAction] here?
Was there a semantic difference between Nothing and Just []?

It is reasonable to use delegations: Maybe ... as it can be optional on Api level, one can omit "delegations" field.. I will use Maybe (NonEmpty ApiMultiDelegationAction) though

Aside from arguably looking a bit strange, wouldn't Maybe (NonEmpty ApiMultiDelegationAction) forbid "delegations" = [], potentially making it more difficult for folks to write API clients?

Could we not have delegations :: [ApiMultiDelegationAction], but have a custom JSON parser defaulting to [] if the key is not present?

... if we even need to allow it to be omitted?

rvl · 2021-06-24T07:34:29Z

lib/core/src/Cardano/Wallet/Transaction.hs

+    , mkUnsignedTransaction
+        :: AnyCardanoEra
+            -- Era for which the transaction should be created.
+        -> XPrv


I think only an XPub is needed here, right?

indeed, used XPub rather than XPrv

rvl · 2021-06-24T07:36:29Z

lib/shelley/src/Cardano/Wallet/Shelley/Transaction.hs

+    -> (Maybe Cardano.TxMetadata, [Cardano.Certificate])
+    -> SlotNo
+    -- ^ Slot at which the transaction will expire.
+    -> XPrv


Suggested change

-> XPrv

-> RewardAccount

rvl · 2021-06-24T07:38:21Z

specifications/api/swagger.yaml

@@ -1006,6 +1022,14 @@ x-transactionOutputs: &transactionOutputs
      amount: *amount
      assets: *walletAssets

+x-transactionNoAmountOutputs: &transactionNoAmountOutputs


I don't this extra declaration should be necessary.
It's just an array of addresses.

so it is used here :

2686 ApiPaymentDestination: &ApiPaymentDestination 2687 oneOf: 2688 - title: outputs with specified amounts 2689 <<: *transactionOutputs 2690 - title: outputs without amounts 2691 <<: *transactionNoAmountOutputs

and in contrast to transactionOutputs it does not include amount and assets as we want to use it in migration. So how to capture migration output here?

rvl · 2021-06-24T07:41:42Z

specifications/api/swagger.yaml

+  type: object
+  required:
+    - action
+    - stake_key_index
+  properties:
+    action:
+      type: string
+      enum: ["quit", "join"]
+    pool: *stakePoolId
+    stake_key_index: *derivationSegment


What do you think of this way? I like it more.

Suggested change

type: object

required:

- action

- stake_key_index

properties:

action:

type: string

enum: ["quit", "join"]

pool: *stakePoolId

stake_key_index: *derivationSegment

oneOf:

- type: object

required:

- join

properties:

join:

type: object

required:

- pool

- stake_key_index

properties:

pool: *stakePoolId

stake_key_index: *derivationSegment

- type: object

required:

- quit

properties:

quit:

type: object

required:

- stake_key_index

properties:

stake_key_index: *derivationSegment

I agree it is better. Adopted

rvl · 2021-06-24T07:44:58Z

specifications/api/swagger.yaml

+      required:
+        - invalid_before
+        - invalid_hereafter


We would want the Haskell validity bound type to stay the same, but in JSON, the bounds should be optional, with a missing key meaning "unspecified".

so we have at this moment :

2693 ApiConstructTransactionData: &ApiConstructTransactionData 2694 type: object 2695 required: 2696 - passphrase 2697 properties: 2698 passphrase: 2699 <<: *lenientPassphrase 2700 description: The wallet's master passphrase. 2701 payments: *ApiPaymentDestination 2702 withdrawal: *transactionWithdrawalRequestSelf 2703 metadata: *transactionMetadata 2704 mint: *transactionMint 2705 delegations: *transactionDelegations 2706 validity_interval: *ApiValidityInterval

so the idea was to sneak optionality by making validity_interval optional, but make ApiValidityInterval well defined. kinda the same as for ApiPaymentDestination - the same idea...Once again I do not have strong opinion about this, could be either way, but maybe it would be ok to be consistent..

For the JSON side, we want an omitted field to mean unspecified bound.

piotr-iohk · 2021-06-28T08:21:55Z

lib/core-integration/src/Test/Integration/Scenario/API/Shelley/TransactionsNew.hs

+    it "TRANS_NEW_CREATE_01x - Single Output Transaction" $ \ctx -> runResourceT $ do
+        let initialAmt = 3*minUTxOValue
+        wa <- fixtureWalletWith @n ctx [initialAmt]
+        wb <- fixtureWalletWith @n ctx [initialAmt]


This could be emptyWallet I guess.

piotr-iohk · 2021-06-28T08:30:28Z

specifications/api/swagger.yaml

+    post:
+      operationId: postTransactionConstruct
+      tags: ["Transactions"]
+      summary: Create


Suggested change

summary: Create

summary: Construct

?

piotr-iohk · 2021-06-28T08:54:38Z

Currently in the API we have only passphrase being required payload parameter.
I guess we want also one of payments or delegations to be required?

EDIT: Do we need passphrase after all at the payment construction step as signing will be done in subsequent step?

rvl

Nice work. I still have a few comments though, and have also pushed some minor changes.

rvl · 2021-06-30T12:50:43Z

lib/core/src/Cardano/Wallet.hs

    , selectionToUnsignedTx
    , signTransaction
+    , constructUnsignedTransaction


I think we can just call this constructTransaction

rvl · 2021-06-30T12:59:09Z

lib/core/src/Cardano/Wallet.hs

+constructUnsignedTransaction ctx wid mkRwdAcct pwd txCtx sel =
+    db & \DBLayer{..} -> do
+    era <- liftIO $ currentNodeEra nl
+    withRootKey @_ @s ctx wid pwd ErrConstructTxWithRootKey $ \xprv scheme -> do


If we aren't signing anything then we shouldn't need the wallet root key.
We should be able to get rewardAcct from the database using readRewardAccount.

rvl · 2021-06-30T13:03:17Z

lib/core/src/Cardano/Wallet/Api/Client.hs

@@ -323,6 +331,7 @@ byronTransactionClient =
        , postExternalTransaction = _postExternalTransaction
        , deleteTransaction = _deleteTransaction
        , getTransaction = _getTransaction
+        , constructTransaction = error "TODO should be supported in the final version of Transaction Workflow."


Suggested change

, constructTransaction = error "TODO should be supported in the final version of Transaction Workflow."

, constructTransaction = error "TODO ADP-909 implement new transaction API for all wallet types."

rvl · 2021-06-30T13:03:45Z

lib/core/src/Cardano/Wallet/Api/Link.hs

@@ -633,6 +634,21 @@ getTransaction w t = discriminate @style
    tid = ApiTxId (t ^. typed @(ApiT (Hash "Tx")))
    mkURL mk = mk wid tid

+createUnsignedTransaction


Suggested change

createUnsignedTransaction

createTransaction

unfortunately, there is already createTransaction

rvl · 2021-06-30T13:26:27Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+    toJSON = genericToJSON defaultRecordTypeOptions
+
+instance ToJSON ApiValidityBound where
+    toJSON ApiValidityBoundUnspecified = String "unspecified"


Better to use Null I think.

rvl · 2021-06-30T13:31:34Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+            (Just joinObj, Nothing) -> do
+                poolId <- joinObj .: "pool"
+                ix <- joinObj .: "stake_key_index"
+                pure $ Joining poolId ix


Suggested change

(Just joinObj, Nothing) -> do

poolId <- joinObj .: "pool"

ix <- joinObj .: "stake_key_index"

pure $ Joining poolId ix

(Just o, Nothing) -> Joining <$> o .: "pool" <*> o .: "stake_key_index"

rvl · 2021-06-30T13:32:21Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+            (Nothing, Just quitObj) -> do
+                ix <- quitObj .: "stake_key_index"
+                pure $ Leaving ix


Suggested change

(Nothing, Just quitObj) -> do

ix <- quitObj .: "stake_key_index"

pure $ Leaving ix

(Nothing, Just o) -> Leaving <$> o .: "stake_key_index"

rvl · 2021-06-30T13:32:56Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+            (Nothing, Just quitObj) -> do
+                ix <- quitObj .: "stake_key_index"
+                pure $ Leaving ix
+            _ -> fail "ApiMultiDelegationAction needs 'join' or 'quit' field"


Suggested change

_ -> fail "ApiMultiDelegationAction needs 'join' or 'quit' field"

_ -> fail "ApiMultiDelegationAction needs either 'join' or 'quit', but not both"

rvl · 2021-06-30T13:41:25Z

lib/core/src/Cardano/Wallet/Api/Types.hs

+                pure ApiValidityBoundUnspecified
+            else
+                fail "invalid string of ApiValidityBound"
+        processObject = withObject "ApiValidityBound object" $ \o -> do


It should be possible try parsing the Quantities directly without testing the "unit" field.

rvl · 2021-06-30T13:45:31Z

specifications/api/swagger.yaml

+      required:
+        - invalid_before
+        - invalid_hereafter


For the JSON side, we want an omitted field to mean unspecified bound.

piotr-iohk · 2021-06-30T16:20:10Z

Currently in swagger only passphrase is marked as required parameter (afaiu it is required for getting reward account), however I think that we need also at least one of payments, delegations or mint to be there as well. It would be nice to express this in swagger somehow (not sure how as at least one of the mentioned fields is required also).

Anyway, one can currently set just passphrase in the request and it seems that in such case the payment is constructed, which seems rather bad:

$ curl -X POST http://localhost:8090/v2/wallets/23b218fd80907f03f4ce4bc138eb3131e08dc0f8/transactions-construct \
-d '{"passphrase":"Secure Passphrase"}' \
-H "Content-Type: application/json" | jq

{
  "fee": {
    "quantity": 2166293,
    "unit": "lovelace"
  },
  "serialized_transaction": "ZzZRQWdZSllJQnowL2pTajFYNmhLbzdDaXNDNEdrTWhhTEZBRC9NSDlrd1BQUDlGUVFFMEFBR0JnbGc1QUluL3h1TUJFRS81UkNGdHhIeTQxb1lZTno0aDhjVmd1azRSQUsxTTRFajFSMHN4bTlFVlpPZENoaGFycXFmU3BVN0UzUEVLWDBiOEdnQjNpSEVDR2dBaERoVURHZ0hVam5pZi8vWT0=",
  "coin_selection": {
    "withdrawals": [],
    "inputs": [
      {
        "amount": {
          "quantity": 10000006,
          "unit": "lovelace"
        },
        "address": "addr_test1qqph473hczdyrk9c9te8qh3xd6gfug604800r4rxt82a2njvupy0236txxdaz9tyuapgv94t42na9f2wcnw0zzjlgm7qw40nap",
        "id": "8b59d852cbf65fad4897eeffaa32ff09ae8c9b382dc042b436425b6e91cc77ee",
        "derivation_path": [
          "1852H",
          "1815H",
          "0H",
          "0",
          "22"
        ],
        "assets": [],
        "index": 0
      }
    ],
    "deposits": [],
    "change": [
      {
        "amount": {
          "quantity": 7833713,
          "unit": "lovelace"
        },
        "address": "addr_test1qzyll3hrqygyl72yy9kugl9c66rpsde7y8cu2c96fcgspt2vupy0236txxdaz9tyuapgv94t42na9f2wcnw0zzjlgm7qp0g974",
        "derivation_path": [
          "1852H",
          "1815H",
          "0H",
          "1",
          "0"
        ],
        "assets": []
      }
    ],
    "outputs": []
  }
}

It seems that one full utxo is selected and "spent" to one of the wallet's own addresses...
Checked on rev 2df0c15.

rvl · 2021-07-01T07:29:50Z

In the case where the user didn't provide any of payments, delegations or mint, I'm not sure whether we need to disallow it - as long as the result is a valid transaction. Perhaps a user would like to post a transaction with nothing but metadata?

piotr-iohk · 2021-07-01T07:44:52Z

In the case where the user didn't provide any of payments, delegations or mint, I'm not sure whether we need to disallow it - as long as the result is a valid transaction. Perhaps a user would like to post a transaction with nothing but metadata?

That would also incur fees + minUtxoValue, so in fact (at least) a payment, right?
I guess it's possible to send metadata with mint or delegation too, but at least one of the payment/delegation/mint would be needed.

paweljakubas · 2021-07-01T16:34:06Z

bors r+

2702: Payment construction endpoint r=paweljakubas a=paweljakubas # Issue Number  adp-909 # Overview  - [x] POST transactions/construct in swagger - [x] Api.Types reflecting things added in swagger - [x] add Api skeleton - [x] unit tests for Api.Types, Malformed - [x] extend Transaction interface by adding mkUnsignedTransaction - [x] fill in implementation of Cardano.Api.Server and Cardano-Wallet function implementing 'payments' functionality - [x] prepare first integration testing # Comments   Co-authored-by: Pawel Jakubas <[email protected]> Co-authored-by: Rodney Lorrimar <[email protected]>

iohk-bors · 2021-07-01T17:15:20Z

Build failed:

buildkite/cardano-wallet

cardano-wallet                 >   src/Test/Integration/Scenario/API/Shared/Wallets.hs:973:19:
--
  | cardano-wallet                 >   1) API Specifications, SHARED_WALLETS, SHARED_WALLETS_LIST_01 - Wallets are listed from oldest to newest
  | cardano-wallet                 >        expected: Status {statusCode = 201, statusMessage = "Created"}
  | cardano-wallet                 >         but got: Status {statusCode = 500, statusMessage = "Internal Server Error"}
  | cardano-wallet                 >
  | cardano-wallet                 >        from the following response: Left (DecodeFailure "{\"code\":\"unexpected_error\",\"message\":\"That's embarrassing. Your wallet looks good, but I couldn't open a new database to store its data. This is unexpected and likely not your fault. Perhaps, check your filesystem's permissions or available space?\"}")
  | cardano-wallet                 >
  | cardano-wallet                 >        While verifying value:
  | cardano-wallet                 >          ( Status
  | cardano-wallet                 >              { statusCode = 500
  | cardano-wallet                 >              , statusMessage = "Internal Server Error"
  | cardano-wallet                 >              }
  | cardano-wallet                 >          , Left
  | cardano-wallet                 >              ( DecodeFailure "{"code":"unexpected_error","message":"That's embarrassing. Your wallet looks good, but I couldn't open a new database to store its data. This is unexpected and likely not your fault. Perhaps, check your filesystem's permissions or available space?"}" )
  | cardano-wallet                 >          )
  | cardano-wallet                 >
  | cardano-wallet                 >   To rerun use: --match "/API Specifications/SHARED_WALLETS/SHARED_WALLETS_LIST_01 - Wallets are listed from oldest to newest/"

paweljakubas · 2021-07-01T17:18:07Z

bors retry

2702: Payment construction endpoint r=paweljakubas a=paweljakubas # Issue Number  adp-909 # Overview  - [x] POST transactions/construct in swagger - [x] Api.Types reflecting things added in swagger - [x] add Api skeleton - [x] unit tests for Api.Types, Malformed - [x] extend Transaction interface by adding mkUnsignedTransaction - [x] fill in implementation of Cardano.Api.Server and Cardano-Wallet function implementing 'payments' functionality - [x] prepare first integration testing # Comments   Co-authored-by: Pawel Jakubas <[email protected]> Co-authored-by: Rodney Lorrimar <[email protected]>

iohk-bors · 2021-07-01T17:47:55Z

Build failed:

ci/hydra-build:required

 src/Test/Integration/Framework/DSL.hs:2280:7:
  1) API Specifications, SHELLEY_STAKE_POOLS, STAKE_POOLS_JOIN_01rewards - Can join a pool, earn rewards and collect them
       expected a successful response but got an error: DecodeFailure "{\"code\":\"created_invalid_transaction\",\"message\":\"That's embarrassing. It looks like I've created an invalid transaction that could not be parsed by the node. Here's an error message that may help with debugging: HardForkApplyTxErrFromEra S (S (S (Z (WrapApplyTxErr {unwrapApplyTxErr = ApplyTxError [DelegsFailure (WithdrawalsNotInRewardsDELEGS (fromList [(RewardAcnt {getRwdNetwork = Mainnet, getRwdCred = KeyHashObj (KeyHash \\\"83df2d49188a828575e0efa8faf2b9a5f5a6f740d6216e6554564497\\\")},Coin 122807086201)]))]}))))\"}"
       While verifying value:
         ( Status
             { statusCode = 500
             , statusMessage = "Internal Server Error"
             }
         , Left
             ( DecodeFailure "{"code":"created_invalid_transaction","message":"That's embarrassing. It looks like I've created an invalid transaction that could not be parsed by the node. Here's an error message that may help with debugging: HardForkApplyTxErrFromEra S (S (S (Z (WrapApplyTxErr {unwrapApplyTxErr = ApplyTxError [DelegsFailure (WithdrawalsNotInRewardsDELEGS (fromList [(RewardAcnt {getRwdNetwork = Mainnet, getRwdCred = KeyHashObj (KeyHash \"83df2d49188a828575e0efa8faf2b9a5f5a6f740d6216e6554564497\")},Coin 122807086201)]))]}))))"}" )
         )

  To rerun use: --match "/API Specifications/SHELLEY_STAKE_POOLS/STAKE_POOLS_JOIN_01rewards - Can join a pool, earn rewards and collect them/"

#2779

paweljakubas · 2021-07-01T17:51:33Z

bors retry

iohk-bors · 2021-07-01T18:32:46Z

Build succeeded:

paweljakubas requested a review from rvl June 10, 2021 12:16

paweljakubas self-assigned this Jun 10, 2021

paweljakubas commented Jun 10, 2021

View reviewed changes

paweljakubas force-pushed the paweljakubas/adp-909/payment-construction branch 3 times, most recently from 997ac09 to 0d2184a Compare June 18, 2021 18:17

paweljakubas changed the title ~~Payment construction and fee endpoints~~ Payment construction endpoint Jun 21, 2021

paweljakubas force-pushed the paweljakubas/adp-909/payment-construction branch from 87efd4f to 60fc62e Compare June 22, 2021 11:04

paweljakubas marked this pull request as ready for review June 22, 2021 15:37

paweljakubas force-pushed the paweljakubas/adp-909/payment-construction branch from c5ebf05 to fc1d4be Compare June 22, 2021 15:40

rvl reviewed Jun 24, 2021

View reviewed changes

paweljakubas force-pushed the paweljakubas/adp-909/payment-construction branch from fc1d4be to 590c35f Compare June 25, 2021 15:27

paweljakubas requested a review from rvl June 27, 2021 18:21

piotr-iohk reviewed Jun 28, 2021

View reviewed changes

rvl approved these changes Jun 30, 2021

View reviewed changes

paweljakubas added 10 commits July 1, 2021 14:38

introduce ApiTransactionConstructData in swagger

22b2310

add post transaction/construct endpoint

c2f658a

introduce input extended

06ed596

add transactions fee endpoint

cb98e20

introduce ApiSerializedTransaction

87c0e15

cherrypick some types from Rodney's PR 2642

4f4f0ea

add ApiConstructTransaction and ApiTxInputExtended

fe070d4

add ApiTransactionConstructData and ApiDelegationTx

a61d323

work on ApiMultiDelegationAction

1271cf2

add constructTransaction scaffolding

86cb780

paweljakubas and others added 17 commits July 1, 2021 14:38

impl constructTransaction - part 2

f07d378

impl constructUnsignedTx in shelley

e65f3c1

extend Transaction interface by mkUnsignedTx

67e35c5

add first version of full impl of constructTransaction

d4b8aa2

update core unit adjustments

8c3a40d

prepare scaffolding for new transaction integration test

ba4e3f7

add another check in the resultant coin selection inputs

48b5897

addressing code review - part 1

62430de

change reward account type in mkUnsignedTx from XPrv to xPub

6968978

address review - part 3

fb253a5

addressing Malformed and other bits

f48ccd4

Rename function

b531643

Use HTTP error code instead of ErrorCall

6f30708

Update cardano-addresses to use 3.5.0 tag

d76ceae

Regenerate nix

9ecd334

Can use derived NFData instance now

22c330b

resign from passphrase in data post

b27561a

paweljakubas force-pushed the paweljakubas/adp-909/payment-construction branch from 2df0c15 to b27561a Compare July 1, 2021 12:39

some more improvements

eed408d

iohk-bors bot merged commit bfaec3b into master Jul 1, 2021

iohk-bors bot deleted the paweljakubas/adp-909/payment-construction branch July 1, 2021 18:32

WilliamKingNoel-Bot pushed a commit that referenced this pull request Jul 1, 2021

docs: Merge #2702

6c47db2

	--, txDelegationAction -- this will be tackled when delegations are supported
	, txDelegationAction = Nothing -- TODO: ADP-909 this will be tackled when delegations are supported

	, constructTransaction = error "TODO should be supported in the final version of Transaction Workflow."
	, constructTransaction = error "TODO ADP-909 implement new transaction API for all wallet types."

	_ -> fail "ApiMultiDelegationAction needs 'join' or 'quit' field"
	_ -> fail "ApiMultiDelegationAction needs either 'join' or 'quit', but not both"

Payment construction endpoint #2702

Payment construction endpoint #2702

Conversation

paweljakubas commented Jun 10, 2021 • edited Loading

Issue Number

Overview

Comments

paweljakubas Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Anviking Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rvl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Anviking Jun 28, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-iohk commented Jun 28, 2021 • edited Loading

rvl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-iohk commented Jun 30, 2021

rvl commented Jul 1, 2021

piotr-iohk commented Jul 1, 2021

paweljakubas commented Jul 1, 2021

iohk-bors bot commented Jul 1, 2021 • edited by Anviking Loading

paweljakubas commented Jul 1, 2021

iohk-bors bot commented Jul 1, 2021 • edited by Anviking Loading

paweljakubas commented Jul 1, 2021

iohk-bors bot commented Jul 1, 2021

paweljakubas commented Jun 10, 2021 •

edited

Loading

paweljakubas Jun 10, 2021 •

edited

Loading

Anviking Jun 10, 2021 •

edited

Loading

Anviking Jun 28, 2021 •

edited

Loading

piotr-iohk commented Jun 28, 2021 •

edited

Loading

iohk-bors bot commented Jul 1, 2021 •

edited by Anviking

Loading

iohk-bors bot commented Jul 1, 2021 •

edited by Anviking

Loading