chore: fix license issue of some beps (#504)

Co-authored-by: justsmileit <[email protected]>

BEPs/BEP-414.md

@@ -8,6 +8,19 @@
 
 # BEP-414: Paymaster API Spec for EOA Wallets
 
+- [BEP-414: Paymaster API Spec for EOA Wallets](#bep-414-paymaster-api-spec-for-eoa-wallets)
+  - [1. Summary](#1-summary)
+  - [2. Abstract](#2-abstract)
+  - [3. Status](#3-status)
+  - [4. Motivation](#4-motivation)
+  - [5. Specification](#5-specification)
+    - [5.1 Definitions](#51-definitions)
+    - [5.2 Workflow](#52-workflow)
+    - [5.3 Wallet Interaction](#53-wallet-interaction)
+    - [5.4 Paymaster API Spec](#54-paymaster-api-spec)
+    - [5.5 Sponsor Policy && Fee Charge](#55-sponsor-policy--fee-charge)
+  - [6. License](#6-license)
+
 ## 1. Summary
 
 Unlike the paymaster defined in EIP-4337, this proposal introduces a paymaster solution specifically tailored for EOA (Externally Owned Account) wallets, along with standardized paymaster APIs. With minimal modifications, wallets can integrate paymasters that implement these API standards, enabling users to send transactions with zero gas fees.
@@ -172,4 +185,5 @@ Paymasters have complete autonomy in defining sponsor policies, which can be imp
 Paymasters also enjoy flexibility in their fee collection methods. Charges can be directly deducted from the sponsor's credit card, or sponsors can pre-deposit cryptocurrency to the paymaster platform, from which the balance is then charged.
 
 ## 6 License
-The content is licensed under CC0.
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

BEPs/BEP153.md

@@ -22,6 +22,7 @@
           - [5.5.2 Crash in Application Layer](#552-crash-in-application-layer)
           - [5.5.3 Error in Communication Layer](#553-error-in-communication-layer)
           - [5.5.4 How Funds are Handled When Errors Occur](#554-how-funds-are-handled-when-errors-occur)
+  - [6. License](#6-license)
 
 ## 1. Summary
 
@@ -223,4 +224,8 @@ It is very important to protect the safety of actors’ funds. As funds need to
 
 When a delegation request fails, an extra cross-chain package will be sent back to BSC. The funds will be unlocked from the tokenhub system contract, transferred to the staking system contract and be recorded as a part of the delegator’s pending undelegated. The delegator can get his/her funds back by claimUndelegated later. However, if the msg sender is a contract without a receive/fallback method, the transfer will fail and the funds may be lost forever. So **make sure your dApp implements the receive/fallback method**.
 
-![5.3 Error handle](./assets/bep-153/5.3_errorhandle.jpg)
+![5.3 Error handle](./assets/bep-153/5.3_errorhandle.jpg)
+
+## 6. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

BEPs/BEP172.md

@@ -16,6 +16,7 @@ Discussions: https://forum.bnbchain.org/t/bep-172-draft-improvement-on-bsc-valid
     - [4.1 Overall workflow](#41-overall-workflow)
     - [4.2 Remove recentlySigned validators from the candidate set](#42-remove-recentlysigned-validators-from-the-candidate-set)
     - [4.3 Reduce minimum delay duration to be zero added to 3 seconds](#43-reduce-minimum-delay-duration-to-be-zero-added-to-3-seconds)
+  - [5. License](#5-license)
 
 ## 1. Summary
 
@@ -40,3 +41,7 @@ With this BEP we rewrite the calculation algorithm for the `offturn` validation
   - All validators would be involved to calculate the `delay` time when committing the block mined by themselves currently, and when the `inturn` validator missed its turn, the fastest-with the smallest `delay` duration equals to 4 seconds-`offturn` validator might be the one that had signed recently which led to some other `offturn` validator be the valid selected one to commit block. This is how we observed a block be committed in more than 4 seconds when the `slash` happened. In this BEP, we remove the `recently signed` validators off from the candidate set for calculating `delay` duration from 1 seconds(then the duration would be 3+1=4 seconds) up.
 ### 4.3 Reduce minimum delay duration to be zero added to 3 seconds
   - When a `slash` happened, things would go wrong for quite a long time later on. For example, when `inturn` validator_A was `slashed` on block_100 and `offturn` validator_B took its place to commit the block of number 100. However validator_B should be `inturn` for committing block_101, then it would fail to commit block_101 since it had committed block_100 `recently`. So although there was actually no `slash` happend(all validator worked appropriately), we still need to `delay` some time (1 second or more) to wait for the `offturn` validator committing the block since the `inturn` validator had `recently` committed some block earlier.In this BEP, we reduce the shortest duration to zero second for this specific scenario which means blocks should be able to committed in expected duration (3 seconds) when all validators workd propriately.
+
+## 5. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

BEPs/BEP173.md

@@ -13,7 +13,7 @@
           - [4.3.2 Voting stage](#432-voting-stage)
           - [4.3.3 Tallying stage](#433-tallying-stage)
           - [4.3.4 Execution stage](#434-execution-stage)
-
+  - [5. License](#5-license)
 
 ## 1. Summary
 
@@ -98,3 +98,7 @@ If any of these conditions are not met, the deposit associated with the denied p
 #### 4.3.4 Execution Stage
 
 Once a text proposal is passed, it has no direct effect on the BNB Chain. Generic proposals such as a TextProposal must be reviewed by the BNB-Chain developers and the community for decisions on how to manually implement them.
+
+## 5. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).