4 design document for mvp #5
Conversation
design/design.md
Outdated
| >* pos_x: **Int** | ||
| >* pos_y: **Int** | ||
| >* fuel: **Int** | ||
| >* pilot_token: **ByteArray** |
design/design.md
Outdated
| ## Transactions | ||
|
|
||
| ### Create Pot UTxO: | ||
| This transaction creates the unique `Pot` UTxO locking min ada and an admin token. |
There was a problem hiding this comment.
We should indicate that the tx stores in the datum the ship token policy id. Something like:
This transaction creates...... and an admin token. It stores in the datum the ShipToken policy id for being able to reference it in the validator.
design/design.md
Outdated
|  | ||
|
|
||
|
|
||
| ### Collect Rewards: |
There was a problem hiding this comment.
User wallet must be shown in the inputs, given that the pilot token is needed for this operation.
design/design.md
Outdated
| ## Introduction | ||
| This document describes the technical design of the Asteria dApp - the script UTxOs involved, the operations that take place both during the game and in the setup phase, and the necessary validators and minting policies. | ||
|
|
||
| There will be a single script UTxO for the `Pot`, several `PelletState` UTxOs and a `ShipState` UTxO for every user. The `Pot` UTxO locks the ada amount paid by each user when creating a ship, and it's position on the board is always assumed to be (0,0). Both `PelletState` and `ShipState` UTxOs have their positions specified in the datum. In order to identify valid game UTxOs, the admin will deposit a special token in the `PelletState` and `Pot` UTxOs when creating them. |
There was a problem hiding this comment.
We could add at the end of this paragraph that the "admin token" is also used for parameterizing the pot and fuel validators, so we could have different "versions" of the game, each one with a different admin token.
design/design.md
Outdated
|
|
||
| #### *Gather Redeemer (includes gathering amount)* | ||
| * ship token is present in some input. | ||
| * there is a `ShipState` input with the same x and y datum coordinates as the `PelletState` UTxO. |
There was a problem hiding this comment.
This should be checked in the ship validator, not here. The rule should be "ship validator reads the pellet datum, but not the other way"
design/design.md
Outdated
| * there is a single `ShipState` input. | ||
| * the `PilotToken` is present in an input. | ||
| * no `ShipState` output. | ||
| * signed by ship owner. |
There was a problem hiding this comment.
how do you know who is the ship owner?? The pilot token is representing this, so no need to this check.
design/design.md
Outdated
| ***TX:*** | ||
| * a single token is minted. | ||
| * there is a single `ShipState` output. | ||
| * signed by the player joining the game. |
design/design.md
Outdated
| * there is a single `ShipState` output. | ||
| * signed by the player joining the game. | ||
|
|
||
| ***DATUM:*** |
There was a problem hiding this comment.
let's use constants to refer to game parameters, like the "minimum distance", also the fuel capacity, etc.
design/design.md
Outdated
| ***VALUE:*** | ||
| * the minted token is paid to the `ShipState` validator address. | ||
|
|
||
| #### BURN: |
design/design.md
Outdated
| ***VALUE:*** | ||
| * the minted token is paid to the `ShipState` validator address. | ||
|
|
||
| #### BURN: |
No description provided.