-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathTODO
152 lines (96 loc) · 6.79 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
# TODO
What can I learn from this Escrow contract?
https://github.com/Aman035/Escrow/blob/v2/Escrow.sol
## ARB Sepolia
- https://github.com/alchemyplatform/hello-world-tutorial
- https://hardhat.org/tutorial/deploying-to-a-live-network
- https://github.com/NomicFoundation/hardhat/issues/4582
- https://docs.arbitrum.io/build-decentralized-apps/quickstart-solidity-hardhat
https://catapulta.sh/?ref=remote3.co
https://anyflow.pro/
https://abi.ninja/
update package.json to latest and esp clearly vulnerabilities.
## Contract Stuff
- [ ] update the first offer
- [ ] reputation has no write method, that might be ok as it just calculates it. Maybe it can be calculated off-chain?
- [ ] maybe update user stuff to use strings more
- [ ] why does Trade have setAdmin, setInitialAdmins?
- [ ] timeout should be on offer maybe, not sure?
- [ ] how do I use the read functions on Rating?
- [ ] offerDisputeCounted?? offerParametersUsed??
- [ ] why does userOffers have a uint arg?
- [ ] pause and unpause should this really be on offers?
- [ ] what is the point in transferOwnership on Offer?
- [ ] contract Registry should probably have generic function to update addresses, not just updateOfferAddress.
- [ ] give Registry a read function
- [ ] really need to plan out the transaction flow with diagrams, re arbitration
- [ ] function to list users? one of those exists for offers
- [ ] escrow could use some serious review, including the transferEscrow function
- [ ] trace user paths. what could be missing?
- [ ] what is missing from the contracts?
- [ ] pick up where I left off with the public interface
## 1. Trade Initiation and Acceptance:
1. Implement a mechanism for the offer owners to accept or reject the trade request. This can be done through email notifications, in-app notifications, or by providing a dedicated page for managing trade requests.
2. If both offer owners accept the trade request, update the trade status to "Accepted" and proceed with the escrow process.
3. Implement the escrow functionality to hold the traded assets (e.g., USDC) until the trade conditions are met. This can be done using a smart contract or a trusted escrow service.
4. Provide a way for the offer owners to confirm the receipt of the fiat payments (e.g., Larry's USD payment to Mike's bank account and Andres' COP deposit to Maria's bank account).
5. Once the fiat payments are confirmed, release the escrowed assets (e.g., transfer the USDC from Mike's escrow to Andres' escrow).
6. Update the trade status to "Completed" and notify all parties involved about the successful completion of the trade.
7. Display the trade status and details to the users on the trade initiation page or a separate trade details page.
- Trade acceptance page for offer owners to accept or reject initiated trades.
- Trade status tracking page showing the current status of ongoing trades.
## 2. Escrow and Payment:
- Escrow locking page for offer owners to lock the crypto amount in escrow.
- Fiat payment confirmation page for trade takers to mark the fiat payment as paid.
- Escrow release page for releasing the crypto to the trade taker upon successful trade completion.
- Escrow refund page for refunding the crypto to the offer owner in case of trade cancellation or timeout.
## 3. Trade Finalization and Dispute Resolution:
- Trade finalization page for offer owners to finalize the trade once the fiat payment is confirmed.
- Dispute initiation page allowing trade parties to raise a dispute in case of any issues.
- Dispute resolution page for admins to resolve disputes and make a decision.
- Dispute evidence submission page for trade parties to submit evidence supporting their case.
## The RAI: Remittance Acceleration Interface
> This connects 2 offers to permit a taker to move fiat currency in country X to fiat currency in country Y using crypto as a transport layer. So, this would connect an offer that sells fiat for crypto in country X with an offer to buy fiat in country Y with the crypto from the first offer.
- question: What asset are you starting with? What asset are you ending with?
- use algorithm to display paths: Pathfinding Algorithm: Implement an algorithm that identifies the most efficient path(s) for converting the initial asset into the final asset. Efficiency could be measured in terms of cost, speed, or a combination of factors defined by the user.
- take a source currency and target currency and return a list of intermediate trades necessary for conversion
- breakdown each step
- per offer: show fees, exchange rates (sources)
- total: show total fees, both from offers and from network, KYC requirements
- amount in, amount out
- risk level / confidence score (based on reputations?)
- Estimated execution time
- Allow users to drag and drop offers to create a chain.
- Enable users to filter offers based on criteria such as fiat currency, crypto currency, and trade amount. (pro user mode?)
- Saved Transactions: Allow users to save chained transactions as templates for future use.
Rating and Feedback:
Trade rating page for trade parties to rate and provide feedback on completed trades.
User reputation page displaying the overall reputation score and rating history of a user.
Admin Panel:
Admin dashboard for managing and monitoring the platform.
Dispute management page for admins to view and resolve disputed trades.
Fee and penalty management page for admins to set and update platform fees and penalties.
Escrow management page for admins to perform escrow-related actions such as splitting or penalizing crypto.
Notifications and Alerts:
Notification system to keep users informed about trade status updates, disputes, and other important events.
Alert system to notify admins about critical actions that require their attention.
Analytics and Reporting:
Trade analytics page displaying various trade-related statistics and metrics.
User analytics page showing user-related data and insights.
Reporting functionality to generate reports on trades, disputes, and platform performance.
Security and Authentication:
Secure user authentication and authorization system.
Two-factor authentication (2FA) for enhanced security.
Access control mechanisms to ensure only authorized users can perform specific actions.
Events
An off-chain service, such as a Node.js application or a cloud function, listens for events emitted from the contracts.
Store contract-emitted events, including notifications, off-chain.
store trade history data in a storage provider such as PlanetScale or Arweave with cryptographic proofs/sigs/hashes so the integrity can be verified.
Looks like I can emit them as events and then store them elsewhere.
web3.eth.getLogs
consider GraphQL
API for retrieving events, including trade history
Testing
walk through all contracts and understand them step by step
create list of every user path so I can test them
update contract documentation