You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: website/docs/guides/infrastructure.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: Contract Infrastructure
3
3
---
4
4
5
5
When creating a smart contract application on Bitcoin Cash you'll need to investigate whether you need surrounding contract infrastructure.
6
-
Below we'll discuss the 2 main types of contract infrastructure you might run into: the need to store contract details and the need for a transaction server.
6
+
Below we'll discuss the 2 main types of contract infrastructure you might run into: the need to store contract details and the need for a transaction server.
7
7
8
8
## Storing Contract Details
9
9
@@ -13,7 +13,7 @@ Because of the `pay-to-scripthash` (`P2SH`) standard for smart contracts on BCH,
13
13
It is the responsibility of smart contract services/apps to keep track of the contract details making up the `P2SH` contract, as user-wallets are currently not smart enough to do this automatically.
14
14
:::
15
15
16
-
When users are allowed to provide their own `constructor` arguments when creating a BCH smart contract, each contract creation will have a unique smart contract address. Only the constructor arguments in the contract bytecode are variable, the rest of the bytecode for a contract is static. This static part is derived from the CashScript source file, so storing the contract source file or artifact both has the same effect.
16
+
When users are allowed to provide their own `constructor` arguments when creating a BCH smart contract, each contract creation will have a unique smart contract address. Only the constructor arguments in the contract bytecode are variable, the rest of the bytecode for a contract is static. This static part is derived from the CashScript source file, so storing the contract source file or artifact both has the same effect.
17
17
18
18
:::note
19
19
To construct the full contract script you need both the `constructor` arguments and static contract bytecode (either the contract source file or the `Artifact`) to be available.
@@ -40,10 +40,10 @@ There are 2 main types of events which might need a transaction server to trigge
40
40
41
41
### Time-related events
42
42
43
-
Time-related events are when your smart contract uses absolute or relative locktimes, which require a waiting period before certain transactions can happen. However, if you want those transactions to 'automatically' happen when this locktime is reached, then you will need to create a transaction server to monitor the blockheight on an ongoing basis.
43
+
Time-related events are when your smart contract uses absolute or relative locktimes, which require a waiting period before certain transactions can happen. However, if you want those transactions to 'automatically' happen when this locktime is reached, then you will need to create a transaction server to monitor the block height on an ongoing basis.
44
44
45
45
:::tip
46
-
Both the `Electrum` and `Chaingraph` indexers allow you to create websocket subscriptions to listen for blockheight updates.
46
+
Both the `Electrum` and `Chaingraph` indexers allow you to create websocket subscriptions to listen for block height updates.
Copy file name to clipboardExpand all lines: website/docs/guides/syntax-highlighting.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ GitHub has highlighting for Solidity built in. To associate `.cash` files with S
43
43
*.cash linguist-language=Solidity # GitHub
44
44
```
45
45
46
-
Unfortunately Gitlab does not have properly working Soldidity highlighting through the `gitattributes` for now...
46
+
Unfortunately Gitlab does not have properly working Solidity highlighting through the `gitattributes` for now...
47
47
48
48
## Others
49
49
If your editor is not mentioned above, the steps are likely very similar. Try to find a Solidity syntax highlighting plugin for your editor of choice and find a method to associate `.cash` files with this Solidity highlighting.
Moria is a decentralized stablecoin and borrowing protocol on Bitcoin Cash using CashTokens. The Moria protocol works with collateralized-debt-positions (CDPs) where stablecoins are issued by creating over-collateralized loans. The Moria protocol uses multiple smart contracts, all written in CashScript.
29
+
Moria is a decentralized stablecoin and borrowing protocol on Bitcoin Cash using CashTokens. The Moria protocol works with collateralizeddebtpositions (CDPs) where stablecoins are issued by creating over-collateralized loans. The Moria protocol uses multiple smart contracts, all written in CashScript.
0 commit comments