Skip to content

Commit

Permalink
Update ERC-1066: Chore fix docs (#546)
Browse files Browse the repository at this point in the history
* correct spelling erc-1066.md

* wrong verb form erc-1077.md

* add missing verb erc-1081.md
  • Loading branch information
cratiu222 authored Sep 27, 2024
1 parent 99e8c6a commit 82a7301
Show file tree
Hide file tree
Showing 3 changed files with 3 additions and 3 deletions.
2 changes: 1 addition & 1 deletion ERCS/erc-1066.md
Original file line number Diff line number Diff line change
Expand Up @@ -236,7 +236,7 @@ Currently unspecified. (Full range reserved)

#### `0x7*` TBD

Currently unspecifie. (Full range reserved)
Currently unspecified. (Full range reserved)

#### `0x8*` TBD

Expand Down
2 changes: 1 addition & 1 deletion ERCS/erc-1077.md
Original file line number Diff line number Diff line change
Expand Up @@ -85,7 +85,7 @@ The fields **MUST** be constructed as this method:

The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive the reward.

The [EIP-191] message must be constructed as following:
The [EIP-191] message must be constructed as follows:
```solidity
keccak256(
abi.encodePacked(
Expand Down
2 changes: 1 addition & 1 deletion ERCS/erc-1081.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ After studying bounties as they've existed for thousands of years (and after imp
To implement these steps, a number of functions are needed:
- `initializeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This is used when deploying a new StandardBounty contract, and is particularly useful when applying the proxy design pattern, whereby bounties cannot be initialized in their constructors. Here, the data string should represent an IPFS hash, corresponding to a JSON object which conforms to the schema (described below).
- `fulfillBounty(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data)`: This is called to submit a fulfillment, submitting a string representing an IPFS hash which contains the deliverable for the bounty. Initially fulfillments could only be submitted by one individual at a time, however users consistently told us they desired to be able to collaborate on fulfillments, thereby allowing the credit for submissions to be shared by several parties. The lines along which eventual payouts are split are determined by the fractions of the submission credited to each fulfiller (using the array of numerators and single denominator). Here, a bounty platform may also include themselves as a collaborator to collect a small fee for matching the bounty with fulfillers.
- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise.
- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to be based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise.
- `drainBounty(StandardToken[] _payoutTokens)`: This may be called by the `issuer` to drain a bounty of it's funds, if the need should arise.
- `changeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This may be called by the `issuer` to change the `issuer`, `arbiter`, `data`, and `deadline` fields of their bounty.
- `changeIssuer(address _issuer)`: This may be called by the `issuer` to change to a new `issuer` if need be
Expand Down

0 comments on commit 82a7301

Please sign in to comment.