{currentMessage}
- ) : ( - "" - )} -{currentMessage}
- ) : ( - "" - )} -(get-block-info? prop-name block-height-expr)`
-#### descripción:
-The `get-block-info?` function fetches data for a block of the given block height. The value and type returned are determined by the specified `BlockInfoPropertyName`. If the provided `BlockHeightInt` does not correspond to an existing block prior to the current block, the function returns `none`. The currently available property names are `time`, `header-hash`, `burnchain-header-hash`, `id-header-hash`, `miner-address`, and `vrf-seed`.
-
-This is a Unix epoch timestamp in seconds which roughly corresponds to when the block was mined. The `time` property returns an integer value of the block header time field. **Warning**: this does not increase monotonically with each block and block times are accurate only to within two hours. See [BIP113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) for more information.
-
-The `header-hash`, `burnchain-header-hash`, `id-header-hash`, and `vrf-seed` properties return a 32-byte buffer.
-
-The `miner-address` property returns a `principal` corresponding to the miner of the given block.
-
-The `id-header-hash` is the block identifier value that must be used as input to the `at-block` function.
-
-#### ejemplo:
-```clarity
-(get-block-info? time u0) ;; Returns (some u1557860301)
-(get-block-info? header-hash u0) ;; Returns (some 0x374708fff7719dd5979ec875d56cd2286f6d3cf7ec317a3b25632aab28ec37bb)
-(get-block-info? vrf-seed u0) ;; Returns (some 0xf490de2920c8a35fabeb13208852aa28c76f9be9b03a4dd2b3c075f7a26923b4)
-```
-
-### err
-#### input: `A`
-#### output: `(response A B)`
-#### signature: `(err value)`
-#### descripción:
-The `err` function constructs a response type from the input value. Use `err` for creating return values in public functions. An _err_ value indicates that any database changes during the processing of the function should be rolled back.
-#### ejemplo:
-```clarity
-(err true) ;; Returns (err true)
-```
-
-### ok
-#### entrada: `A`
-#### output: `(response A B)`
-#### signature: `(ok value)`
-#### descripción:
-The `ok` function constructs a response type from the input value. Use `ok` for creating return values in public functions. An _ok_ value indicates that any database changes during the processing of the function should materialize.
-#### ejemplo:
-```clarity
-(ok 1) ;; Returns (ok 1)
-```
-
-### some
-#### input: `A`
-#### output: `(optional A)`
-#### signature: `(some value)`
-#### descripción:
-The `some` function constructs a `optional` type from the input value.
-#### ejemplo:
-```clarity
-(some 1) ;; Returns (some 1)
-(is-none (some 2)) ;; Returns false
-```
-
-### default-to
-#### input: `A, (optional A)`
-#### output: `A`
-#### signature: `(default-to default-value option-value)`
-#### descripción:
-The `default-to` function attempts to 'unpack' the second argument: if the argument is a `(some ...)` option, it returns the inner value of the option. If the second argument is a `(none)` value, `default-to` it returns the value of `default-value`.
-#### ejemplo:
-```clarity
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: \"blockstack\" } { id: 1337 })
-(default-to 0 (get id (map-get? names-map (tuple (name \"blockstack\"))))) ;; Returns 1337
-(default-to 0 (get id (map-get? names-map (tuple (name \"non-existant\"))))) ;; Returns 0
-```
-
-### asserts!
-#### input: `bool, C`
-#### output: `bool`
-#### firma: `(asserts! bool-expr thrown-value)`
-#### descripción:
-The `asserts!` function admits a boolean argument and asserts its evaluation: if bool-expr is `true`, `asserts!` returns `true` and proceeds in the program execution. If the supplied argument is returning a false value, `asserts!` _returns_ `thrown-value` and exits the current control-flow.
-#### ejemplo:
-```clarity
-(asserts! (is-eq 1 1) (err 1)) ;; Devuelve true
-```
-
-### unwrap!
-#### input: `(optional A) | (response A B), C`
-#### output: `A`
-#### firma: `(unwrap! | uint, ...`
-#### descripción:
-The `unwrap!` function attempts to 'unpack' the first argument: if the argument is an option type, and the argument is a `(some ...)` option, `unwrap!` returns the inner value of the option. If the argument is a response type, and the argument is an `(ok ...)` response, `unwrap!` returns the inner value of the `ok`. If the supplied argument is either an `(err ...)` or a `(none)` value, `unwrap!` _returns_ `thrown-value` from the current function and exits the current control-flow.
-#### ejemplo:
-```clarity
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: \"blockstack\" } { id: 1337 })
-(define-private (get-name-or-err (name (string-ascii 12)))
- (let ((raw-name (unwrap! (map-get? names-map { name: name }) (err 1))))
- (ok raw-name)))
-
-(get-name-or-err \"blockstack\") ;; Returns (ok (tuple (id 1337)))
-(get-name-or-err \"non-existant\") ;; Returns (err 1)
-```
-
-### unwrap-err!
-#### input: `(response A B), C`
-#### output: `B`
-#### signature: `(unwrap-err! response-input thrown-value)`
-#### descripción:
-The `unwrap-err!` function attempts to 'unpack' the first argument: if the argument is an `(err ...)` response, `unwrap-err!` returns the inner value of the `err`. If the supplied argument is an `(ok ...)` value, `unwrap-err!` _returns_ `thrown-value` from the current function and exits the current control-flow.
-#### ejemplo:
-```clarity
-(unwrap-err! (err 1) false) ;; Returns 1
-```
-
-### unwrap-panic
-#### input: `(optional A) | (response A B)`
-#### output: `A`
-#### signature: `(unwrap-panic option-input)`
-#### descripción:
-The `unwrap` function attempts to 'unpack' its argument: if the argument is an option type, and the argument is a `(some ...)` option, this function returns the inner value of the option. If the argument is a response type, and the argument is an `(ok ...)` response, it returns the inner value of the `ok`. If the supplied argument is either an `(err ...)` or a `(none)` value, `unwrap` throws a runtime error, aborting any further processing of the current transaction.
-#### ejemplo:
-```clarity
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: \"blockstack\" } { id: 1337 })
-(unwrap-panic (map-get? names-map { name: \"blockstack\" })) ;; Returns (tuple (id 1337))
-(unwrap-panic (map-get? names-map { name: \"non-existant\" })) ;; Throws a runtime exception
-```
-
-### unwrap-err-panic
-#### entrada: `(response A B)`
-#### salida: `B`
-#### firma: `(unwrap-err-panic response-input)`
-#### descripción:
-The `unwrap-err` function attempts to 'unpack' the first argument: if the argument is an `(err ...)` response, `unwrap` returns the inner value of the `err`. If the supplied argument is an `(ok ...)` value, `unwrap-err` throws a runtime error, aborting any further processing of the current transaction.
-#### ejemplo:
-```clarity
-(unwrap-err-panic (err 1)) ;; Returns 1
-(unwrap-err-panic (ok 1)) ;; Throws a runtime exception
-```
-
-### match
-#### input: `(optional A) name expression expression | (response A B) name expression name expression`
-#### output: `C`
-#### signature: `(match opt-input some-binding-name some-branch none-branch) |
-(match-resp input ok-binding-name ok-branch err-binding-name err-branch)`
-#### descripción:
-The `match` function is used to test and destructure optional and response types.
-
-If the `input` is an optional, it tests whether the provided `input` is a `some` or `none` option, and evaluates `some-branch` or `none-branch` in each respective case.
-
-Within the `some-branch`, the _contained value_ of the `input` argument is bound to the provided `some-binding-name` name.
-
-Only _one_ of the branches will be evaluated (similar to `if` statements).
-
-If the `input` is a response, it tests whether the provided `input` is an `ok` or `err` response type, and evaluates `ok-branch` or `err-branch` in each respective case.
-
-Within the `ok-branch`, the _contained ok value_ of the `input` argument is bound to the provided `ok-binding-name` name.
-
-Within the `err-branch`, the _contained err value_ of the `input` argument is bound to the provided `err-binding-name` name.
-
-Only _one_ of the branches will be evaluated (similar to `if` statements).
-
-Note: Type checking requires that the type of both the ok and err parts of the response object be determinable. For situations in which one of the parts of a response is untyped, you should use `unwrap-panic` or `unwrap-err-panic` instead of `match`.
-#### ejemplo:
-```clarity
-
-(define-private (add-10 (x (optional int)))
- (match x
- value (+ 10 value)
- 10))
-(add-10 (some 5)) ;; Returns 15
-(add-10 none) ;; Returns 10
-
-(define-private (add-or-pass-err (x (response int (string-ascii 10))) (to-add int))
- (match x
- value (ok (+ to-add value))
- err-value (err err-value)))
-(add-or-pass-err (ok 5) 20) ;; Returns (ok 25)
-(add-or-pass-err (err \"ERROR\") 20) ;; Returns (err \"ERROR\")
-```
-
-### try!
-#### input: `(optional A) | (response A B)`
-#### output: `A`
-#### firma: `(try! A`
-#### descripción:
-The `try!` function attempts to 'unpack' the first argument: if the argument is an option type, and the argument is a `(some ...)` option, `try!` returns the inner value of the option. If the argument is a response type, and the argument is an `(ok ...)` response, `try!` returns the inner value of the `ok`. If the supplied argument is either an `(err ...)` or a `none` value, `try!` _returns_ either `none` or the `(err ...)` value from the current function and exits the current control-flow.
-#### ejemplo:
-```clarity
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: \"blockstack\" } { id: 1337 })
-(try! (map-get? names-map { name: \"blockstack\" })) ;; Returns (tuple (id 1337))
-(define-private (checked-even (x int))
- (if (is-eq (mod x 2) 0)
- (ok x)
- (err false)))
-(define-private (double-if-even (x int))
- (ok (* 2 (try! (checked-even x)))))
-(double-if-even 10) ;; Returns (ok 20)
-(double-if-even 3) ;; Returns (err false)
-```
-
-### is-ok
-#### entrada: `(response A B)`
-#### output: `bool`
-#### signature: `(is-ok value)`
-#### descripción:
-`is-ok` tests a supplied response value, returning `true` if the response was `ok`, and `false` if it was an `err`.
-#### ejemplo:
-```clarity
-(is-ok (ok 1)) ;; Returns true
-(is-ok (err 1)) ;; Returns false
-```
-
-### is-none
-#### input: `(optional A)`
-#### output: `bool`
-#### signature: `(is-none value)`
-#### descripción:
-`is-none` tests a supplied option value, returning `true` if the option value is `(none)`, and `false` if it is a `(some ...)`.
-#### ejemplo:
-```clarity
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: \"blockstack\" } { id: 1337 })
-(is-none (get id (map-get? names-map { name: \"blockstack\" }))) ;; Returns false
-(is-none (get id (map-get? names-map { name: \"non-existant\" }))) ;; Returns true
-```
-
-### is-err
-#### entrada: `(response A B)`
-#### output: `bool`
-#### signature: `(is-err value)`
-#### descripción:
-`is-err` tests a supplied response value, returning `true` if the response was an `err`, and `false` if it was an `ok`.
-#### ejemplo:
-```clarity
-(is-err (ok 1)) ;; Returns false
-(is-err (err 1)) ;; Returns true
-```
-
-### is-some
-#### input: `(optional A)`
-#### output: `bool`
-#### signature: `(is-some value)`
-#### descripción:
-`is-some` tests a supplied option value, returning `true` if the option value is `(some ...)`, and `false` if it is a `none`.
-#### ejemplo:
-```clarity
-
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: \"blockstack\" } { id: 1337 })
-(is-some (get id (map-get? names-map { name: \"blockstack\" }))) ;; Returns true
-(is-some (get id (map-get? names-map { name: \"non-existant\" }))) ;; Returns false
-```
-
-### filter
-#### input: `Function(A) -> bool, sequence_A`
-#### output: `sequence_A`
-#### signature: `(filter func sequence)`
-#### descripción:
-The `filter` function applies the input function `func` to each element of the input sequence, and returns the same sequence with any elements removed for which `func` returned `false`. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. The `func` argument must be a literal function name. `
-#### ejemplo:
-```clarity
-
-(filter not (list true false true false)) ;; Returns (false false)
-(define-private (is-a (char (string-utf8 1))) (is-eq char u\"a\"))
-(filter is-a u\"acabd\") ;; Returns u\"aa\"
-(define-private (is-zero (char (buff 1))) (is-eq char 0x00))
-(filter is-zero 0x00010002) ;; Returns 0x0000
-```
-
-### ft-get-balance
-#### input: `TokenName, principal`
-#### output: `uint`
-#### signature: `(ft-get-balance token-name principal)`
-#### descripción:
-`ft-get-balance` returns `token-name` balance of the principal `principal`. The token type must have been defined using `define-fungible-token`.
-#### ejemplo:
-```clarity
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(ft-get-balance stackaroo 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; Returns u100
-```
-
-### nft-get-owner?
-#### input: `AssetName, A`
-#### output: `(optional principal)`
-#### signature: `(nft-get-owner? The asset must have been defined using define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-#### descripción:
-`nft-burn?` is used to burn an asset and remove that asset's owner from the `recipient` principal. The asset must have been defined using `define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-#### ejemplo:
-```clarity
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo \"Roo\" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF)
-(nft-get-owner? stackaroo \"Roo\") ;; Returns (some SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF)
-(nft-get-owner? stackaroo \"Too\") ;; Returns none
-```
-
-### ft-transfer?
-#### input: `TokenName, uint, principal, principal`
-#### output: `(response bool uint)`
-#### signature: `(ft-transfer? token-name amount sender recipient)`
-#### descripción:
-`ft-transfer?` is used to increase the token balance for the `recipient` principal for a token type defined using `define-fungible-token` by debiting the `sender` principal. In contrast to `stx-transfer?`, any user can transfer the assets. When used, relevant guards need to be added.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to transfer `(err u2)` -- `sender` and `recipient` are the same principal `(err u3)` -- amount to send is non-positive `
-#### ejemplo:
-```clarity
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(ft-transfer? stackaroo u50 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(ft-transfer? stackaroo u60 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (err u1)
-```
-
-### nft-transfer?
-#### input: `AssetName, A, principal, principal`
-#### output: `(response bool uint)`
-#### signature: `(nft-transfer? asset-class asset-identifier sender recipient)`
-#### descripción:
-`nft-transfer?` is used to change the owner of an asset identified by `asset-identifier` from `sender` to `recipient`. The `asset-class` must have been defined by `define-non-fungible-token` and `asset-identifier` must be of the type specified in that definition. In contrast to `stx-transfer?`, any user can transfer the asset. When used, relevant guards need to be added.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not own the asset `(err u2)` -- `sender` and `recipient` are the same principal `(err u3)` -- asset identified by asset-identifier does not exist `
-#### ejemplo:
-```clarity
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo \"Roo\" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(nft-transfer? stackaroo \"Roo\" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(nft-transfer? stackaroo \"Roo\" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (err u1)
-(nft-transfer? stackaroo \"Stacka\" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (err u3)
-```
-
-### nft-mint?
-#### input: `AssetName, A, principal`
-#### output: `(response bool uint)`
-#### signature: `(nft-mint? asset-class asset-identifier recipient)`
-#### descripción:
-`nft-burn?` is used to burn an asset and remove that asset's owner from the `recipient` principal. The asset must have been defined using `define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-
-If an asset identified by `asset-identifier` _already exists_, this function will return an error with the following error code:
-
-`(err u1)`
-
-Otherwise, on successfuly mint, it returns `(ok true)`. `
-#### ejemplo:
-```clarity
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo \"Roo\" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-### ft-mint?
-#### input: `TokenName, uint, principal`
-#### output: `(response bool uint)`
-#### firma: `(ft-mint? token-name amount recipient)`
-#### descripción:
-`ft-mint?` is used to increase the token balance for the `recipient` principal for a token type defined using `define-fungible-token`. The increased token balance is _not_ transfered from another principal, but rather minted.
-
-If a non-positive amount is provided to mint, this function returns `(err 1)`. Otherwise, on successfuly mint, it returns `(ok true)`. `
-#### ejemplo:
-```clarity
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-### ft-get-supply
-#### input: `TokenName`
-#### output: `uint`
-#### signature: `(ft-get-supply token-name)`
-#### descripción:
-`ft-get-balance` returns `token-name` circulating supply. The token type must have been defined using `define-fungible-token`.
-#### ejemplo:
-```clarity
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(ft-get-supply stackaroo) ;; Returns u100
-```
-
-### ft-burn?
-#### input: `TokenName, uint, principal`
-#### output: `(response bool uint)`
-#### signature: `(ft-burn? token-name amount sender)`
-#### descripción:
-`ft-burn?` is used to decrease the token balance for the `sender` principal for a token type defined using `define-fungible-token`. The decreased token balance is _not_ transfered to another principal, but rather destroyed, reducing the circulating supply.
-
-If a non-positive amount is provided to burn, this function returns `(err 1)`. Otherwise, on successfuly burn, it returns `(ok true)`.
-
-#### ejemplo:
-```clarity
-
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(ft-burn? stackaroo u50 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-### nft-burn?
-#### input: `AssetName, A, principal`
-#### output: `(response bool uint)`
-#### signature: `(nft-burn? asset-class asset-identifier recipient)`
-#### descripción:
-`nft-burn?` is used to burn an asset and remove that asset's owner from the `recipient` principal. The asset must have been defined using `define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-
-If an asset identified by `asset-identifier` _doesn't exist_, this function will return an error with the following error code:
-
-`(err u1)`
-
-Otherwise, on successfuly burn, it returns `(ok true)`. `
-#### ejemplo:
-```clarity
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo \"Roo\" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(nft-burn? stackaroo \"Roo\" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-### stx-get-balance
-#### input: `principal`
-#### output: `uint`
-#### signature: `(stx-get-balance owner)`
-#### descripción:
-`stx-get-balance` is used to query the STX balance of the `owner` principal.
-
-This function returns the STX balance of the `owner` principal. In the event that the `owner` principal isn't materialized, it returns 0.
-
-#### ejemplo:
-```clarity
-(stx-get-balance 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; Returns u0
-(stx-get-balance (as-contract tx-sender)) ;; Returns u1000
-```
-
-### stx-transfer?
-#### input: `uint, principal, principal`
-#### output: `(response bool uint)`
-#### signature: `(stx-transfer? amount sender recipient)`
-#### descripción:
-`stx-transfer?` is used to increase the STX balance for the `recipient` principal by debiting the `sender` principal. The `sender` principal _must_ be equal to the current context's `tx-sender`.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to transfer `(err u2)` -- `sender` and `recipient` are the same principal `(err u3)` -- amount to send is non-positive `(err u4)` -- the `sender` principal is not the current `tx-sender`
-
-#### ejemplo:
-```clarity
-
-(as-contract
- (stx-transfer? u60 tx-sender 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)) ;; Returns (ok true)
-(as-contract
- (stx-transfer? u50 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR tx-sender)) ;; Returns (err u4)
-```
-
-### stx-burn?
-#### input: `uint, principal`
-#### output: `(response bool uint)`
-#### signature: `(stx-burn? amount sender)`
-#### descripción:
-`stx-burn?` debits the `sender` principal's STX holdings by `amount`, destroying the STX. The `sender` principal _must_ be equal to the current context's `tx-sender`.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to transfer `(err u3)` -- amount to send is non-positive `(err u4)` -- the `sender` principal is not the current `tx-sender`
-
-#### ejemplo:
-```clarity
-(as-contract
- (stx-burn? u60 tx-sender)) ;; Returns (ok true)
-(as-contract
- (stx-burn? u50 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)) ;; Returns (err u4)
-```
-
-### define-constant
-#### input: `MethodSignature, MethodBody`
-#### output: `Not Applicable`
-#### signature: `(define-constant name expression)`
-#### descripción:
-`define-constant` is used to define a private constant value in a smart contract. The expression passed into the definition is evaluated at contract launch, in the order that it is supplied in the contract. This can lead to undefined function or undefined variable errors in the event that a function or variable used in the expression has not been defined before the constant.
-
-Like other kinds of definition statements, `define-constant` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-#### ejemplo:
-```clarity
-
-(define-constant four (+ 2 2))
-(+ 4 four) ;; Returns 8
-```
-
-### define-private
-#### input: `MethodSignature, MethodBody`
-#### output: `Not Applicable`
-#### signature: `(define-private (function-name (arg-name-0 arg-type-0) (arg-name-1 arg-type-1) ...) function-body)`
-#### descripción:
-`define-private` is used to define _private_ functions for a smart contract. Private functions may not be called from other smart contracts, nor may they be invoked directly by users. Instead, these functions may only be invoked by other functions defined in the same smart contract.
-
-Like other kinds of definition statements, `define-private` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Private functions may return any type.
-#### ejemplo:
-```clarity
-(define-private (max-of (i1 int) (i2 int))
- (if (> i1 i2)
- i1
- i2))
-(max-of 4 6) ;; Returns 6
-```
-
-### define-public
-#### input: `MethodSignature, MethodBody`
-#### output: `Not Applicable`
-#### signature: `(define-public (function-name (arg-name-0 arg-type-0) (arg-name-1 arg-type-1) ...) function-body)`
-#### descripción:
-`define-public` is used to define a _public_ function and transaction for a smart contract. Public functions are callable from other smart contracts and may be invoked directly by users by submitting a transaction to the Stacks blockchain.
-
-Like other kinds of definition statements, `define-public` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Public functions _must_ return a ResponseType (using either `ok` or `err`). Any datamap modifications performed by a public function is aborted if the function returns an `err` type. Public functions may be invoked by other contracts via `contract-call?`.
-#### ejemplo:
-```clarity
-(define-public (hello-world (input int))
- (begin (print (+ 2 input))
- (ok input)))
-```
-
-### define-read-only
-#### input: `MethodSignature, MethodBody`
-#### output: `Not Applicable`
-#### signature: `(define-read-only (function-name (arg-name-0 arg-type-0) (arg-name-1 arg-type-1) ...) function-body)`
-#### descripción:
-`define-read-only` is used to define a _public read-only_ function for a smart contract. Such functions are callable from other smart contracts.
-
-Like other kinds of definition statements, `define-read-only` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Read-only functions may return any type. However, read-only functions may not perform any datamap modifications, or call any functions which perform such modifications. This is enforced both during type checks and during the execution of the function. Public read-only functions may be invoked by other contracts via `contract-call?`.
-#### ejemplo:
-```clarity
-(define-read-only (just-return-one-hundred)
- (* 10 10))
- ```
-
-### define-map
-#### input: `MapName, TypeDefinition, TypeDefinition`
-#### output: `Not Applicable`
-#### signature: `(define-map map-name key-type value-type)`
-#### descripción:
-`define-map` is used to define a new datamap for use in a smart contract. Such maps are only modifiable by the current smart contract.
-
-Maps are defined with a key type and value type, often these types are tuple types.
-
-Like other kinds of definition statements, `define-map` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-#### ejemplo:
-```clarity
-(define-map squares { x: int } { square: int })
-(define-private (add-entry (x int))
- (map-insert squares { x: 2 } { square: (* x x) }))
-(add-entry 1)
-(add-entry 2)
-(add-entry 3)
-(add-entry 4)
-(add-entry 5)
-```
-
-### define-data-var
-#### input: `VarName, TypeDefinition, Value`
-#### output: `Not Applicable`
-#### signature: `(define-data-var var-name type value)`
-#### descripción:
-`define-data-var` is used to define a new persisted variable for use in a smart contract. Such variable are only modifiable by the current smart contract.
-
-Persisted variable are defined with a type and a value.
-
-Like other kinds of definition statements, `define-data-var` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-#### ejemplo:
-```clarity
-(define-data-var size int 0)
-(define-private (set-size (value int))
- (var-set size value))
-(set-size 1)
-(set-size 2)
-```
-
-### define-fungible-token
-#### input: `TokenName, `
-#### output: `Not Applicable`
-#### signature: `(define-fungible-token token-name )`
-#### descripción:
-`define-fungible-token` is used to define a new fungible token class for use in the current contract.
-
-The second argument, if supplied, defines the total supply of the fungible token. This ensures that all calls to the `ft-mint?` function will never be able to create more than `total-supply` tokens. If any such call were to increase the total supply of tokens passed that amount, that invocation of `ft-mint?` will result in a runtime error and abort.
-
-Like other kinds of definition statements, `define-fungible-token` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Tokens defined using `define-fungible-token` may be used in `ft-transfer?`, `ft-mint?`, and `ft-get-balance` functions`
-#### ejemplo:
-```clarity
-(define-fungible-token stacks)
-(define-fungible-token limited-supply-stacks u100)
-```
-
-### define-non-fungible-token
-#### input: `AssetName, TypeSignature`
-#### output: `Not Applicable`
-#### signature: `(define-non-fungible-token asset-name asset-identifier-type)`
-#### descripción:
-`define-non-fungible-token` is used to define a new non-fungible token class for use in the current contract. Individual assets are identified by their asset identifier, which must be of the type `asset-identifier-type`. Asset identifiers are _unique_ identifiers.
-
-Like other kinds of definition statements, `define-non-fungible-token` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Assets defined using `define-non-fungible-token` may be used in `nft-transfer?`, `nft-mint?`, and `nft-get-owner?` functions`
-#### ejemplo:
-```clarity
-(define-non-fungible-token names (buff 50))
-```
-
-### define-trait
-#### input: `VarName, [MethodSignature]`
-#### output: `Not Applicable`
-#### signature: `(define-trait trait-name ((func1-name (arg1-type arg2-type ...) (return-type))))`
-#### descripción:
-`define-trait` is used to define a new trait definition for use in a smart contract. Other contracts can implement a given trait and then have their contract identifier being passed as function arguments in order to be called dynamically with `contract-call?`.
-
-Traits are defined with a name, and a list functions defined with a name, a list of argument types, and return type.
-
-Like other kinds of definition statements, `define-trait` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-#### ejemplo:
-```clarity
-(define-trait token-trait
- ((transfer? (principal principal uint) (response uint uint))
- (get-balance (principal) (response uint uint))))
-```
-
-### use-trait
-#### input: `VarName, TraitIdentifier`
-#### output: `Not Applicable`
-#### signature: `(use-trait trait-alias trait-identifier)`
-#### descripción:
-`use-trait` is used to bring a trait, defined in another contract, to the current contract. Subsequent references to an imported trait are signaled with the syntax ``.
-
-Traits import are defined with a name, used as an alias, and a trait identifier. Trait identifiers can either be using the sugared syntax (.token-a.token-trait), or be fully qualified ('SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait).
-
-Like other kinds of definition statements, `use-trait` may only be used at the top level of a smart contract definition (i.e., you cannot put such a statement in the middle of a function body).
-#### ejemplo:
-```clarity
-(use-trait token-a-trait 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait)
-(define-public (forward-get-balance (user principal) (contract ))
- (begin
- (ok 1)))
-```
-
-### impl-trait
-#### input: `TraitIdentifier`
-#### output: `Not Applicable`
-#### signature: `(impl-trait trait-identifier)`
-#### descripción:
-`impl-trait` can be use for asserting that a contract is fully implementing a given trait. Additional checks are being performed when the contract is being published, rejecting the deployment if the contract is violating the trait specification.
-
-Trait identifiers can either be using the sugared syntax (.token-a.token-trait), or be fully qualified ('SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait).
-
-Like other kinds of definition statements, `impl-trait` may only be used at the top level of a smart contract definition (i.e., you cannot put such a statement in the middle of a function body).
-
-#### ejemplo:
-```clarity
-(impl-trait 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait)
-(define-public (get-balance (account principal))
- (ok u0))
-(define-public (transfer? (from principal) (to principal) (amount uint))
- (ok u0))
-```
\ No newline at end of file
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/clarity-language/language-keywords.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/clarity-language/language-keywords.md
deleted file mode 100644
index 963934d563..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/clarity-language/language-keywords.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: Palabras clave
-description: Vea una lista detallada de todas las palabras clave para el lenguaje Clarity.
-tags:
- - clarity
----
-
-
-## Referencia de palabra clave
-
-Detailed list of all keywords for the Clarity language.
-
-
-### contract-caller
-#### salida: `principal`
-#### descripción:
-Returns the caller of the current contract context. If this contract is the first one called by a signed transaction, the caller will be equal to the signing principal. If `contract-call?` was used to invoke a function from a new contract, `contract-caller` changes to the _calling_ contract's principal. If `as-contract` is used to change the `tx-sender` context, `contract-caller` _also_ changes to the same contract principal.
-#### ejemplo:
-```clarity
-(print contract-caller) ;; Will print out a Stacks address of the transaction sender
-```
-
-### tx-sender
-#### salida: `principal`
-#### descripción:
-Returns the original sender of the current transaction, or if `as-contract` was called to modify the sending context, it returns that contract principal.
-#### ejemplo:
-```clarity
-(print tx-sender) ;; Will print out a Stacks address of the transaction sender
-```
-
-### block-height
-#### output: `uint`
-#### descripción:
-Returns the current block height of the Stacks blockchain as an uint
-#### ejemplo:
-```clarity
-(> block-height 1000) ;; returns true if the current block-height has passed 1000 blocks.
-```
-
-### burn-block-height
-#### output: `uint`
-#### descripción:
-Returns the current block height of the underlying burn blockchain as a uint
-#### ejemplo:
-```clarity
-(> burn-block-height 1000) ;; returns true if the current height of the underlying burn blockchain has passed 1000 blocks.
-```
-
-### none
-#### output: `(optional ?)`
-#### descripción:
-Represents the _none_ option indicating no value for a given optional (analogous to a null value).
-#### ejemplo:
-```clarity
-(define-public (only-if-positive (a int))
- (if (> a 0)
- (some a)
- none))
-(only-if-positive 4) ;; Returns (some 4)
-(only-if-positive (- 3)) ;; Returns none
-```
-
-### true
-#### output: `bool`
-#### descripción:
-Boolean true constant.
-#### ejemplo:
-```clarity
-(and true false) ;; Evaluates to false
-(or false true) ;; Evaluates to true
-```
-
-### false
-#### output: `bool`
-#### descripción:
-Boolean false constant.
-#### ejemplo:
-```clarity
-(and true false) ;; Evaluates to false
-(or false true) ;; Evaluates to true
-```
-
-### stx-liquid-supply
-#### output: `uint`
-#### descripción:
-Returns the total number of micro-STX (uSTX) that are liquid in the system as of this block.
-#### ejemplo:
-```clarity
-(print stx-liquid-supply) ;; Will print out the total number of liquid uSTX
-```
-
-### is-in-regtest
-#### output: `bool`
-#### descripción:
-Returns whether or not the code is running in a regression test
-#### ejemplo:
-```clarity
-(print is-in-regtest) ;; Will print 'true' if the code is running in a regression test
-```
-
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/clarity-language/language-types.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/clarity-language/language-types.md
deleted file mode 100644
index e2c3453962..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/clarity-language/language-types.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Tipos
-description: Vea una lista detallada de todos los tipos para el lenguaje Clarity.
-tags:
- - clarity
----
-
-## Clarity Type System
-
-The type system contains the following types:
-
-| Tipos | Notas |
-| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `int` | signed 128-bit integer |
-| `uint` | unsigned 128-bit integer |
-| `bool` | boolean value (`true` or `false`) |
-| `principal` | object representing a principal (whether a contract principal or standard principal) |
-| `(buff max-len)` | byte buffer of maximum length `max-len`. |
-| `(string-ascii max-len)` | Cadena ASCII de longitud máxima `max-len` |
-| `(string-utf8 max-len)` | UTF-8 string of maximum length `max-len` (u"A smiley face emoji \u{1F600} as a utf8 string") |
-| `(list max-len entry-type)` | list of maximum length `max-len`, with entries of type `entry-type` |
-| `{label-0: value-type-0, label-1: value-type-1, ...}` | tuple, group of data values with named fields |
-| `(optional some-type)` | an option type for objects that can either be `(some value)` or `none` |
-| `(response ok-type err-type)` | object used by public functions to commit their changes or abort. May be returned or used by other functions as well, however, only public functions have the commit/abort behavior. |
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/index.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/index.md
deleted file mode 100644
index ab09a9ad44..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/index.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Visión general de Clarity
-description: Resumen y guías para comenzar con Clarity
-sidebar_label: Escribe contratos inteligentes
-sidebar_position: 2
----
-
-## Introducción
-
-Clarity is a **decidable** smart contract language that optimizes for predictability and security, designed for the Stacks blockchain. Smart contracts allow developers to encode essential business logic on a blockchain.
-
-## Contratos inteligentes
-
-Smart contracts encode and enforce rules for modifying a particular set of data that is shared among people and entities who don't necessarily trust each other. For example, a smart contract can hold funds in escrow until multiple parties agree to release them, create its own ledger and keep track of its own novel tokens (fungible or non-fungible), and even help make supply chains more transparent.
-
-A smart contract execution can result in new transactions being written to the blockchain. Because smart contracts are programs that exist in a blockchain, anyone can query them, and anyone can submit transactions to execute them.
-
-Apps can take advantage of smart contracts to manage a global state that is visible to the public. Anyone can audit the blockchain to independently verify that an app's global shared state has been managed correctly according to the smart contract's rules.
-
-There is a [Clarity Visual Studio Code plugin][] available for syntax assistance and debugging.
-
-## Casos de uso
-
-Not every decentralized application requires smart contracts, but Clarity unlocks interesting capabilities for decentralized applications. Examples of use cases include, but are not limited to:
-
-- Access control (for example pay to access)
-- Non-fungible (for example collectibles) and fungible tokens (for example stablecoins)
-- Plantillas de modelo de negocio (por ejemplo suscripciones)
-- App-specific blockchains
-- Decentralized Autonomous Organizations
-
-## Diseño del lenguaje
-
-Clarity differs from most other smart contract languages in two essential ways:
-
-- The language is interpreted and broadcast on the blockchain as is (not compiled)
-- The language is decidable (not Turing complete)
-
-Using an interpreted language ensures that the executed code is human-readable and auditable. A decidable language like Clarity makes it possible to determine precisely which code is executed, for any function.
-
-A Clarity smart contract consists of two parts, a data space and a set of functions. Only the associated smart contract may modify its corresponding data space on the blockchain. Functions may be private and thus callable only from within the smart contract, or public and thus callable from other contracts. Users call smart contracts' public functions by broadcasting a transaction on the blockchain which invokes the public function. Contracts can also call public functions from other smart contracts.
-
-Tenga en cuenta algunas de las reglas y limitaciones del lenguaje Clarity.
-
-- The only primitive types are booleans, integers, buffers, and principals.
-- Recursion is illegal and there are no anonymous functions.
-- Looping is only performed via `map`, `filter`, or `fold`.
-- There is support for lists, however, the only variable length lists in the language appear as function inputs; there is no support for list operations like append or join.
-- Las variables son inmutables.
-
-## Explorar más
-
-Para más detalles y referencias del lenguaje, mira lo siguiente:
-
-- [Clarity language overview](./clarity-language/)
-- [Understating Principals](principals)
-- [Valores de Clarity](values)
-
-[Clarity Visual Studio Code plugin]: https://marketplace.visualstudio.com/items?itemName=HiroSystems.clarity-lsp
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/principals.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/principals.md
deleted file mode 100644
index d854b416e6..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/principals.md
+++ /dev/null
@@ -1,237 +0,0 @@
----
-title: Principals
-description: 'Clarity: Entendiendo Principals'
-sidebar_position: 1
----
-
-## Introducción
-
-_Principals_ are a Clarity native type that represents an entity that can have a token balance. This section discusses principals and how they are used in the Clarity.
-
-## Principals and tx-sender
-
-Assets in the smart contracting language and blockchain are "owned" by objects of the principal type, meaning that any object of the principal type may own an asset. For the case of public-key hash and multi-signature Stacks addresses, a given principal can operate on their assets by issuing a signed transaction on the blockchain. _Smart contracts_ may also be principals (represented by the smart contract's identifier), however, there is no private key associated with the smart contract, and it cannot broadcast a signed transaction on the blockchain.
-
-A Clarity contract can use a globally defined `tx-sender` variable to obtain the current principal. The following example defines a transaction type that transfers `amount` microSTX from the sender to a recipient if amount is a multiple of 10, otherwise returning a 400 error code.
-
-```clarity
-(define-public (transfer-to-recipient! (define-public (transfer-to-recipient! (recipient principal) (amount uint))
- (if (is-eq (mod amount 10) 0)
- (stx-transfer? amount tx-sender recipient)
- (err u400))) amount tx-sender recipient)
- (err u400)))
-```
-
-Clarity provides an additional variable to help smart contracts authenticate a transaction sender. The keyword `contract-caller` returns the principal that _called_ the current contract. If an inter-contract call occurred, `contract-caller` returns the last contract in the stack of callers. For example, suppose there are three contracts A, B, and C, each with an `invoke` function such that `A::invoke` calls `B::invoke` and `B::invoke` calls `C::invoke`.
-
-When a user Bob issues a transaction that calls `A::invoke`, the value of `contract-caller` in each successive invoke function's body would change:
-
-```clarity
-in A::invoke, contract-caller = Bob
-in B::invoke, contract-caller = A
-in C::invoke, contract-caller = B
-```
-
-This allows contracts to make assertions and perform authorization checks using not only the `tx-sender` (which in this example, would always be "Bob"), but also using the `contract-caller`. This could be used to ensure that a particular function is only ever called directly and never called via an inter-contract call (by asserting that `tx-sender` and `contract-caller` are equal). We provide an example of a two different types of authorization checks in the rocket ship example below.
-
-## Smart contracts as principals
-
-Smart contracts themselves are principals and are represented by the smart contract's identifier -- which is the publishing address of the contract _and_ the contract's name, for example:
-
-```clarity
-'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR.contract-name
-```
-
-For convenience, smart contracts may write a contract's identifier in the form `.contract-name`. This will be expanded by the Clarity interpreter into a fully qualified contract identifier that corresponds to the same publishing address as the contract it appears in. For example, if the same publisher address, `SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR`, is publishing two contracts, `contract-A` and `contract-B`, the fully qualified identifier for the contracts would be:
-
-```clarity
-'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR.contract-A
-'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR.contract-B
-```
-
-But, in the contract source code, if the developer wishes to call a function from `contract-A` in `contract-B`, they can write
-
-```clarity
-(contract-call? (contract-call? .contract-A public-function-foo)
-```
-
-This allows the smart contract developer to modularize their applications across multiple smart contracts _without_ knowing the publishing key a priori.
-
-In order for a smart contract to operate on assets it owns, smart contracts may use the special `(as-contract ...)` function. This function executes the expression (passed as an argument) with the `tx-sender` set to the contract's principal, rather than the current sender. The `as-contract` function returns the value of the provided expression.
-
-For example, a smart contract that implements something like a "token faucet" could be implemented as so:
-
-```clarity
-(define-map claimed-before
- ((sender principal))
- ((claimed bool)))
-
-(define-constant err-already-claimed u1)
-(define-constant err-faucet-empty u2)
-(define-constant stx-amount u1)
-
-(define-public (claim-from-faucet)
- (let ((requester tx-sender)) ;; declarar una varable local requester = tx-sender
- (asserts! (is-none (map-get? claimed-before {sender: requester})) (err err-already-claimed))
- (unwrap! (as-contract (stx-transfer? stx-amount tx-sender requester)) (err err-faucet-empty))
- (map-set claimed-before {sender: requester} {claimed: true})
- (ok stx-amount)))
-```
-
-In this example, the public function `claim-from-faucet`:
-
-- Checks if the sender has claimed from the faucet before.
-- Assigns the tx sender to a `requester` variable.
-- Adds an entry to the tracking map.
-- Uses `as-contract` to send 1 microstack
-
-Unlike other principals, there is no private key associated with a smart contract. As it lacks a private key, a Clarity smart contract cannot broadcast a signed transaction on the blockchain.
-
-## Example: Authorization checks
-
-The interactions between `tx-sender`, `contract-caller` and `as-contract` are subtle, but are important when performing authorization checks in a contract. In this example contract, we'll show two different kinds of authorization checks a contract may wish to perform, and then walk through how different ways in which contract functions may be called will pass or fail those checks.
-
-This contract defines a "rocket-ship" non-fungible-token that a principal may own and manage the authorized pilots. Pilots are principals that are allowed to "fly" the rocket ship.
-
-This contract performs two different authorization checks:
-
-1. Before a ship is allowed to fly, the contract checks whether or not the transaction was created and signed by an authorized pilot. A pilot could, for example, call another contract, which then calls the `fly-ship` public function on the pilot's behalf.
-2. Before modifying the allowed-pilots for a given rocket ship, the contract checks that the transaction was signed by the owner of the rocket ship. Furthermore, the contract requires that this function be called _directly_ by the ship's owner, rather than through a inter-contract-call.
-
-The second type of check is more restrictive than the first check, and is helpful for guarding very sensitive routines --- it protects users from unknowingly calling a function on a malicious contract that subsequently tries to call sensitive functions on another contract.
-
-```clarity
-;;
-;; rockets-base.clar
-;;
-
-(define-non-fungible-token rocket-ship uint)
-
-;; a map from rocket ships to their allowed
-;; pilots
-(define-map allowed-pilots
- ((rocket-ship uint)) ((pilots (list 10 principal))))
-
-;; implementing a contains function via fold
-(define-private (contains-check
- (y principal)
- (to-check { p: principal, result: bool }))
- (if (get result to-check)
- to-check
- { p: (get p to-check),
- result: (is-eq (get p to-check) y) }))
-
-(define-private (contains (x principal) (find-in (list 10 principal)))
- (get result (fold contains-check find-in
- { p: x, result: false })))
-
-(define-read-only (is-my-ship (ship uint))
- (is-eq (some tx-sender) (nft-get-owner? rocket-ship ship)))
-
-;; this function will print a message
-;; (and emit an event) if the tx-sender was
-;; an authorized flyer.
-;;
-;; here we use tx-sender, because we want
-;; to allow the user to let other contracts
-;; fly the ship on behalf of users
-
-(define-public (fly-ship (ship uint))
- (let ((pilots (default-to
- (list)
- (get pilots (map-get? allowed-pilots { rocket-ship: ship })))))
- (if (contains tx-sender pilots)
- (begin (print "Flew the rocket-ship!")
- (ok true))
- (begin (print "Tried to fly without permission!")
- (ok false)))))
-;;
-;; Authorize a new pilot.
-;;
-;; here we want to ensure that this function
-;; was called _directly_ by the user by
-;; checking that tx-sender and contract-caller are equal.
-;; if any other contract is in the call stack, contract-caller
-;; would be updated to a different principal.
-;;
-(define-public (authorize-pilot (ship uint) (pilot principal))
- (begin
- ;; sender must equal caller: an intermediate contract is
- ;; not issuing this call.
- (asserts! (is-eq tx-sender contract-caller) (err u1))
- ;; sender must own the rocket ship
- (asserts! (is-eq (some tx-sender)
- (nft-get-owner? rocket-ship ship)) (err u2))
- (let ((prev-pilots (default-to
- (list)
- (get pilots (map-get? allowed-pilots { rocket-ship: ship })))))
- ;; don't add a pilot already in the list
- (asserts! (not (contains pilot prev-pilots)) (err u3))
- ;; append to the list, and check that it is less than
- ;; the allowed maximum
- (match (as-max-len? (append prev-pilots pilot) u10)
- next-pilots
- (ok (map-set allowed-pilots {rocket-ship: ship} {pilots: next-pilots}))
- ;; too many pilots already
- (err u4)))))
-```
-
-### Extending functionality: Multi-flyer contract
-
-The authorization scheme for `fly-ship` allows pilots to fly rocket-ships from other contracts. This allows other contracts to provide new functionality built around calling that function.
-
-For example, we can create a contract that calls `fly-ship` for multiple rocket-ships in a single transaction:
-
-```clarity
-;;
-;; rockets-multi.clar
-;;
-
-(define-private (call-fly (ship uint))
- (unwrap! (contract-call? .rockets-base fly-ship ship) false))
-;; try to fly all the ships, returning a list of whether
-;; or not we were able to fly the supplied ships
-(define-public (fly-all (ships (list 10 uint)))
- (ok (map call-fly ships)))
-```
-
-### Authorization for Contract-Owned Assets
-
-The check in `authorize-pilot` protects users from malicious contracts, but how would such a scheme support contract-owned assets? This is what the `as-contract` function is used for. The `as-contract` function executes the supplied closure as if the sender of the transaction was the current contract, rather than the user -- it does this by updating `tx-sender` to the current contract principal. We can use this to, for example, create a smart contract rocket-ship-line:
-
-```clarity
-;;
-;; rockets-ship-line.clar
-;;
-
-(define-constant line-ceo 'SP19Y6GRV9X778VFS1V8WT2H502WFK33XZXADJWZ)
-
-(define-data-var employed-pilots (list 10 principal) (list))
-
-;; This function will:
-;; * check that it is called by the line-ceo
-;; * check that the rocket is owned by the contract
-;; * authorize each employed pilot to the ship
-(define-public (add-managed-rocket (ship uint))
- (begin
- ;; only the ceo may call this function
- (asserts! (is-eq tx-sender contract-caller line-ceo) (err u1))
- ;; start executing as the contract
- (as-contract (begin
- ;; make sure the contract owns the ship
- (asserts! (contract-call? .rockets-base is-my-ship ship) (err u2))
- ;; register all of our pilots on the ship
- (add-pilots-to ship)))))
-
-;; add all the pilots to a ship using fold --
-;; the fold checks the return type of previous calls,
-;; skipping subsequent contract-calls if one fails.
-(define-private (add-pilot-via-fold (pilot principal) (prior-result (response uint uint)))
- (let ((ship (try! prior-result)))
- (try! (contract-call? .rockets-base authorize-pilot ship pilot))
- (ok ship)))
-(define-private (add-pilots-to (ship uint))
- (fold add-pilot-via-fold (var-get employed-pilots) (ok ship)))
-```
-
-In order for the contract to add each pilot to a new ship, the contract must call `authorize-pilot`. However, the contract wants to perform this action on behalf of a ship the _contract_ owns, not the transaction sender. To do this, the contract uses `as-contract`.
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/resources.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/resources.md
deleted file mode 100644
index 2c77a44bde..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/resources.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Recursos
-description: 'Recursos'
-sidebar_position: 8
----
-
-# Recursos externos
-
-
-[Libro de Clarity](https://book.clarity-lang.org/)
-
-[Universo de Clarity](https://stacks.org/clarity-universe)
-
-[Tutoriales Clarity de Hiro](https://docs.hiro.so/tutorials)
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/software.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/software.md
deleted file mode 100644
index 3ee29373af..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/software.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Software de desarrollo de Clarity
-description: Las siguientes herramientas son útiles para desarrollar contratos inteligentes con Clarity
-sidebar_position: 4
----
-
-## Protocolo del Servidor de Idioma (LSP en inglés) para Clarity (incluyendo extensión de Visual Studio Code)
-
-The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc.
-
-Esto hace que la programación en Clarity sea más fácil y mucho más intuitiva.
-
-
-
-
-El repositorio de Clarity LSP está disponible [aquí](https://github.com/hirosystems/clarity-lsp). La extensión para Visual Studio Code se puede descargar directamente desde [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=HiroSystems.clarity-lsp), pero podría ser una versión anterior. Para una versión más actualizada también puedes descargarla desde [open-vsx](https://open-vsx.org/extension/hirosystems/clarity-lsp).
-
-## Clarity REPL
-
-A read—eval—print loop (REPL), also termed an interactive toplevel or language shell, is a simple, interactive computer programming environment that takes single user inputs (that is, single expressions), evaluates (executes) them, and returns the result to the user; a program written in a REPL environment is executed piecewise.
-
-
-
-Las instrucciones sobre cómo instalar Clarity REPL se pueden encontrar [aquí](https://github.com/hirosystems/clarity-repl).
-
-## Clarinet
-
-Clarinet is a Clarity runtime packaged as a command line tool, designed to facilitate smart contract understanding, development, testing and deployment. Clarinet consists of a Clarity REPL and a testing harness, which, when used together allow you to rapidly develop and test a Clarity smart contract, with the need to deploy the contract to a local devnet or testnet.
-
-
-
-Las instrucciones de instalación, incluyendo la compilación del código fuente se pueden encontrar [aquí](https://github.com/hirosystems/clarinet). If you prefer you can directly download the latest compiled realease for Windows, Mac and Linux [here](https://github.com/hirosystems/clarinet/releases).
-
-[Clarinet 101](https://www.youtube.com/playlist?list=PL5Ujm489LoJaAz9kUJm8lYUWdGJ2AnQTb) contains multiple Clarinet video tutorials
-
-### Primeros pasos con Clarinet
-
-Puede verificar que tiene instalado Clarinet comprobando su versión:
-
-```bash
-$ clarinet --version
-clarinet 0.70
-```
-
-More detailed information on using Clarinet is available [here](https://book.clarity-lang.org/ch07-00-using-clarinet.html). However to get you started, the following commands are important to know.
-
-Crear un nuevo proyecto y entrar en su directorio:
-
-```bash
-clarinet new my-project && cd my-project
-```
-
-Crear un nuevo contrato dentro de `mi-proyecto`:
-
-```bash
-clarinet contract new mycoolcontract
-```
-
-Check the syntax of Clarity:
-
-```bash
-clarity check
-```
-
-Para probar su contrato:
-
-```bash
-clarinet test
-```
-
-Entrar en la consola de Clarinet:
-
-```bash
-clarinet console
-```
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/tokens.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/tokens.md
deleted file mode 100644
index 2f8e89394f..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/tokens.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Tokens
-description: Aprende acerca del soporte de tokens en Clarity
-sidebar_position: 3
----
-
-## Introducción
-
-A fundamental use of blockchain technology is the representation, store, and transfer of value between users of a blockchain. Cryptocurrency is a very common use of blockchain technology, and remains one of the primary drivers of adoption of blockchain technology. Cryptocurrencies are represented by blockchain tokens: individual units of value within a given blockchain ecosystem. Blockchain tokens can extend beyond just digital currency, however, and recent developments throughout the cryptocurrency community have demonstrated potential for the use of blockchain to tokenize and represent not just money but other tangible assets.
-
-A blockchain token is a digital asset that can be verifiably owned by a user of a blockchain. Blockchain tokens are governed by a set of rules that are defined by either the blockchain itself (in the case of native tokens) or by a smart contract on a blockchain. Rules can vary depending on the nature and the use of the token.
-
-Tokens on a blockchain fall into two general categories, depending on their properties: [fungible][] or [non-fungible][]. The following sections discuss the properties of both types of tokens, and provide information about implementation of the two types of tokens on Stacks.
-
-## Tokens fungibles
-
-A core property of any token on a blockchain is fungibility. A fungible token is a token that's mutually interchangable or capable of mutual substitution. In other words, one quantity or part of a fungible token can be replaced by an equal quantity or part of the same fungible token. Fungible tokens are often used to represent real-world fungible assets like currency. The STX token is an example of a fungible token. Other examples include stablecoins, tokens that represent voting rights in a DAO, or tokens that algorithmically track the price of stocks.
-
-Fungible tokens form one of the most important value propositions for blockchain technology, the ability to store value and exchange that value through both internal and external transactions. Because fungible tokens can be divided into smaller parts and recombined into the same value representation, they serve a great utility for transferring value between blockchain users.
-
-The primary fungible token on the Stacks blockchain is the native token, STX. Because the Stacks blockchain allows for the creation of \[smart contracts\]\[\], other fungible tokens can be created on the Stacks blockchain as well. [SIP-010][] specifies the standard for fungible tokens on the Stacks blockchain. This specification defines the functions and traits that a fungible token on Stacks _must_ have. By complying with this standard, fungible tokens on Stacks can be easily represented by wallets that support Stacks.
-
-### Understanding the fungible token standard
-
-The [SIP-010][] standard is an interface definition that allows Stacks applications and wallets to interact with fungible tokens in a standard way. Supporting the standard reduces complexity for token creators to get their tokens into the ecosystem. Under the [SIP-010][] standard, fungible tokens must have the following characteristics:
-
-- Ability to transfer a specified amount of the token to a recipient (`transfer`). The recipient is required to be a Stacks principal.
-- Ability to obtain the human-readable name of the token (`get-name`).
-- Ability to obtain a short name (ticker symbol) for the token (`get-symbol`).
-- Ability to get the number of decimals in the token representation (`get-decimals`). This is used to construct a representation of the token that humans would be familiar dealing with. For example, the US dollar has 2 decimals, if the base unit is cents.
-- Ability to get the balance of the token for a particular Stacks principal (`get-balance-of`).
-- Ability to get the total supply of the token (`get-total-supply`).
-- A URI to metadata associated with the token (`get-token-uri`). This can resolve to off-chain metadata about the token or contract, such as an image icon for the token or a description.
-
-## Tokens no fungibles (NFTs)
-
-Non-fungible tokens (NFTs) are a type of token that are not interchangeable. NFTs have unique traits (usually in the form of attached metadata) that restrict the abillity to replace them with identical tokens. An NFT is a token that is unique, such as a piece of art, or ownership rights to a real-world asset such as a house.
-
-NFTs alone don't have an inherent value, like a currency. The value of an NFT is derived from the assets that the NFT represents. The use of NFTs are myriad, including digital art, collectibles, domain names, and representation of ownership of content rights. NFTs can be used as digital certificates that track the authenticty of real world items, or digitize the ownership rights to property.
-
-As with fungible tokens, NFTs on the Stacks blockchain are created with smart contracts. [SIP-009][] specifies the standard for NFTs on the Stacks blockchain. This specification defines the functions and traits that an NFT _must_ have, but most NFTs have more functions or traits attached than those solely described by the specification. By complying with this standard, non-fungible tokens on Stacks can be easily represented by wallets that support Stacks.
-
-### Understanding the non-fungible token standard
-
-The [SIP-009][] standard is an interface definition that the Stacks ecosystem aligned on. With support for this standard across wallets and tools, it becomes easy to interact with NFTs. Under the [SIP-009][] standard, NFT contract must have the following characteristics:
-
-- Ability to obtain the last token identifier (`get-last-token-id`). This id represents the upper limit of NFTs issued by the contract.
-- A URI to metadata associated with a specific token identifier. (`get-token-uri`). This URI could resolve to a JSON file with information about the creator, associated media files, descriptions, signatures, and more.
-- Ability to verify the owner for a given token identifier (`get-owner`). The owner resolves to a [Stacks principal](principals).
-- Ability to transfer an NFT to a recipient (`transfer`). The recipient is required to be a Stacks principal.
-
-## Lectura adicional
-
-- [La Diferencia entre tokens fungibles y no fungibles](https://101blockchains.com/fungible-vs-non-fungible-tokens/)
-- [Explícalo como si tuviera 5 años: NFTs](https://messari.io/article/explain-it-like-i-am-5-nfts)
-
-[fungible]: #fungible-tokens
-[non-fungible]: #non-fungible-tokens-nfts
-[SIP-010]: https://github.com/hstove/sips/blob/feat/sip-10-ft/sips/sip-010/sip-010-fungible-token-standard.md
-[SIP-009]: https://github.com/stacksgov/sips/blob/main/sips/sip-009/sip-009-nft-standard.md
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/values.md b/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/values.md
deleted file mode 100644
index 0d130a428d..0000000000
--- a/i18n/es/docusaurus-plugin-content-docs/current/write-smart-contracts/values.md
+++ /dev/null
@@ -1,301 +0,0 @@
----
-title: Valores de Clarity
-description: Aprenda cómo tratar con Clarity Values en JavaScript
-sidebar_position: 2
----
-
-## Introducción
-
-El lenguaje de Clarity hace uso de un sistema de tipo estático fuerte. This simply means that every function defined in Clarity expects arguments of specific types, and that a failure to provide properly typed arguments will result in your code failing to compile, or your contract call transactions failing prior to execution.
-
-In order to build web applications that interact with Clarity contracts, you will need to learn how to construct and use `ClarityValue` objects. The [@stacks/transactions](https://github.com/hirosystems/stacks.js/tree/master/packages/transactions) library makes this easy, as we will demonstrate below.
-
-## Tipos de Clarity
-
-Please see the following page for information on [Clarity Types](../write-smart-contracts/clarity-language/language-types).
-
-## Constructing Clarity Values and accessing their data
-
-Clarity values can be constructed with functions provided by the [@stacks/transactions](https://github.com/hirosystems/stacks.js/tree/master/packages/transactions) library. These functions simply output javascript objects that contain a value and a numerical representation of the Clarity type information. The Clarity types are encoded as follows:
-
-```typescript
-export enum ClarityType {
- Int = 0,
- UInt = 1,
- Buffer = 2,
- BoolTrue = 3,
- BoolFalse = 4,
- PrincipalStandard = 5,
- PrincipalContract = 6,
- ResponseOk = 7,
- ResponseErr = 8,
- OptionalNone = 9,
- OptionalSome = 10,
- List = 11,
- Tuple = 12,
- StringASCII = 13,
- StringUTF8 = 14,
-}
-```
-
-`ClarityValue` objects can be serialized and included in transactions that interact with published Clarity contracts.
-
-Here are examples of how to construct each type of Clarity value, and how to access its data if it has any:
-
-### Booleans
-
-```typescript
-const t = trueCV();
-// { type: ClarityType.BoolTrue }
-
-const f = falseCV();
-// { type: ClarityType.BoolFalse }
-```
-
-Boolean Clarity Values don't contain any underlying data. They are simply objects with `type` information.
-
-### Optional Values
-
-```typescript
-const nothing: NoneCV = noneCV();
-// { type: ClarityType.OptionalNone }
-
-const something: SomeCV = someCV(trueCV());
-// { type: ClarityType.OptionalSome, value: { type: 4 } }
-```
-
-Optional Clarity Values can either be nothing (an empty type that has no data), or something (a wrapped value).
-
-If you are dealing with a function or contract function that returns an `OptionalCV`, you should always check what type it is before trying to access its value.
-
-```typescript
-const maybeVal: OptionalCV = await callReadOnlyFunction(...);
-
-if (maybeVal.type === ClarityType. OptionalSome) {
- console.log(maybeVal.value);
-} else if (maybeVal.type === ClarityType. OptionalNone) {
- // deal with `none` value
-}
-```
-
-### Buffers
-
-```typescript
-const buffer = Buffer.from('foo');
-const bufCV: BufferCV = bufferCV(buffer);
-// { type: ClarityType.Buffer, buffer: }
-```
-
-### Integers
-
-Clarity supports both integers and unsigned integers.
-
-```typescript
-const i: IntCV = intCV(-10);
-// { type: ClarityType.Int, value: BN { ... } }
-
-const u: UIntCV = uintCV(10);
-// { type: ClarityType.UInt, value: BN { ... } }
-```
-
-Clarity value ints store their underlying data as `BigNum` values from the [bn.js](https://github.com/indutny/bn.js/) library.
-
-In order to display/print Clarity (u)int values, use the `cvToString(val)` method.
-
-If you wish to perform arithmetic operations using Clarity (u)int values, you must use methods from the `BigNum` api on their underlying `BigNum` values, and the construct a new Clarity value out of the result. For example:
-
-```typescript
-const x = intCV(1);
-const y = intCV(2);
-
-x.value.add(y.value);
-// 3
-```
-
-### Strings
-
-```typescript
-const ascii: StringAsciiCV = stringAsciiCV('hello world');
-// { type: ClarityType.StringASCII, data: 'hello world' }
-
-const utf8: StringUtf8CV = stringUtf8CV('hello 🌾');
-// { type: ClarityType.StringUTF8, data: 'hello 🌾' }
-```
-
-Clarity supports both ascii and utf8 strings.
-
-### Principals
-
-```typescript
-const address = 'SP2JXKMSH007NPYAQHKJPQMAQYAD90NQGTVJVQ02B';
-const contractName = 'contract-name';
-
-const spCV = standardPrincipalCV(address);
-// {
-// type: ClarityType.PrincipalStandard
-// address: {
-// type: StacksMessageType.Address,
-// version: AddressVersion.MainnetSingleSig,
-// hash160: "SP2JXKMSH007NPYAQHKJPQMAQYAD90NQGTVJVQ02B"
-// }
-// }
-
-const cpCV = contractPrincipalCV(address, contractName);
-// {
-// type: ClarityType.PrincipalContract,
-// contractName: {
-// type: StacksMessageType.LengthPrefixedString,
-// content: 'contract-name',
-// lengthPrefixBytes: 1,
-// maxLengthBytes: 128,
-// },
-// address: {
-// type: StacksMessageType.Address,
-// version: AddressVersion.MainnetSingleSig,
-// hash160: "SP2JXKMSH007NPYAQHKJPQMAQYAD90NQGTVJVQ02B"
-// }
-// }
-```
-
-Both kinds of Clarity principal values contain `type` information and an `address` object. Contract principals also contain a `contractName`.
-
-### Response Values
-
-```typescript
-const errCV = responseErrorCV(trueCV());
-// { type: ResponseErr, value: { type: ClarityType.BoolTrue } }
-
-const okCV = responseOkCV(falseCV());
-// { type: ResponseOk, value: { type: ClarityType.BoolFalse } }
-```
-
-Response Clarity Values will either have the type `ClarityType.ResponseOk` or `ClarityType.ResponseErr`. They both contain a Clarity Value. Often this value will be an integer error code if the response is an `Error`.
-
-### Tuples
-
-```typescript
-const tupCV = tupleCV({
- a: intCV(1),
- b: trueCV(),
- c: falseCV(),
-});
-// {
-// type: ClarityType.Tuple,
-// data: {
-// a: { type: ClarityType.Int, value: BN { ... } },
-// b: { type: ClarityType.BoolTrue },
-// c: { type: ClarityType.BoolFalse },
-// }
-// }
-
-console.log(tupCV.data['b']);
-// { type: ClarityType.BoolTrue }
-```
-
-Tuples in Clarity are typed and contain named fields. The tuple above, for example, contains three fields with the names **a**, **b** and **c**, and the types of their values are `Int`, `Boolean` and `Boolean`, respectively.
-
-Clarity tuples are represented in JavaScript as objects and a tuple's data can be accessed by its `data` field, where the underlying JS object is stored.
-
-### Lists
-
-```typescript
-const l = listCV([trueCV(), falseCV()]);
-// { type: ClarityType.List, list: [{ type: ClarityType.BoolTrue }] }
-
-console.log(l.list[0]);
-// { type: ClarityType.BoolTrue }
-```
-
-Lists, in Clarity, are homogeneous, meaning they can only contain elements of a singular (Clarity) type. Make sure to avoid constructing lists that have elements of multiple types.
-
-A Clarity lists underlying data can be accessed via its `list` field.
-
-## Using Clarity Values
-
-Now that you know how to construct _and_ deconstruct Clarity values, you can use them to build `contract-call` transactions that call smart contract functions, and you can utilize their responses.
-
-This is covered in depth [here](../understand-stacks/transactions#construction).
-
-## Utilizing Clarity Values from Transaction Responses
-
-`Read-only` Clarity functions can return Clarity values as a response. These `read-only` functions can be accessed easily in JavaScript via the [`callReadOnlyFunction()`](https://github.com/hirosystems/stacks.js/tree/master/packages/transactions#calling-read-only-contract-function) function included in `@stacks/transactions`, which returns a `ClarityValue`.
-
-As mentioned above, `ClarityValues` are simply javascript objects containing a value and its associated Clarity type information. These object types are defined [here](https://github.com/hirosystems/stacks.js/tree/1f2b5fd8bdf1c2b5866e8171163594d7708a8c7a/packages/transactions/src/clarity/types).
-
-When you are calling a `read-only` contract function, you will always know what type the function will return, since functions in Clarity are strongly typed.
-
-It is common for Clarity functions to return values wrapped in a `Response`, in order to indicate if there was success or an error.
-
-Since every `ClarityValue` has a `type` field, the type of the result of a `read-only` function call can be checked and acted upon like so:
-
-```typescript
-const contractAddress = 'ST3KC0MTNW34S1ZXD36JYKFD3JJMWA01M55DSJ4JE';
-const contractName = 'kv-store';
-const functionName = 'get-value';
-const buffer = bufferCVFromString('foo');
-const network = new StacksTestnet(); // for mainnet, use `StacksMainnet()`
-const senderAddress = 'ST2F4BK4GZH6YFBNHYDDGN4T1RKBA7DA1BJZPJEJJ';
-
-const options = {
- contractAddress,
- contractName,
- functionName,
- functionArgs: [buffer],
- network,
- senderAddress,
-};
-
-// make a read-only call to a contract function that
-// returns a Response
-const result: ResponseCV = await callReadOnlyFunction(options);
-
-if (result.type === ClarityType. ResponseOk) {
- console.log(cvToString(result.value));
-} else if (result.type === ClarityType. ResponseErr) {
- throw new Error(`kv-store contract error: ${result.value.data}`);
-}
-```
-
-### ClarityValues to/from Hex
-
-If you receive a response from a transaction in the form of a `hex` string, you can deserialize it into a Clarity value like so:
-
-```javascript
-import { hexToCV } from '@stacks/transactions';
-
-let cv = hexToCV('hex_string');
-```
-
-Similarly, you can convert a Clarity value to `hex` string like so:
-
-```javascript
-import { cvToHex, trueCV } from '@stacks/transactions';
-
-let trueHex = cvToHex(trueCV());
-```
-
-## Debugging Clarity Values
-
-Sometimes you might receive a Clarity value that you were not expecting. Logging the value to your console won't always prove to be useful, unless you have memorized the Clarity value type enum values.
-
-In order to figure out what kind of value you are dealing with, you can use the `cvToString()` function to convert the Clarity value to a more easily readable string.
-
-For example, calling `cvToString()` on a large `tuple` might yield something like:
-
-```
-(tuple
- (a -1)
- (b u1)
- (c 0x74657374)
- (d true)
- (e (some true))
- (f none)
- (g SP2JXKMSH007NPYAQHKJPQMAQYAD90NQGTVJVQ02B)
- (h SP2JXKMSH007NPYAQHKJPQMAQYAD90NQGTVJVQ02B.test)
- (i (ok true))
- (j (err false))
- (k (list true false))
- (l (tuple (a true) (b false)))
- (m "hello world")
- (n u"hello \u{1234}"))`
-```
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/index.md b/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/index.md
deleted file mode 100644
index 7bce272298..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/index.md
+++ /dev/null
@@ -1,178 +0,0 @@
----
-title: Blochain
-description: Blockchain Stacks
-sidebar_position: 6
----
-
-Vous trouverez ci-dessous un guide pour commencer à travailler localement avec la blockchain.
-
-Le dépôt de code est [ici](https://github.com/stacks-network/stacks-blockchain).
-
-## Commencer avec la Blockchain Stacks
-
-### Download and build stacks-blockchain
-
-La première étape est de s'assurer que Rust et le logiciel de support sont installés.
-
-```bash
-curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
-```
-
-:::info
-Pour compiler sous Windows, suivez les instructions de l'installateur de rustup sur https://rustup.rs/
-:::
-
-From there, you can clone the Stacks Blockchain repository:
-
-```bash
-git clone --depth=1 https://github.com/stacks-network/stacks-blockchain.git
-
-cd stacks-blockchain
-```
-
-Puis construisez le projet :
-
-```bash
-cargo build
-```
-
-Exécutez les tests :
-
-```bash
-cargo test testnet -- --test-threads=1
-```
-
-### Encoder et signer les transactions
-
-Ici, nous allons générer une paire de clés qui sera utilisée pour signer les opérations à venir :
-
-```bash
-cargo run --bin blockstack-cli generate-sk --testnet
-
-# Output
-# {
-# secretKey: "b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001",
-# publicKey: "02781d2d3a545afdb7f6013a8241b9e400475397516a0d0f76863c6742210539b5",
-# stacksAddress: "ST2ZRX0K27GW0SP3GJCEMHD95TQGJMKB7G9Y0X1MH"
-# }
-```
-
-Ce pavé numérique est déjà enregistré dans le fichier `testnet-follower-conf.toml` , donc il peut être utilisé comme présenté ici.
-
-Nous allons interagir avec le contrat simple suivant `kv-store`. In our examples, we will assume this contract is saved to `./kv-store.clar`:
-
-```scheme
-(define-map store { key: (string-ascii 32) } { value: (string-ascii 32) })
-
-(define-public (get-value (key (string-ascii 32)))
- (match (map-get? store { key: key })
- entry (ok (get value entry))
- (err 0)))
-
-(define-public (set-value (key (string-ascii 32)) (value (string-ascii 32)))
- (begin
- (map-set store { key: key } { value: value })
- (ok true)))
-```
-
-Nous voulons publier ce contrat sur la chaîne, puis émettre des transactions qui interagissent avec lui en transférant des clés et en récupérer des valeurs, afin que nous puissions observer la lecture et l'écriture.
-
-Notre première étape est de générer et de signer, à l'aide de votre clé privée, la transaction qui publiera le contrat `kv-store`. Pour cela, nous utiliserons la sous-commande `blockstack-cli` qui a l'usage suivant :
-
-```bash
-blockstack-cli (options) publish [publisher-secret-key-hex] [fee-rate] [nonce] [contract-name] [file-name.clar]
-```
-
-Avec les paramètres suivants:
-
-```bash
-cargo run --bin blockstack-cli publish b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001 515 0 kv-store ./kv-store.clar --testnet
-```
-
-Le `515` correspond aux frais de transaction, libellés en microSTX. Pour l'instant, le réseau de test nécessite un microSTX par octet minimum, et cette transaction devrait être inférieure à 515 octets. Le troisième argument `0` est une nonce, qui doit être augmenté de façon monotonique à chaque nouvelle transaction.
-
-Cette commande affichera le **format binaire** de la transaction. Dans notre cas, nous voulons récupérer cette sortie et la copier dans un fichier qui sera utilisé plus tard dans ce tutoriel.
-
-```bash
-cargo run --bin blockstack-cli publish b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001 515 0 kv-store ./kv-store.clar --testnet | xxd -r -p > tx1.bin
-```
-
-### Exécuter le testnet
-
-Vous pouvez observer la machine d'état en action (localement) en exécutant :
-
-```bash
-cargo stacks-node start --config=./testnet/stacks-node/conf/testnet-follower-conf.toml
-```
-
-`testnet-follower-conf.toml` est un fichier de configuration que vous pouvez utiliser pour mettre en place des balances genesis ou configurer des observateurs d'événements. Vous pouvez accorder à une adresse un solde initial du compte en ajoutant les entrées suivantes:
-
-```
-[[ustx_balance]]
-address = "ST2VHM28V9E5QCRD6C73215KAPSBKQGPWTEE5CMQT"
-amount = 100000000
-```
-
-Le champ `adresse` est l'adresse du réseau de test de Stacks, et le champ `amount` est le nombre de microSTX à y accorder dans le bloc genèse. Les adresses des clés privées utilisées dans le tutoriel ci-dessous sont déjà ajoutées.
-
-### Publiez votre contrat
-
-En supposant que le réseau de test fonctionne, nous pouvons publier notre contrat de `kv-store`.
-
-Dans un autre terminal (ou explorateur de fichiers), vous pouvez déplacer le `tx1.bin` généré plus tôt, vers le mempool:
-
-```bash
-curl -X POST -H "Content-Type: application/octet-stream" --data-binary @./tx1.bin http://localhost:20443/v2/transactions
-```
-
-Dans la fenêtre de terminal exécutant le testnet, vous pouvez observer les réactions de la machine d'état.
-
-### Lecture depuis / Écriture vers le contrat
-
-Maintenant que notre contrat a été publié sur la chaîne, nous allons essayer de soumettre quelques transactions en lecture / écriture. Nous allons commencer par essayer de lire la valeur associée à la clé `foo`.
-
-Pour cela, nous utiliserons la sous-commande :
-
-```bash
-cargo run --bin blockstack-cli contract-call --help
-```
-
-Avec les paramètres suivants:
-
-```bash
-cargo run --bin blockstack-cli contract-call b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001 500 1 ST2ZRX0K27GW0SP3GJCEMHD95TQGJMKB7G9Y0X1MH kv-store get-value -e \"foo\" --testnet | xxd -r -p > tx2.bin
-```
-
-`contract` génère et signe une transaction d'appels contractuels.
-
-Nous pouvons soumettre la transaction en la déplaçant dans le chemin de mempool :
-
-```bash
-curl -X POST -H "Content-Type: application/octet-stream" --data-binary @./tx2.bin http://localhost:20443/v2/transactions
-```
-
-De même, nous pouvons générer une transaction qui définirait la clé `foo` à la valeur `bar`:
-
-```bash
-cargo run --bin blockstack-cli contract-call b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001 500 2 ST2ZRX0K27GW0SP3GJCEMHD95TQGJMKB7G9Y0X1MH kv-store set-value -e \"foo\" -e \"bar\" --testnet | xxd -r -p > tx3.bin
-```
-
-Et soumettez-le en le déplaçant sur le chemin de mempool :
-
-```bash
-curl -X POST -H "Content-Type: application/octet-stream" --data-binary @./tx3.bin http://localhost:20443/v2/transactions
-```
-
-Enfin, nous pouvons effectuer une troisième transaction, en lisant à nouveau la clé `foo` . pour s'assurer que la transaction précédente a bien mis à jour la machine d'état :
-
-```bash
-cargo run --bin blockstack-cli contract-call b8d99fd45da58038d630d9855d3ca2466e8e0f89d3894c4724f0efc9ff4b51f001 500 3 ST2ZRX0K27GW0SP3GJCEMHD95TQGJMKB7G9Y0X1MH kv-store get-value -e \"foo\" --testnet | xxd -r -p > tx4.bin
-```
-
-Et soumettez cette dernière transaction en la déplaçant dans le chemin de mempool :
-
-```bash
-curl -X POST -H "Content-Type: application/octet-stream" --data-binary @./tx4.bin http://localhost:20443/v2/transactions
-```
-
-Félicitations, vous pouvez maintenant [écrire vos propres contrats intelligents avec Clarity](write-smart-contracts/).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/networks.md b/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/networks.md
deleted file mode 100644
index 5118c6a802..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/networks.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Les réseaux de la blockchain Stacks
-description: Les réseaux de la blockchain Stacks
-sidebar_position: 3
----
-
-### Les réseaux de la blockchain Stacks
-
-- [x] **Krypton** est un réseau de test Stacks 2 avec un temps de bloc fixe de deux minutes, appelé `regtest`. Regtest est généralement instable pour une utilisation régulière, et est souvent réinitialisé. Consultez la [documentation du regtest](understand-stacks/testnet) pour plus d'informations sur l'utilisation de regtest.
-
-- [x] **Testnet** (anciennement Xenon) est le réseau de test public de Stacks 2, qui tourne PoX (preuve de transaction) basé sur le réseau de test Bitcoin. C'est l'implémentation complète de la blockchain de Stacks 2, et devrait être considérée comme un réseau de test stable pour le développement de contrats intelligents Clarity . Reportez-vous à [la documentation du testnet](understand-stacks/testnet) pour plus d'informations sur le réseau testnet public.
-
-- [x] **Le réseau principal** est la blockchain de Stacks 2 entièrement fonctionnelle, voir la [vue d'ensemble des Stacks](understand-stacks/) pour plus d'informations sur l'exécution d'un noeud Stacks, le minage, le stacking et l'écriture de contrats intelligents Clarity .
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/stacks-blockchain-api.md b/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/stacks-blockchain-api.md
deleted file mode 100644
index a6cecdac65..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/stacks-blockchain-api.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: API de la blockchain Stacks
-description: Interagir avec la Blockchain Stacks 2.0 via l'API
-sidebar_position: 4
----
-
-## Introduction
-
-:::tip API Documentation La documentation officielle de l'API est disponible [ici](https://stacks-network.github.io/stacks-blockchain/). :::
-
-
-L'API de la Blockchain Stacks 2.0 vous permet de interroger la blockchain Stacks 2.0 et d'interagir avec des contrats intelligents. Il a été construit pour maintenir des vues matérialisées paginables de la blockchain Stacks 2.0.
-
-:::prudence L'API RESTful est développée par Hiro. Hiro héberge également un noeud d'API public pour faciliter l'intégration. L'utiliser nécessite de faire confiance au serveur hébergé, mais offre une expérience d'intégration plus rapide. Vous pouvez [exécuter votre propre serveur API](https://docs.hiro.so/get-started/running-api-node) :::
-
-L'API JSON RESTful peut être utilisée sans aucune autorisation. Le chemin de base de l'API est :
-
-```bash
-# pour mainnet, remplacez `testnet` par `mainnet`
-https://stacks-node-api.testnet.stacks.co/
-```
-
-:::note Cette documentation ne couvre que les points de terminaison qui sont exposés sur un noeud Stacks, appelé l'API RPC. Pour une documentation complète sur l'API RESTful, consultez la [référence de l'API Hiro](https://docs.hiro.so/api). :::
-
-### API RPC d'un noeud Stacks
-
-L' [implémentation de stacks-node](https://github.com/stacks-network/stacks-blockchain/) expose les points d'entrée JSON RPC.
-
-Tous les accès `/v2/` passent par un proxy Stacks hébergé par Hiro. Pour une architecture sans confiance, vous devriez faire ces requêtes à un noeud auto-hébergé.
-
-## Points d'entrée du proxy Hiro pour de l'API RPC Stacks
-
-L'API Stacks 2.0 Blockchain est hébergée de façon centralisée. Cependant, chaque nœud Stacks en cours d’exécution expose une API RPC, qui vous permet d’interagir avec la blockchain. Au lieu d'utiliser une API hébergée de manière centralisée, vous pouvez directement accéder à l'API RPC d'un noeud hébergé localement.
-
-:::tip
-Les proxy API de la Blockchain Stacks vers les points RPC de Node
-:::
-
-Bien que le noeud API RPC ne donne pas les mêmes fonctionnalités que ceux de la Blockchain Stacks API 2.0 , vous obtenez des fonctionnalités similaires d'une manière qui est étendue à ce noeud spécifique. L'API RPC inclut les points d'entrée suivants :
-
-- [POST /v2/transactions](https://docs.hiro.so/api#operation/post_core_node_transactions)
-- [GET /v2/contracts/interface/{contract_address}/{contract_name}](https://docs.hiro.so/api#operation/get_contract_interface)
-- [POST /v2/map_entry/{contract_address}/{contract_name}/{map_name}](https://docs.hiro.so/api#operation/get_contract_data_map_entry)
-- [GET /v2/contracts/source/{contract_address}/{contract_name}](https://docs.hiro.so/api#operation/get_contract_source)
-- [GET /v2/accounts/{principal}](https://docs.hiro.so/api#operation/get_account_info)
-- [POST /v2/contracts/call-read/{contract_address}/{contract_name}/{function_name}](https://docs.hiro.so/api#operation/call_read_only_function)
-- [GET /v2/fees/transfer](https://docs.hiro.so/api#operation/get_fee_transfer)
-- [GET /v2/info](https://docs.hiro.so/api#operation/get_core_api_info)
-
-:::caution Si vous exécutez un noeud local, il expose un serveur HTTP sur le port `20443`. Le point d'accès info serait `localhost:20443/v2/info`. :::
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/stacks-releases.md b/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/stacks-releases.md
deleted file mode 100644
index e95e5df252..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/blockchain/stacks-releases.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Le versions de Stacks
-description: Versions de la Blockchain Stacks
-sidebar_position: 2
----
-
-:::info
-Cette page a besoin de contributions. Aidez-nous de l'améliorer.
-:::
-
-### Versions de la Blockchain Stacks
-
-Toutes les versions sont publiées [ici](https://github.com/stacks-network/stacks-blockchain/releases). Les plus importants sont décrits ci-dessous.
-
-### Stacks 2.1
-
-Disponible à la fin de 2022.
-
-Plus d'informations sur [à quoi s'attendre avec les piles 2.1](https://stacks.org/stacks-21-what-to-expect).
-
-#### Stacks 2.05
-Activé sur le [bloc Bitcoin 713000](https://explorer.stacks.co/txid/0xece8e369310b5ff9b92ef11181ae0d2457ac0c821376d4a96c4998763e22ad04?chain=mainnet).
-
-Cette modification permet de stocker les coûts de la liste en fonction de la longueur réelle et du nombre d'opérations d'E/S indexées. Plus d'infos sur cet [article de blog](https://www.stacks.org/stacks-2-05?ref=docs-website).
-
-#### Stacks 2.0
-Activée le 14 janvier 2021
-
-Ce hardfork permet le stacking, les contrats intelligents Clarity et les transactions évolutives, ainsi que la construction directement sur Bitcoin. Plus d'informations [ici](https://forum.stacks.org/t/path-to-mainnet-for-stx-holders-things-to-know-ahead-of-stacks-2-0/11529).
-
-#### Stacks Genesis
-Publié le 30 octobre 2018, UTC+6 à partir du bloc Bitcoin 547921
-
-Ce hardfork traite de l'enregistrement d'actifs numériques avec jeton Stacks ainsi que la distribution de jetons Stacks aux acheteurs existants. Plus d'informations [ici](https://blog.blockstack.org/the-launch-of-the-stacks-genesis-block/?ref=docs-website).
-
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/deploy-tips.md b/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/deploy-tips.md
deleted file mode 100644
index 0a324e6648..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/deploy-tips.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Aides au déploiement
-description: Apprenez quelques méthodes courantes pour déployer votre application.
----
-
-## Introduction
-
-Les applications Stacks sont des applications web qui authentifient les utilisateurs avec Stacks Auth et stockent des données avec Gaia. Ces deux technologies sont accessibles du côté client. En tant que tel, les applications de Stacks tendent à être simples dans la conception et le fonctionnement. Dans de nombreux cas, ils n’ont pas à héberger quoi que ce soit en dehors des ressources de l’application.
-
-## Où déployer son application
-
-Avant que les utilisateurs puissent interagir avec votre application, vous devez le déployer sur un serveur accessible sur Internet. Le déploiement nécessite que vous :
-
-- Configuriez ou personnalisiez les fichiers dans le répertoire `public`.
-- Construisiez votre site d'application pour le déploiement.
-- Copiez vos fichiers d'application générés sur votre serveur de production.
-
-Si vous avez d'abord bâti votre application avec le générateur d'applications Stacks, votre application contient les blocs de départ pour configurer, construire et déployer votre application. Par exemple, le modèle React possède une structure avec les blocs de construction suivants.
-
-| Fichier ou dossier | Description |
-| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| node_modules/react-scripts | Un ensemble de scripts pour vous aider à démarrer les projets React sans configuration, pour que vous n'ayez pas à configurer votre projet par vous-même. |
-| package.json | Contient une section de scripts qui inclut une référence aux scripts de react, qui sont une dépendance. Ce script crée un répertoire de compilation contenant vos fichiers à déployer. |
-| public/favicon.ico | Un exemple d'icône de raccourci. |
-| public/index.html | Une page d'accueil pour une application. |
-| public/manifest.json | Un fichier JSON qui décrit votre application Web au navigateur. |
-| cors | Contient des exemples de fichiers de déploiement pour la configuration des requêtes multi-origines. |
-
-Si vous utilisez le générateur pour construire votre structure avec JavasScript ou Vue, les fichiers de configuration de votre projet seront différents.
-
-Quel que soit le langage que vous utilisez, vous devez personnaliser et étendre le squelette de base selon les besoins de votre application. Par exemple, vous pourriez vouloir ajouter plus de propriétés au fichier `manifest.json`. Comme chaque application est différente, Stacks Auth ne propose pas d'instructions spécifiques pour le faire. Les étapes que vous définissez sont spécifiques à votre application.
-
-## Authentification Stacks et déploiement
-
-When your application authenticates users with Stacks, the Stacks Wallet at on URL requests a resource (the app manifest) from your DApp. Une requête pour une ressource en dehors du domaine d'origine (le Portefeuille de Stacks) est appelée comme une requête _cross-origin_(CORs). Obtenir des données de cette manière peut être risqué, vous devez donc configurer la sécurité de votre site Web pour permettre des interactions entre les origines.
-
-You can think of CORS interactions as an apartment building with Security. For example, if you need to borrow a ladder, you could ask a neighbor in your building who has one. Security would likely not have a problem with this request (that is, same-origin, your building). If you needed a particular tool, however, and you ordered it delivered from an online hardware store (that is, cross-origin, another site), Security may request identification before allowing the delivery man into the apartment building. (Credit: Codecademy)
-
-The way you configure CORs depends on which company you use to host your web application. The application generator adds a `cors` directory to your application scaffolding. This directory contains files for Netlify (`_headers` and `_redirects`) as well as one for Firebase (`firebase.json`). The configurations in the `cors` directory make your application's `manifest.json` file accessible to other applications (for example, to the Stacks Browser). If you are deploying to a service other than Netlify or Firebase, you must configure CORS on that service to include the following headers when serving `manifest.json`:
-
-```html
-Access-Control-Allow-Origin: * Access-Control-Allow-Headers: "X-Requested-With,
-Content-Type, Origin, Authorization, Accept, Client-Security-Token,
-Accept-Encoding" Access-Control-Allow-Methods: "POST, GET, OPTIONS, DELETE, PUT"
-```
-
-Consult the documentation for your hosting service to learn how to configure CORS on that service.
-
-## Deployment and Radiks
-
-If you are deploying a Stacks application that uses [Radiks](https://github.com/stacks-network/radiks), your deployment includes a server and a database component. You must take this into account when deploying your application. You may want to choose a service such as [Heroku](https://www.heroku.com) or [Digital Ocean](https://www.digitalocean.com) if your app uses Radiks.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/index.md b/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/index.md
deleted file mode 100644
index 23714cba5d..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/index.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Build apps with Stacks
-description: Authenticate users, sign transactions and store data with the Stacks blockchain
-sidebar_position: 3
-sidebar_label: Build apps
----
-
-## Introduction
-
-Apps built with the Stacks blockchain give users control over their digital identities, assets, and data.
-
-Unlike most cloud-based apps, they are "decentralized" since they don't depend on any centralized platform, server, or database to function. Rather, they use the Stacks blockchain to authenticate users and facilitate read and write requests for them without any single point of failure or trust.
-
-Stacks provides three main functions for building apps:
-
-
-
-- **Authentication**: Register and sign users in with identities on the Stacks blockchain
-- **Transaction signing**: Prompt users to sign and broadcast transactions to the Stacks blockchain
-- **Data storage**: Save and retrieve data for users with [Gaia](../gaia)
-
-
-All three of these integrations can be used together to create powerful new user experiences that rival or exceed those of traditional apps—all while protecting your users' digital rights.
-
-While integration is possible for any type of app, most of the resources available here are for web developers experienced with JavaScript. See [Hiro developer docs](https://docs.hiro.so) for more information on the available app development libraries for Stacks.
-
-## [References](references)
-
-[Authentication](references/authentication)
-
-[BNS](references/bns)
-
-[Gaia](../gaia/)
-
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/nocodeclarity.md b/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/nocodeclarity.md
deleted file mode 100644
index 727b4e2163..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/nocodeclarity.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: NoCodeClarity
-description: Launch apps for the Stacks blockchain through no code platforms like Bubble.
----
-
-## Introduction
-
-
-
-[NoCodeClarity](https://nocodeclarity.com) allows people to create applications for the Stacks blockchain without coding.
-
-## Stacks Plug-In on bubble
-
-The [Stacks-No-Code-Plugin](https://bubble.io/plugin/the-stacks-plug-in-1645467277638x949839693014368300) released in May 2022 and it can easily be installed on Bubble with a few clicks allowing users to deploy applications with no coding knowledge. [Bubble](https://bubble.io/blog/explaining-bubble-to-investors/) is the first No Code platform that the Stacks plugin launched on. More platforms are in the roadmap of NoCodeClarity, founded by Christopher Perceptions and Sergio Gongora. The Stacks plugin was created through the support of the Stacks Foundation via a grant in January 2022 and NoCodeClarity was awarded a $100,000 grant in June 2022 to expand the roadmap.
-
-Additional [instructions](https://s3.amazonaws.com/appforest_uf/f1654202471526x991633667675927800/Instructions%20v2.docx.pdf) are also available. Tutorials and step by step guides will be released soon.
-
-The Stacks-No-Code-Plugin code is [publicly available on Github](https://github.com/nocodeclarity/Stacks-No-Code-Plugin).
-
-
-
-## Demo page
-
-A demo page is available [here](https://test-stacks-plugin.bubbleapps.io/version-test).
-
-## NoCodeClarity videos
-
-NodeCodeClarity has their own [youtube channel](https://www.youtube.com/channel/UC9Ep0VQ-GQ-yDzt-wmIElRA).
-
-Videos:
-
-* [NoCodeClarity Setup](https://www.youtube.com/watch?v=WanXlpBGl0w)
-* [NoCodeClarity - Part 1 of the plugin](https://www.youtube.com/watch?v=o6d3hrzNqVI&t=248s)
-* [NoCodeClarity - Part 2 of the plugin](https://www.youtube.com/watch?v=0rzMdsrRg80)
-* [Sneak Peek of the No Code Stacks Wallet Template](https://www.youtube.com/watch?v=Xe6Yv0rF6XM)
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/authentication.md b/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/authentication.md
deleted file mode 100644
index d5233aea7f..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/authentication.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Authentication
-description: Inscription et se connection des utilisateurs avec des identités sur la blockchain de Stacks
----
-
-## Introduction
-
-Ce guide explique comment l'authentification est effectuée sur la blockchain de Stacks.
-
-L'authentification permet aux utilisateurs de s'identifier à une application tout en conservant un contrôle total sur leurs identifiants et leurs informations personnelles. Elle peut être intégré seul ou utilisé en conjonction avec [la signature de transactions](https://docs.hiro.so/get-started/transactions#signature-and-verification) et [le stockage de données](https://docs.stacks.co/gaia/overview), pour lesquels il s'agit d'un prérequis.
-
-Les utilisateurs qui s'inscrivent à votre application peuvent ensuite s'authentifier à n'importe quelle autre application avec le support du [Blockchain Naming System](bns) et vice versa.
-
-## Comment ça fonctionne
-
-Le flux d'authentification avec Stacks est similaire au flux typique client-server utilisé par les services de connexion centralisée (par exemple, OAuth). Cependant, avec les stacks, le flux d'authentification est produit entièrement côté client.
-
-Une application et un authentificateur tels que [le Portefeuille Stacks](https://www.hiro.so/wallet/install-web), communiquent pendant le flux d'authentification en transmettant deux jetons. L'application initiatrice envoie à l'authentificateur un jeton `authRequest`. Une fois qu'un utilisateur approuve l'authentification, l'authentificateur répond à l'application avec un jeton `authResponse`.
-
-Ces jetons sont basés sur [une norme JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519) avec une prise en charge supplémentaire de la courbe `secp256k1` utilisée par Bitcoin et de nombreuses autres crypto-monnaies. Ils sont passés via des requêtes d'URL.
-
-Lorsqu'un utilisateur choisit d'authentifier une application, il envoie le jeton `authRequest` à l'authentificateur via une requête URL avec un paramètre également nommé :
-
-`https://wallet.hiro.so/...?authRequest=j902120cn829n1jnvoa...`
-
-Lorsque l'authentificateur reçoit la requête, il génère un jeton `authResponse` pour l'application en utilisant une _clé de transit éphémère_. La clé de transit éphémère est juste utilisée pour l'instance particulière de l'application, dans ce cas, pour signer la `authRequest`.
-
-L'application stocke la clé de transit éphémère lors de la génération de la requête. La partie publique de la clé de transit est passée dans le jeton `authRequest`. L'authentificateur utilise la partie publique de la clé pour chiffrer une _clé privée de l'application_ qui est retournée via la `authResponse`.
-
-L'authentificateur génère la clé privée de l'application à partir de la _adresse privée de l'utilisateur_ et du domaine de l'application. La clé privée de l'application est utilisée pour trois fonctions :
-
-1. Elle est utilisés pour créer des informations d'identification qui permettent à l'application d'accéder à un seau de stockage (stockage temporaire) dans le hub Gaia de l'utilisateur
-2. Il est utilisé pour le chiffrement de bout en bout des fichiers stockés pour l'application dans le stockage Gaia de l'utilisateur.
-3. Il sert de secret cryptographique que les applications peuvent utiliser pour exécuter d'autres fonctions cryptographiques.
-
-Enfin, la clé privée de l'application est déterministe, ce qui signifie que la même clé privée sera toujours générée pour une adresse et un domaine donnés de Stacks.
-
-Les deux premières de ces fonctions sont particulièrement pertinentes pour le stockage de données [avec Stacks.js](https://docs.stacks.co/docs/gaia).
-
-## Paire de clés
-
-L'authentification avec Stacks utilise largement la cryptographie à clé publique en général et ECDSA avec la courbe `secp256k1` en particulier.
-
-Les sections suivantes décrivent les trois paires de clés publiques privées, y compris la façon dont elles sont générées, où elles sont utilisées et à qui les clés privées sont divulguées.
-
-### Clé privée de transit
-
-La clé de transit privé est une clé éphémère utilisée pour chiffrer les secrets qui doivent passer de l'authentificateur à l'application pendant le processus d'authentification . Elle est générée aléatoirement par l'application au début de la réponse d'authentification.
-
-La clé publique, qui correspond à la clé privée de transit, est stockée dans un simle élément "tableau" dans la clé `public_keys` du jeton de requête d'authentification. L'authentificateur crypte les données secrètes telles que la clé privée de l'application en utilisant cette clé publique et la renvoie à l'application lorsque l'utilisateur se connecte à l'application. La clé privée de transit signe la demande d'authentification de l'application.
-
-### Clé privée de l'adresse d'identité
-
-La clé privée de l'adresse d'identité est dérivée de la phrase porte-clés de l'utilisateur et est la clé privée du nom d'utilisateur dans Stacks que l'utilisateur choisit d'utiliser pour se connecter à l'application. C'est un secret qui appartient à l'utilisateur et qui ne quitte jamais l'instance de l'authentificateur.
-
-Cette clé privée signe le jeton de réponse d'authentification pour une application pour indiquer que l'utilisateur approuve la connexion à cette application.
-
-### Clé privée de l'application
-
-La clé privée de l'application est une clé privée spécifique à l'application qui est générée à partir de la clé privée de l'adresse de l'utilisateur en utilisant le `domain_name` en entrée.
-
-La clé privée de l'application est partagée de manière sécurisée avec l'application pour chaque authentification, chiffrée par l'authentificateur avec la clé publique de transit. Parce que la clé de transit n'est stockée que sur le côté client, cela empêche une attaque de l'homme du milieu où un serveur ou un fournisseur Internet pourrait potentiellement détourner la clé privée de l'application.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/bns.md b/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/bns.md
deleted file mode 100644
index 0af4f6c20b..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/bns.md
+++ /dev/null
@@ -1,247 +0,0 @@
----
-title: Système de nommage de la blockchain
-description: Lier les noms d'utilisateur aux états hors chaîne
----
-
-Le système de nommage Blockchain (BNS) est un système de réseau qui lie les noms d'utilisateur "à l'état hors chaîne" sans s'appuyer sur aucun point de contrôle central.
-
-La blockchain de Stacks V1 a implémenté BNS à travers des opérations de noms de premier ordre (?). Dans les piles V2, le BNS a été remplacé par un contrat intelligent chargé durant le bloc genèse.
-
-Les noms dans BNS ont trois propriétés :
-
-- **Les noms sont globalement uniques.** Le protocole n'autorise pas les collisions de noms, et tous les noeuds de confiance résolvent un nom donné de la même façon.
-- **Les noms sont en langage naturel.** Chaque nom est choisi par son créateur.
-- **Les noms sont inaliénables.** Seul le propriétaire du nom peut changer l'état auquel il se réfère. Plus précisément, un nom est détenu par une ou plusieurs clés privées ECDSA.
-
-La blockchain Stacks assure que la vue BNS de chaque nœud est synchronisée avec tous les autres nœuds du monde, de sorte que les requêtes sur un nœud seront les mêmes sur les autres nœuds. Les nœuds de la blockchain Stacks permettent au propriétaire d'un nom de se lier jusqu'à 40 Ko d'état hors chaîne à leur nom, qui sera répliquée à tous les autres nœuds de blockchain de Stacks via un réseau P2P.
-
-La plus grande conséquence pour les développeurs est qu'en BNS, la lecture de l'état du nom est rapide et bon marché, mais l'écriture de l'état du nom est lente et coûteuse. C'est parce que l'enregistrement et la modification des noms nécessitent d'envoyer une ou plusieurs transactions à la blockchain sous-jacente, et les nœuds BNS ne les traiteront pas jusqu'à ce qu'ils soient suffisamment confirmés. Les utilisateurs et les développeurs ont besoin d'acquérir et de dépenser la cryptomonnaie requise (STX) pour envoyer des transactions BNS.
-
-## Raison d'être des systèmes de nommage
-
-Nous comptons sur les systèmes de nommage dans la vie de tous les jours, et ils jouent un rôle critique dans de nombreuses applications différentes. Par exemple, lorsque vous regardez un ami sur les réseaux sociaux, vous utilisez le système de nommage de la plate-forme pour lier leur nom à leur profil. Lorsque vous consultez un site Web, vous utilisez le Domain Name Service pour résoudre le nom d'hôte à l'adresse IP de son hôte. Lorsque vous consultez une branche Git, vous utilisez votre client Git pour résoudre le nom de la branche à un hachage de livraison. Lorsque vous regardez la clé PGP de quelqu'un sur un serveur de clés, vous résolvez son ID de clé à sa clé publique.
-
-Quelles sortes de choses voulons-nous être vraies en ce qui concerne les noms? En BNS, les noms sont globalement uniques, les noms ont un sens humain, et les noms sont inaliénables. Cependant, si vous regardez ces exemples, vous verrez que chacun d'eux garantit seulement _deux_ de ces propriétés. Cela limite leur utilité.
-
-- Dans le DNS et les médias sociaux, les noms sont globalement uniques et lisibles par l'homme, mais pas uniques. L'opérateur système a le dernier mot l'appartenance de chaque nom.
-
- - **Problème**: Les clients doivent faire confiance au système pour faire le bon choix dans ce qu'un nom donné signifie. Cela inclut la confiance que personne d'autre que les administrateurs système peuvent apporter ces modifications.
-
-- Dans Git, les noms de branches sont en langage humain et irrévocables, mais pas globalement uniques. Deux nœuds Git différents peuvent avoir le même nom de branche appartenant à différents dépôt non liés.
-
- - **Problème**: Puisque les noms peuvent faire référence à un état conflictuel, les développeurs doivent trouver un autre mécanisme pour résoudre les ambiguïtés. Dans le cas de Gitit , l'utilisateur doit intervenir manuellement.
-
-- En PGP, les noms sont des clés d'identification. Ils sont uniques au niveau mondial et sont détenus de manière cryptographique, mais pas lisibles par l'homme. Les identifiants de clés PGP sont dérivés des clés qu'ils référencent.
- - **Problème**: Ces noms sont difficiles à retenir pour la plupart des utilisateurs puisqu'ils ne transmettent pas d'informations sémantiques relatives à leur utilisation dans le système.
-
-Les noms BNS ont les trois propriétés et aucun de ces problèmes. Cela en fait un outil puissant pour construire toutes sortes d'applications réseau. Avec BNS, nous pouvons faire ce qui suit et plus:
-
-- Construire des services de noms de domaine où les noms de domaine ne peuvent pas être détournés.
-- Construire des plateformes de réseaux sociaux où les noms d'utilisateurs ne peuvent pas être volés par des hameçonneurs.
-- Construire des systèmes de contrôle de version où les branches du dépôt ne sont pas en conflit.
-- Construire une infrastructure à clé publique où il est facile pour les utilisateurs de découvrir et se souvenir des clés de chacun.
-
-## Organisation du BNS
-
-Les noms de BNS sont organisés en une hiérarchie globale de noms. Il y a trois couches différentes dans cette hiérarchie liée au nommage :
-
-- **Les espaces de nommage**. Ce sont les noms de premier niveau dans la hiérarchie. Une analogie avec les espaces de noms BNS sont des domaines de premier niveau DNS. Les espaces de noms BNS existants incluent `.id`, `.podcast`, et `.helloworld`. Tous les autres noms appartiennent à exactement un espace de noms. N'importe qui peut créer un espace de noms, mais afin que l'espace de noms soit maintenu, il doit être _launched_ pour que n'importe qui puisse y enregistrer des noms. Les espaces de nommage ne sont pas détenus par leurs créateurs.
-
-- **Les noms BNS**. Ce sont des noms dont les enregistrements sont stockés directement sur la blockchain . La propriété et l'état de ces noms sont contrôlés par l'envoi de transactions blockchain. Les exemples de noms incluent `verified.podcast` et `muneeb.id`. N'importe qui peut créer un nom BNS, à condition que l'espace de noms le contienne déjà.
-
-- **Les sous-domaines BNS**. Ce sont des noms dont les enregistrements sont stockés hors chaîne, mais sont ancrés collectivement dans la blockchain. La propriété et l'état de ces noms vivent dans les données du réseau P2P. Alors que les sous-domaines BNS sont détenus par des clés privées séparées, le propriétaire d'un nom BNS doit diffuser son état de sous-domaine. Les exemples de sous-domaines comprennent `jude.personal.id` et `podsaveamerica.verified.podcast`. Contrairement aux espaces de noms et noms BNS, l'état des sous-domaines BNS ne fait _pas_ partie des règles de consensus de la blockchain.
-
-Une matrice de comparaison de fonctionnalités résumant les similitudes et les différences entre ces objets de nom est présentée ci-dessous:
-
-| Fonctionalité | **Espaces de nommage** | **Noms BNS** | **Sous-domaines BNS** |
-| ------------------------------------------------- | ---------------------- | ------------ | --------------------- |
-| Globalement unique | X | X | X |
-| Langage humain | X | X | X |
-| Détenu par une clé privée | | X | X |
-| Tout le monde peut créer | X | X | [1] |
-| Le propriétaire peut mettre à jour | | X | [1] |
-| État hébergé sur la chaîne | X | X | |
-| Etat hébergé hors de la chaîne | | X | X |
-| Comportement contrôlé par des règles de consensus | X | X | |
-| Peut avoir une date d'expiration | | X | |
-
-[1] Nécessite la coopération d'un propriétaire du nom BNS pour diffuser ses transactions
-
-## Espaces de nommage
-
-Les espaces de noms sont les objets de nommage de premier niveau dans BNS.
-
-Ils contrôlent quelques propriétés inhérentes aux noms :
-
-- Combien coûte leur enregistrement
-- La durée avant de nécessiter leur renouvellement
-- Qui (le cas échéant) reçoit les frais d'enregistrement du nom
-- Qui est autorisé à initialiser l'espace de noms avec ses noms initiaux.
-
-Au moment de cette écriture, le plus grand espace de noms BNS est l'espace de noms `.id` . Les noms de l'espace de noms `.id` sont destinés à résoudre les identités de l'utilisateur . Les noms abrégés en `.id` sont plus chers que les noms longs, et doivent être renouvelés par leurs propriétaires tous les deux ans. Les frais d'enregistrement d'un nom ne sont pas payés à qui que ce soit en particulier ---ils sont plutôt envoyés à un « trou noir » où ils sont rendus inutilisables (l'intention est de décourager les squatteurs d'identification).
-
-Contrairement aux DNS, _n'importe qui_ peut créer un espace de noms et définir ses propriétés. Les espaces de noms sont créés sur la base du premier arrivé, et une fois créés, ils durent pour toujours.
-
-Cependant, la création d'un espace de noms n'est pas libre. Le créateur d'espace de noms doit _brûler_ de la cryptomonnaie pour le faire. Plus l'espace de noms est court, plus la cryptomonnaie doit être brûlée (c'est-à-dire que les espaces de noms courts sont plus précieux que les espaces de noms longs). Par exemple, il a coûté à Blockstack PBC 40 BTC pour créer l'espace de noms `.id` en 2015 (dans la transaction `5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b281`).
-
-Les espaces de noms peuvent contenir entre 1 et 19 caractères, et sont composés des caractères `a-z`, `0-9`, `-`, et `_`.
-
-## Sous-domaines
-
-Les noms des BNS sont fortement détenus car le propriétaire de sa clé privée peut générer des transactions valides qui mettent à jour le hachage et le propriétaire de son fichier de zone. Cependant, cela demande d'obliger le propriétaire du nom à payer la transaction sous-jacente dans la blockchain de . De plus, cette approche limite le taux d'enregistrement des noms BNS et les opérations à la bande passante transactionnelle de la blockchain sous-jacente.
-
-BNS surmonte cela avec des sous-domaines. Un **sous-domaine BNS** est un type de nom BNS dont l'état et le propriétaire sont stockés en dehors de la blockchain, mais dont l'existence et l'historique des opérations sont ancrées dans la blockchain . Comme leurs homologues sur la chaîne, les sous-domaines sont globalement uniques, fortement possédés et en langage humain. BNS leur donne leur propre état de nom et clés publiques. Contrairement aux noms on-chain, les sous-domaines peuvent être créés et gérés à coût réduit, car ils sont diffusés sur le réseau BNS en lots. Une seule transaction blockchain peut envoyer jusqu'à 120 opérations de sous-domaine .
-
-Ceci est réalisé en stockant les enregistrements de sous-domaine dans les fichiers de zone de noms BNS. Un propriétaire de noms on-chain diffuse des opérations de sous-domaine en les encodant en tant qu'enregistrements `TXT` dans un fichier de zone DNS. Pour diffuser le fichier de zone, le nom propriétaire définit le hachage du nouveau fichier de zone avec une transaction `NAME_UPDATE` et réplique le fichier de zone. Ceci réplique, à son tour, toutes les opérations du sous-domaine qu'elle contient, et ancre l'ensemble des opérations de sous-domaine à une transaction sur la chaîne. Les règles de consensus du noeud BNS assurent que seules opérations de sous-domaine valides de \_\_ `transactions NAME_UPDATE` valides ne seront jamais stockées.
-
-Par exemple, le nom `a été vérifié. odcast` une fois écrit le hachage du fichier de zone `247121450ca0e9af45e85a82e61cd525cd7ba023`, qui est le hachage du fichier de zone suivant :
-
-```bash
-$TTL 3600
-1yeardaily TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxeWVhcmRhaWx5CiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMXllYXJkYWlseS9oZWFkLmpzb24iCg=="
-2dopequeens TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAyZG9wZXF1ZWVucwokVFRMIDM2MDAKX2h0dHAuX3RjcCBVUkkgMTAgMSAiaHR0cHM6Ly9waC5kb3Rwb2RjYXN0LmNvLzJkb3BlcXVlZW5zL2hlYWQuanNvbiIK"
-10happier TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMGhhcHBpZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMGhhcHBpZXIvaGVhZC5qc29uIgo="
-31thoughts TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMXRob3VnaHRzCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzF0aG91Z2h0cy9oZWFkLmpzb24iCg=="
-359 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNTkKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8zNTkvaGVhZC5qc29uIgo="
-30for30 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMGZvcjMwCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzBmb3IzMC9oZWFkLmpzb24iCg=="
-onea TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiBvbmVhCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vb25lYS9oZWFkLmpzb24iCg=="
-10minuteteacher TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMG1pbnV0ZXRlYWNoZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMG1pbnV0ZXRlYWNoZXIvaGVhZC5qc29uIgo="
-36questionsthepodcastmusical TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNnF1ZXN0aW9uc3RoZXBvZGNhc3RtdXNpY2FsCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzZxdWVzdGlvbnN0aGVwb2RjYXN0bXVzaWNhbC9oZWFkLmpzb24iCg=="
-_http._tcp URI 10 1 "https://dotpodcast.co/"
-```
-
-Chaque enregistrement `TXT` dans ce fichier de zone encode une création de sous-domaine. Par exemple, `1yeardaily.verified.podcast` se correspond à:
-
-```json
-{
- "address": "1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH",
- "blockchain": "bitcoin",
- "last_txid": "d87a22ebab3455b7399bfef8a41791935f94bc97aee55967edd5a87f22cce339",
- "status": "registered_subdomain",
- "zonefile_hash": "e7acc97fd42c48ed94fd4d41f674eddbee5557e3",
- "zonefile_txt": "$ORIGIN 1yeardaily\n$TTL 3600\n_http._tcp URI 10 1 \"https://ph.dotpodcast.co/1yeardaily/head.json\"\n"
-}
-```
-
-Cette information a été extraite de l'enregistrement de la ressource `1yeardaily` `TXT` dans le fichier de zone pour `verified.podcast`.
-
-### Cycle de vie des sous-domaines
-
-Notez que `1yeardaily.verified.podcast` a une clé publique différente de `verified.podcast`. Un noeud BNS ne traitera une opération de sous-domaine ultérieure le `1yeardy. erified.podcast` que s'il contient une signature de la clé privée de cette adresse. `verified.podcast` ne peut pas générer mises à jour ; seul le propriétaire de `1yeardaily.verified.podcast`. peut le faire
-
-Le cycle de vie d'un sous-domaine et de ses opérations est affiché dans la figure 2.
-
-```
- subdomain subdomain subdomain
- creation update transfer
-+----------------+ +----------------+ +----------------+
-| cicero | | cicero | | cicero |
-| owner="1Et..." | signed | owner="1Et..." | signed | owner="1cJ..." |
-| zf0="7e4..." |<--------| zf0="111..." |<--------| zf0="111..." |<---- ...
-| seqn=0 | | seqn=1 | | seqn=2 |
-| | | sig="xxxx" | | sig="xxxx" |
-+----------------+ +----------------+ +----------------+
- | | |
- | off-chain | |
-~ ~ ~ ~ | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~|~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | ~ ~ ~ ~ ~ ~ ~ ...
- | on-chain | |
- V V (zone file hash ) V
-+----------------+ +----------------+ +----------------+
-| res_publica.id | | jude.id | | res_publica.id |
-| NAME_UPDATE |<--------| NAME_UPDATE |<--------| NAME_UPDATE |<---- ...
-+----------------+ +----------------+ +----------------+
- blockchain blockchain blockchain
- block block block
-
-
-Figure 2 : durée de vie du sous-domaine en ce qui concerne les opérations de noms on-chain . nouvelle
-opération de sous-domaine ne sera acceptée que si elle a un numéro "séquence=" ultérieur,
-et une signature valide en "sig=" sur le corps de la transaction. e champ "sig="
-inclut à la fois la clé publique et la signature, et la clé publique doit être hachée sur
-le champ "addr=" de l'opération précédente de sous-domaine.
-
-Les transactions de création de sous-domaine et de transfert de sous-domaine pour
-"cicero.res_publica.id" sont diffusées par le propriétaire de "res_publica.id".
-Cependant, tout nom sur chaîne ("jude.id" dans ce cas) peut diffuser une mise à jour de sous-domaine
-pour "cicero.res_publica.id".
-```
-
-Les opérations de sous-domaine sont ordonnées par numéro de séquence, à partir de 0. Chaque nouvelle opération de sous-domaine doit inclure :
-
-- Le numéro d'ordre suivant
-- La clé publique qui hache à l'adresse de la précédente transaction de sous-domaine
-- Une signature de la clé privée correspondante sur l'ensemble du sous-domaine opération.
-
-Si deux opérations de sous-domaine correctement signées mais conflictuelles sont découvertes (c.-à-d. ils ont le même numéro de séquence), celui qui se produit plus tôt dans l'histoire de la blockchain est accepté. Les opérations de sous-domaine non valides sont ignorées.
-
-Combiné, cela garantit qu'un noeud BNS avec tous les fichiers de zone avec les opérations d'un sous-domaine donné sera en mesure de déterminer la séquence valide de transitions d'état qu'il a soumises, et déterminez le fichier de zone actuel et le hachage de la clé publique pour le sous-domaine.
-
-### Création et gestion de sous-domaine
-
-Contrairement à un nom on-chaîne, un propriétaire de sous-domaine a besoin de l'aide du propriétaire de noms sur chaîne pour diffuser ses opérations de sous-domaine. En particulier :
-
-- Une transaction de création de sous-domaine ne peut être traitée que par le propriétaire du nom sur qui partage son suffixe. Par exemple, seul le propriétaire de `res_publica.id` peut diffuser des transactions de création de sous-domaine pour les noms de sous-domaine se terminant par `.res_publica.id`.
-- Une transaction de transfert de sous-domaine ne peut être diffusée que par le propriétaire du nom sur la chaîne qui l'a créé. For example, the owner of `cicero.res_publica.id` needs the owner of `res_publica.id` to broadcast a subdomain-transfer transaction to change `cicero.res_publica.id`'s public key.
-- In order to send a subdomain-creation or subdomain-transfer, all of an on-chain name owner's zone files must be present in the Atlas network. Cela permet au noeud BNS de prouver l'\_absence<0> de tout conflit d'opération de création ou de transfert de sous-domaines lors de la création des nouveaux fichiers de zones.
-- # Une transaction de mise à jour de sous-domaine peut être diffusée par _n'importe quel propriétaire de nom sur la chaîne,_ mais le propriétaire du sous-domaine doit trouver celui qui coopérera. Par exemple, le propriétaire de `verified.podcast` peut diffuser une transaction de mise à jour de sous-domaine créée par le propriétaire de `cicero.res_publica.id`.
-- In order to send a subdomain-creation or subdomain-transfer, all of an on-chain name owner's zone files must be present in the Atlas network. This lets the BNS node prove the _absence_ of any conflicting subdomain-creation and subdomain-transfer operations when processing new zone files.
-- A subdomain update transaction can be broadcast by _any_ on-chain name owner, but the subdomain owner needs to find one who will cooperate. For example, the owner of `verified.podcast` can broadcast a subdomain-update transaction created by the owner of `cicero.res_publica.id`.
-
-Cela dit, pour créer un sous-domaine, le propriétaire du sous-domaine génère une opération de création de sous-domaine pour le nom désiré et le donne au propriétaire du nom sur la chaîne.
-
-Une fois créé, un propriétaire de sous-domaine peut utiliser n'importe quel propriétaire de nom sur la chaîne pour diffuser une opération de mise à jour de sous-domaine. Pour ce faire, ils génèrent et signent l'opération de sous-domaine requise et la donnent à un propriétaire de nom sur la chaîne, qui l'empaquete alors avec d'autres opérations de sous-domaine dans un fichier de zone DNS et le diffuse sur le réseau.
-
-Si le sous-propriétaire du sous-domaine veut changer l'adresse de son sous-domaine, il a besoin de signer une opération de transfert de sous-domaine et la donner au propriétaire du nom sur chaîne qui a créé le sous-domaine. Ils l'empaquetent ensuite dans un fichier de zone et diffusent .
-
-### Enregistreurs de sous-domaine
-
-Parce que les noms de sous-domaine sont bon marché, les développeurs peuvent être enclins à exécuter des demandes d'enregistrement de sous-domaine pour le compte de leurs applications. Par exemple, le nom `personal.id` est utilisé pour enregistrer des noms d'utilisateur sans les obliger à faire une transaction Bitcoin.
-
-Nous fournissons une implémentation de référence d'un [Enregistrement BNS ](https://github.com/stacks-network/subdomain-registrar) pour aider les développeurs à diffuser des opérations de sous-domaine. Les utilisateurs posséderaient toujours leurs noms de sous-domaine; le bureau d’enregistrement donne simplement aux développeurs un moyen pratique de les enregistrer et de les gérer dans le contexte d’une application particulière.
-
-# Normes BNS et DID
-
-Les noms BNS sont conformes à la spécification de [de la Fondation d’identité décentralisée](http://identity.foundation) protocole pour les identifiants décentralisés (DID).
-
-Chaque nom dans BNS a un DID associé. Le format DID pour BNS est :
-
-```bash
- did:stack:v0:{address}-{index}
-```
-
-Où :
-
-- `{address}` est un hachage de clé publique sur chaîne (par exemple une adresse Bitcoin).
-- `{index}` fait référence au `nème` nom que cette adresse a créé.
-
-Par exemple, le DID pour `personal.id` est `did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0`, parce que le nom `personal.id` a été le tout premier nom créé par `1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV`.
-
-Comme autre exemple, le DID pour `jude.id` est `did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-1`. Ici, l'adresse `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` avait créé un prénom plus tôt dans l'histoire avant celui-ci (qui se trouve être `abcdefgh123456. d`).
-
-Le but d'un DID est de fournir un identifiant éternel pour une clé publique. La clé publique peut changer, mais le DID ne changera pas.
-
-Stacks Blockchain implémente une méthode DID en elle-même afin d'être compatible avec d'autres systèmes qui utilisent DID pour la résolution de clé publique. Pour qu'un DID soit résolu, tout ce qui suit doit être vrai pour un nom :
-
-- Le nom doit exister
-- Le hachage du fichier de zone du nom doit être le hachage d'un fichier de zone DNS bien formé
-- Le fichier de zone DNS doit être présent dans les données du noeud Stacks.
-- Le fichier de zone DNS doit contenir un enregistrement de la ressource `URI` qui pointe vers un jeton web JSON signé
-- # La clé publique qui a signé le jeton Web JSON (et qui est inclus avec celui-ci) doit être hachée à l'adresse qui est propriétaire du nom
-- The name's zone file hash must be the hash of a well-formed DNS zone file
-- The DNS zone file must be present in the Stacks node's data.
-- The DNS zone file must contain a `URI` resource record that points to a signed JSON Web Token
-- The public key that signed the JSON Web Token (and is included with it) must hash to the address that owns the name
-
-Tous les noms n'auront pas forcément de DIDs qui seront résolus pour les clés publiques. Cependant, les noms créés par l'outil standard auront les DIDs qui le font.
-
-Une API RESTful est en cours de développement.
-
-## Encodage DID pour les sous-domaines
-
-Chaque nom et sous-domaine dans BNS a un DID. L'encodage est un peu différent pour les sous-domaines, donc le logiciel peut déterminer quel façon de coder choisir.
-
-- Pour les noms de BNS on-chain, le `{address}` est le même que l'adresse Bitcoin qui détient le nom. Actuellement, les adresses d'octets de version 0 et d'octets de version 5 sont prises en charge (c.-à-d. adresses commençant par `1` ou `3`, signifiant `p2pkh` et `p2sh` adresses).
-
-- Pour les sous-domaines BNS hors chaîne BNS, le `{address}` a un octet de version 63 pour sous-domaines appartenant à une seule clé privée, et l'octet de version 50 pour les sous-domaines appartenant à un ensemble m-of-n de clés privées. C'est-à-dire que les adresses DID de sous-domaine commencent par `S` ou `M`, respectivement.
-
-Le champ `{index}` pour un DID d'un sous-domaine est distinct du champ `{index}` pour le DID d'un BNS, même si la même chose crée des noms et des sous-domaines. Par exemple, le nom `abcdefgh123456. d` a le DID `did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-0`, parce que c'était le prénom créé par `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg`. Cependant, `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` _a aussi_ créé `jude.statism.id` comme premier nom de sous-domaine. Le DID pour `jude.statism.id` est `did:stack:v0:SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i-0`. Notez que l'adresse `SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i` encode la même clé publique de hachage que l'adresse `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` (la seule différence entre ces deux chaînes est que le premier est codé en base58check avec la version byte 0, et la seconde est encodée avec la version byte 63).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/references.md b/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/references.md
deleted file mode 100644
index 98e9359790..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/build-apps/references/references.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: References
-sidebar_label: References
----
-
-[Authentification](./authentication)
-
-[Systeme de Noms sur Blockchain](./bns)
-
-[Exemple d'applications par Hiro](https://docs.hiro.so/example-apps)
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/contribute/docs.md b/i18n/fr/docusaurus-plugin-content-docs/current/contribute/docs.md
deleted file mode 100644
index 77705451b8..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/contribute/docs.md
+++ /dev/null
@@ -1,207 +0,0 @@
----
-title: Contribute to docs
-description: Learn how this site is built, and how you can contribute to it.
----
-
-## Introduction
-
-Thank you for your interest in contributing and helping make these docs as good as they can be.
-
-This docs site is built on the open source platform [Discosaurus 2](https://docusaurus.io/) and most of its content is written in Markdown files. All of the code for this site is free and open source, located at the [GitHub repository here](https://github.com/stacks-network/docs).
-
-:::tip Don't know what Markdown is? Want to learn? Here is a [helpful guide](https://guides.github.com/features/mastering-markdown/).
-
-Don't want to learn it? No need to. Write [in plain text an issue on Github](https://github.com/stacks-network/docs/issues/new?assignees=&labels=documentation&template=add-documentation.md&title=%5BAdd+docs%5D) :::
-
-:::info You need a free [Github](https://www.github.com) account to add or edit any content. :::
-
-To edit any page, just click on the *Edit this page* button at the bottom of each page and submit your changes online.
-
-To add new content, they are two different ways to do it, the [easy way](#easy-way) and the [advanced way](#advanced-way).
-
-## Easy way
-
-[**Simply click here and enter the text of the article you wish to add.**](https://github.com/stacks-network/docs/issues/new?assignees=&labels=documentation&template=add-documentation.md&title=%5BAdd+docs%5D)
-
-This will open up an issue on github using our template.
-## Advanced way
-
-For more advanced changes you can follow the next steps.
-
-You can also test the site locally using this method.
-### Steps
-
-1. Fork the [docs reposiroty](https://github.com/stacks-network/docs) by clicking on the *Fork* button in the upper right of the screen.
-2. Clone your fork to your local machine with this command `git clone git@github.com:/docs.git stacks_docs`
-3. Enter your project folder `cd stacks_docs`
-4. Create a branch `git checkout -b feat/my-feature-branch`.
-5. You can optionally preview your changes in real time with:
- - `npm install` (to install dependencies).
- - `npx docusaurus start` to start a local copy of the site. A web browser will open at http://localhost:3000, so you can see a preview of yourhanges in real time.
-6. Make the changes you wish and then commit them with this kind of message: `git commit -am "feat: some new feature or content"`.
-7. Push to to GitHub with `git push --set-upstream origin feature/my-feature-branch`.
-8. Visit GitHub and make your pull request.
-
-## Aditional information
-### Running and building the site locally (optional)
-
-You can start the page locally with the following command. This is enough to preview your changes.
-```bash
-npx docusaurus start
-```
-
-Before running this command for the first time you will need to run `npm install` to install dependencies.
-
-The docs site will be accessible at this url: [`http://localhost:3000`](http://localhost:3000).
-
-
-After you finished your changes, you can also build the entire site with the following command (not usually needed):
-```bash
-npm run build
-```
-
-:::tip `npx docusaurus start` will only load the default language (english). To test all languages you can build with `npm run build` and then preview your build with `npm run serve`. :::
-
-### An alternative: Working in browser
-
-As an alterative to working locally, you can also use the web IDE gitpod that provides an environment to contribute directly from within your browser.
-
-You only need to have a github account and open [this link](https://gitpod.io/#https://github.com/stacks-network/docs).
-
-### Folder structure of the site
-
-If you are interested in only adding new documentation content to the site, the files that will be important to you are located within `./docs/*`:
-
-```bash
-docs/
- build-apps
- contribute/
- faq/
- gaia/
- nodes-and-miners/
- noteworthy-contracts/
- references/
- understand-stack/
- write-smart-contracts/
-```
-
-The routing for this site is file based, meaning if you created a folder within `/docs/gaia/` named `testing` and in it a file named `test1.md`, you would be able to navigate to `http://localhost:3000/gaia/testing/test1` and you would see whatever content is in that markdown file.
-
-All the docs in English are stored in the folder `/docs/`.
-
-To add new English content simply add a markdown file (.md) into any subfolder in docs, and it will be automatically displayed in the category of that folder.
-
-All the docs in other languages are stored under the folder `i18n`, but these files should never be edited using GitHub as they are overwritten by Crowdin every time new translations are added. **To make changes in other languages**, you must do so using Crowdin. Please refer to [translations](translations) instead.
-
-### Frontmatter
-
-Frontmatter is the top part of any markdown document that is written in a language called [YAML](https://yaml.org/). It looks like this:
-
-```yaml
----
-title: This is my page title
-description: A short, concise sentence describing what is on this page
----
-```
-
-Frontmatter gives us the ability to define some things within a page that the site can use, such as a page title or page description. When adding any new page, please include a `title` and `description`.
-
-
-
-### Use Conventional Commits
-
-We use the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) as and commits naming convention. Use it while contributing, please.
-
-### Code blocks
-
-To write a code block, you need to wrap your code in ` ```language `, and end your code block with ` ``` `. Here is an example of ` ```clarity `.
-
-```clarity
-(define-data-var counter int 0)
-
-(define-public (get-counter)
- (ok (var-get counter)))
-```
-### Admonitions
-
-You can use the following admonitions to highlight content.
-
-```md
-:::note
-Some **content** with _markdown_ `syntax`.
-:::
-
-:::tip
-Some **content** with _markdown_ `syntax`.
-:::
-
-:::info
-Some **content** with _markdown_ `syntax`.
-:::
-
-:::caution
-Some **content** with _markdown_ `syntax`.
-:::
-
-:::danger
-Some **content** with _markdown_ `syntax`.
-:::
-
-:::tip My personalized title
-Some **content** with _markdown_ `syntax`.
-:::
-```
-
-Which renders:
-
-:::note
-
-Some **content** with _markdown_ `syntax`.
-
-:::
-
-:::tip
-
-Some **content** with _markdown_ `syntax`.
-
-:::
-
-:::info
-
-Some **content** with _markdown_ `syntax`.
-
-:::
-
-:::caution
-
-Some **content** with _markdown_ `syntax`.
-
-:::
-
-:::danger
-
-Some **content** with _markdown_ `syntax`.
-
-:::
-
-:::tip My personalized title
-
-Some **content** with _markdown_ `syntax`.
-
-:::
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/contribute/index.md b/i18n/fr/docusaurus-plugin-content-docs/current/contribute/index.md
deleted file mode 100644
index ac81d899bd..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/contribute/index.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Contribute
-description: Contribute to the Stacks ecosystem.
-sidebar_position: 10
-sidebar_label: "Contribute"
----
-
-You can contribute to the Stacks ecosystem in multiple ways:
-
-
-
-### Documentation
-
-Contribute to the Stacks Docs on this website. More info [here](docs).
-
-### Translations
-
-Help us reach more people with translations. More details [here](translations).
-
-
-
-### Articles
-
-Write an article or a blog post about Stacks. A good place to start is [Stacks Forum](https://forum.stacks.org).
-
-### Github
-
-If you are familiar with Github they are multiple repositories of the Stack Ecosystem that you can contribute to.
-
-- https://github.com/stacks-network/
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/contribute/translations.md b/i18n/fr/docusaurus-plugin-content-docs/current/contribute/translations.md
deleted file mode 100644
index bd9a452333..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/contribute/translations.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Contribute with translations
-description: Want to help tranlating these docs to your local language?
----
-
-## Help with translations
-
-Translations are managed with Crowdin.
-Anybody can colaborate and no technichal skills are required, as it's all done on the browser.
-
-To help with translation please go to [this page](https://crowdin.com/project/docsstacksco), click any language and start translating.
-
-All help is appreciated.
-
-:::caution
-Please don't add any translations to the Github repository, as the translated pages get rewritten from Crowdin. Translations need to be added on Crodin intead.
-:::
-
-### Common issues on translations
-
-When translating in Crowdin, please only translate the texts and not the html code.
-
-If you acccidently modify the html tags you will get errors like shown below (`Seems like some formating tags are missing` or `Translation contains tag that source text doesn't have`). These errors will prevent your translation getting published until the tags are left as they were in the original text.
-
- 
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/faq/faq.md b/i18n/fr/docusaurus-plugin-content-docs/current/faq/faq.md
deleted file mode 100644
index c65bb3b369..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/faq/faq.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: General FAQs
-description: Frequently Asked Questions
-sidebar_label: "FAQ"
-sidebar_position: 10
----
-
-
-
-## Why is my transfer still pending?
-
-Commonly it's because your fee is too low or your [nonce](#what-is-nonce) is incorrect.
-
-More information can be found [here](https://www.hiro.so/wallet-faq/why-is-my-stacks-transaction-pending). There are also [best practices and known issues](https://forum.stacks.org/t/transactions-in-mempool-best-practices-and-known-issues/11659) and [diagnosing pending transactions](https://forum.stacks.org/t/diagnosing-pending-transactions/11908).
-
-There is also this [script](https://github.com/citycoins/scripts/blob/main/getnetworkstatus.js) to look at either the first 200 transactions or all the transactions in the mempool, to then return the maximum adn average fee values. We've noticed that using 1.5-2x the average fee in the mempool will generally get things processed within 6-10 blocks even during high congestion.
-
-There is also this [script](https://github.com/citycoins/scripts/blob/main/gettxstatus.js) to track a pending transaction until it reaches a final status.
-
-## What is Nonce?
-
-A nonce is used to make sure that every transaction goes in right order. Nonce starts at 0, so the very first transaction from an address should set to nonce=0. You can find the nonce of your wallet address by searching the address in any [Stacks blockchain explorer](https://explorer.stacks.co/). You can also user `$ stx balance `.
-
-If you have a transaction nonce that is less than your account nonce, the transaction is unmineable and will (should) disappear after 256 blocks. This does not affect future transactions and therefore can be just ignored, they are in the past.
-
-If you have a transaction nonce that is equal to your account nonce, then that transaction is valid and should be the next in line to be processed next.
-
-If you have a transaction nonce that is higher than your account nonce, then there needs to be a chain of transactions starting with your account nonce in order for it to be processed. E.g. Your account nonce is 10 but the pending transaction has a nonce of 12. It will not be mineable until a transaction with nonces 10 and 11 are processed.
-
-## Whats a Replace-by-fee (RBF)?
-
-A replace-by-fee (RBF) transaction tells the blockchain that you would like to replace one transaction with another, while specifying a fee that is higher than the original transaction fee. A transaction can be replaced with **any other transaction**, and is not limited to the same operation.
-
-This can be used to effectively **cancel a transaction** by replacing it with something else, like a small STX transfer to another owned address.
-
-This can be used to **raise the fee for a pending transaction** so it is considered by miners during periods of high congestion. This can also be used to _resubmit_ a transaction, in the sense that the RBF transaction gets a new txid and gets considered again (or faster) by miners. E.g. I submit my transaction with 1 STX fee at block 54,123. By block 54,133 I see my tx hasn’t been picked up, so I RBF with 1.1 STX. Then wait 10 blocks again, and RBF again if not received. There’s a balance between doing this too often and keeping a consistent pace, but it has been seen to help get transactions through, especially when new ones are constantly flooding in.
-
-The replacement transaction needs to use the same nonce as the original transaction with a fee increase of at least 0.000001 STX. E.g. Your original transaction has a fee of 0.03 STX, the new RBF transaction must have a fee of 0.030001 STX or above.
-
-RBF transactions process in one of two ways:
-
-- If miners pick up the original transaction before the RBF transaction is received, then the original transaction is processed and the replacement transaction goes into an unmineable state. It will eventually disappear and doesn’t affect future transactions.
-- If miners pick up the replaced transaction then the new transaction is processed instead of the original, and the status of the original transaction is set to “droppped_replaced_by_fee”. This status is not shown on the explorer but can be seen when querying the txid.
-
-Submitting multiple transactions for the same action can slow things down in a few ways.
-
-- If the total spent in 2 or 3 transactions is more than can be spent in a single transaction, the transactions appear unmineable.
-- If the fees for multiple transactions exceed the STX balance, the transactions will be unmineable.
-
-## What are .btc domains?
-
-[This forum post](https://forum.stacks.org/t/btc-domains-are-live/12065) explains all the benefits of .btc domains. They can currently be purchased in [btc.us](https://btc.us/)
-
-## What is the blockchain trilemma?
-
-## Stacks vs. Solana vs. Polygon: How Do They Compare From a Developer Perspective?
-
-[This blog post answers the question](https://www.hiro.so/blog/stacks-vs-solana-vs-polygon-how-do-they-compare-from-a-developer-perspective).
-
-## What Does Lightning’s Taro Proposal Mean for Stacks?
-
-[This blog post answers the question](https://www.hiro.so/blog/what-does-lightnings-taro-proposal-mean-for-stacks).
-
-
-## Is Stacks a [PoS chain](https://en.wikipedia.org/wiki/Proof_of_stake)?[¹][]
-
-No.
-
-The act of block production requires an extrinsic expenditure — it is not tied to owning the native token, as would be required in PoS. The only way to produce blocks in the Stacks chain is to transfer Bitcoin to a predetermined randomized list of Bitcoin addresses. Moreover, the Stacks blockchain can fork, and there exists a protocol to rank forks by quality independent of the set of miners and the tokens they hold. These two properties further distinguish it from PoS chains, which cannot fork due to the inability to identify a canonical fork without trusting a 3rd party to decree a particular fork as valid. The ability to fork allows the Stacks blockchain to survive failure modes that would crash a PoS chain.
-
-## Is Stacks a [sidechain](https://en.bitcoin.it/wiki/Sidechain)?[¹][]
-
-No.
-
-For two key reasons.
-
-First, the history of all Stacks blocks produced is recorded to Bitcoin. This means that the act of producing a private Stacks fork is at least as hard as reorging the Bitcoin chain. This in turn makes it so attacks on the chain that rely on creating private forks (such as selfish mining and double-spending) are much harder to carry out profitably, since all honest participants can see the attack coming before it happens and have a chance to apply countermeasures. Sidechains offer no such security benefit.
-
-Second, the Stacks blockchain has its own token; it does not represent pegged Bitcoin. This means that the safety of the canonical fork of the Stacks blockchain is underpinned by its entire token economy’s value, whereas the safety of a sidechain’s canonical fork is underpinned only by whatever system-specific measures incentivize its validators to produce blocks honestly, or the Bitcoin miners’ willingness to process peg-in requests (whichever is the weaker guarantee).
-
-
-## Is Stacks a [layer-2 system](https://academy.binance.com/en/glossary/layer-2) for Bitcoin?[¹][]
-
-No.
-
-Stacks blockchain is a layer-1 blockchain, which uses a novel and unique mining protocol called proof-of-transfer (PoX). A PoX blockchain runs in parallel to another blockchain (Bitcoin in Stacks’ case), which it uses as a reliable broadcast medium for its block headers. It's a sovereign system in its own right. The Stacks blockchain state is distinct from Bitcoin, and is wholly maintained by and for Stacks nodes. Stacks transactions are separate from Bitcoin transactions. Layer-2 systems like Lightning are designed to help scale Bitcoin payment transactions, whereas Stacks is designed to bring new use-cases to Bitcoin through smart contracts. Stacks is not designed as a Bitcoin layer-2 scalability solution.
-
-
-## Is Stacks a [merged-mined chain](https://en.bitcoin.it/wiki/Merged_mining_specification)?[¹][]
-
-No.
-
-The only block producers on the Stacks chain are Stacks miners. Bitcoin miners do not participate in Stacks block validation, and do not claim Stacks block rewards. Moreover, Stacks is not a [blind merged-mined chain](https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki), because STX block winners are public and randomly chosen (instead of highest-bid-wins), and its tokens are minted according to a schedule that is independent of the degree of miner commitment or Bitcoin transferred (instead of minted only by one-way pegs from Bitcoin). This ensures that Stacks is able to make forward progress without opt-in from Bitcoin miners, and it ensures that Stacks miners are adequately compensated for keeping the system alive regardless of transaction volume.
-
-## Whats the difference between Stacks and Ethereum?[²][]
-**Computation and Storage** Stacks does all computation and storage outside of the blockchain, and uses the blockchain only as a “shared source of truth” between clients. By contrast, Ethereum does all computation and most application storage in the blockchain itself. Like Ethereum, if two Stacks nodes see the same underlying blockchain, they will independently run the same computations and produce the same state. Unlike Ethereum, there is no Stacks-specific blockchain.
-
-**Programming Language and Tooling** Stacks’s programming model is based on running off-chain programs. These programs can be written and debugged in any language you want. By contrast, Ethereum’s programming model is based on running on-chain “smart contracts.” These are written and debugged with a whole new set of tools, like Solidity and Serpent. These are written and debugged with a whole new set of tools, like Solidity and Serpent.
-
-**Scalability of On-chain Computation** Stacks is designed around a “virtual chain” concept, where nodes only need to reach consensus on the shared “virtual chain” they’re interested in. Virtual chains do not interact with one another, and a single blockchain can host many virtual chains. Although Stacks’s specific virtual chain is not Turing-complete (i.e. it’s a list of instructions to build the name database), it is possible to create Turing-complete virtual chains like Ethereum. These virtual chains can live in any blockchain for which there exists a driver, and virtual chain clients only need to execute their virtual chain transactions (i.e. Stacks only processes Stacks virtual chain transactions).
-
-By contrast, because smart contracts run on-chain and can call one another, all Ethereum nodes need to process all smart contracts’ computations in order to reach consensus. This can get expensive as the number of running smart contracts grow, which takes the form of gas fee increases.
-
-**Scalability of Off-chain Computation** Stacks applications are very similar to Web applications today and almost never need to interact with the blockchain. For most Stacks applications, the blockchain is only used to authenticate the application’s code and data before the user runs it. By contrast, Ethereum applications usually require an application-specific smart contract, and must interact with the blockchain to carry out its operations.
-
-
-[¹]: https://stacks.org/stacks-blockchain
-[²]: https://forum.stacks.org/t/what-is-the-difference-between-blockstack-and-ethereum/781
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/configuration.md b/i18n/fr/docusaurus-plugin-content-docs/current/gaia/configuration.md
deleted file mode 100644
index a6a530cd70..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/configuration.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Configuration
-description: Configuring Gaia Hub
----
-
-## Configuration files
-
-The following configuration files exist in the folder `deploy/configs/gaia/`:
-
-```
-admin-config.json
-hub-config.json
-reader-config.json
-```
-
-## GAIA Admin Service
-
-You can also use the GAIA Admin Service to remotely administer it with an API Key. It will require you to install `npm` with a `apt install npm`. Once `npm` is installed you can continue with the steps in the [GAIA Admin Service](https://github.com/stacks-network/gaia/blob/master/admin/README.md).
-
-## Driver Selection
-
-The Gaia hub currently supports the following drivers:
-
-```
-'aws' == Amazon S3
-'azure' == Azure Blob Storage
-'disk' == Local disk
-'google-cloud' === Google Cloud Storage
-```
-
-Set the driver you wish to use in your [config.json](https://github.com/stacks-network/gaia/blob/master/hub/config.sample.json) file with the `driver` parameter. Many drivers additionally accept the `bucket` parameter, which controls the bucket name that files should be written to.
-
-These driver may require you to provide additional credentials for performing writes to the backends. See `config.sample.json` for fields for those credentials. In some cases, the driver can use a system configured credential for the backend (e.g., if you are logged into your AWS CLI account, and run the hub from that environment, it won't need to read credentials from your `config.json`).
-
-_Note:_ The disk driver requires a \*nix like filesystem interface, and will not work correctly when trying to run in a Windows environment. :::
-
-## Note on SSL
-
-We _strongly_ recommend that you deploy your Gaia hub with SSL enabled. Otherwise, the tokens used to authenticate with the Gaia hub may be stolen by attackers, which could allow them to execute writes on your behalf.
-Configuration options are available to run the hub with an `https` Node.js server.
-Otherwise, a reverse proxy web server such as nginx or Apache can be used.
-
-## Require Correct Hub URL
-
-If you turn on the `requireCorrectHubUrl` option in your `config.json` file, your Gaia hub will require that authentication requests correctly include the `hubURL` they are trying to connect with. This is used to prevent a malicious gaia hub from using an authentication token for itself on other Gaia hubs.
-
-By default, the Gaia hub will validate that the supplied URL matches `https://${config.serverName}`, but if there are multiple valid URLs for clients to reach the hub at, you can include a list in your `config.json`:
-
-```javascript
-{
- ....
- serverName: "normalserver.com"
- validHubUrls: [ "https://specialserver.com/",
- "https://legacyurl.info" ]
- ....
-}
-```
-
-## The readURL parameter
-
-By default, the gaia hub drivers will return read URLs which point directly at the written content. For example, an S3 driver would return the URL directly to the S3 file. However, if you configure a CDN or domain to point at that same bucket, you can use the `readURL` parameter to tell the gaia hub that files can be read from the given URL. For example, the `hub.blockstack.org` Gaia Hub is configured to return a read URL that looks like `https://gaia.blockstack.org/hub/`.
-
-Unset this configuration parameter if you do not intend to deploy any caching.
-
-## Minimum Proofs Requirement
-
-The gaia hub can also be configured to require a minimum number of social proofs in a user's profile to accept writes from that user. This can be used as a kind of spam-control mechanism. However, we recommend for the smoothest operation of your gaia hub, to set the `proofsConfig.proofsRequired` configuration key to `0`.
-
-## CDN & Replicated Hubs
-
-- https://docs.microsoft.com/en-us/azure/storage/blobs/storage-https-custom-domain-cdn
-
-- The hub implementation is designed to be ran from a single Node.js instance. If the hub instance is sharded (e.g. replicated hubs via load balancing), then any given `bucket` (identified by URI segment) must be served by the same instance, At least a couple elements of the Gaia Hub depend on this: token invalidation in-memory caching, and resource endpoint 409 contention behavior.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/deploy-gaia-hub.md b/i18n/fr/docusaurus-plugin-content-docs/current/gaia/deploy-gaia-hub.md
deleted file mode 100644
index 558cbb14f5..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/deploy-gaia-hub.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Deploy Gaia Hub
-description: Steps and tutorials
----
-
-## Deploy your GAIA hub
-
-Tutorials to deploy your own GAIA hub are currently available for [Linux](./setup-linux), [MacOS](./setup-mac) and [Amazon EC2 / CloudFormation](./gaia-on-ec2).
-
-Regardless of what server the Gaia Hub runs on, the storage it uses can currently be deployed on multiple platforms:
-
-- Local disk (the server itself)
-- Amazon S3
-- Azure Blob Storage
-- Google Cloud
-
-:::tip
-Support for IPFS is under development.
-:::
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/gaia-on-ec2.md b/i18n/fr/docusaurus-plugin-content-docs/current/gaia/gaia-on-ec2.md
deleted file mode 100644
index 2067e7d57c..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/gaia-on-ec2.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Amazon EC2
-description: Use a template to deploy a Gaia hub on Amazon EC2
-tags:
- - tutorial
- - gaia
----
-
-## Introduction
-
-The template provided on this page provides an easy way to deploy a Gaia hub directly to Amazon EC2. You can use this template to deploy your own Gaia hub to your Amazon Web Services (AWS) account. Amazon EC2 is an affordable and convenient cloud computing provider. The template provides a one-click deploy for Amazon EC2 with either S3 or EBS as a storage provider.
-
-## Prerequisites
-
-This procedure uses Amazon CloudFormation to configure an EC2 cloud compute provider to run the Gaia hub service with an S3 or EBS provider for file storage. You should have access to an AWS account either through your personal account or through a corporate account. This account should have permissions to create resources.
-
-Additionally, you must also own a domain name and be able to update the DNS records associated with that domain name.
-
-## Setup steps
-
-### Step 1 - Create Stack
-
-Use a link in the table to launch the [CloudFormation](https://console.aws.amazon.com/cloudformation/) template in the AWS region that you wish to deploy a Gaia hub.
-
-
-
-### Step 2 - Setup stack using template
-
-You need to configure the template with the appropiate values for your hub and domain it runs on.
-
-Select `Template is ready` and `Amazon S3 URL` and enter the following Amazon S3 URL:
-```
-https://s3-external-1.amazonaws.com/cf-templates-vzldibfi2mw8-us-east-1/2022160J6G-cloudformation.yaml
-```
-
-If you prefer you can instead select `Template is ready` and `Upload a template file` to upload the template file `cloudformation.yaml`.
-
-The latest `cloudformation.yaml` file can be downloaded [here](https://raw.githubusercontent.com/stacks-network/gaia/master/deploy/cloudformation.yaml). On most browsers you can right-click on that page and click on `Save page as` to download the file. Alternatively, you can copy/paste the text into a text file called `cloudformation.yaml`.
-
-Then click `Next`.
-
-
-
-### Step 3 - Specify stack details
-
-Specify the stack details and then click `Next`: 
-
-| Field | Value | Notes |
-| --------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| Stack name | _a unique name in your AWS account_ | e.g.: my_gaia_hub |
-| DomainName | _your-domain_ | |
-| EmailAddress | _your email address_ | |
-| GaiaBucketName | _S3 bucket name_ | The template combines this name with the stack name to create a unique S3 bucket. The template ignores this field if GaiaStorageType is set to `disk`. |
-| GaiaStorageType | `s3` or `disk` | Select the GaiaStorageType of which to use as a backend for the Gaia Hub. Selecting `s3` causes the template to create an S3 bucket based on the name given in the previous field. Selecting `disk` causes the template to attach a separate EBS volume to the EC2 instance for Hub storage. |
-| InstaceType | t2.micro | Select the instance type you want. Default value is `t2.micro`. |
-| KeyName | | In the KeyName drop-down, select an [EC2 KeyPair](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#KeyPairs:) to enable SSH access to the EC2 instance. You should download the `.pem` keyfile for this pair from the EC2 console. For more information see the [EC2 key pair documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#prepare-key-pair) |
-| SSHLocation | 0.0.0.0/0 | Leave the SSHLocation field with the default value of `0.0.0.0/0` to enable SSH access from any IP address. If you wish to restrict SSH access to the EC2 instance to a certain IP, you can update this field. |
-| SubnetId | _subnetid_ | Select a public subnet |
-| VpcId | _vpcid_ | |
-
-### Step 4 - Configure stack options
-
-Configure any stack options that fit your desired setup and click `Next`. All these fields are optional.
-
-
-
-### Step 5 - Review
-
-Review the configuration of your Gaia hub, select the checkbox to acknowledge that AWS may create IAM resources with custom names and click on `Create stack`.
-
-
-
-### Step 6 - Retrieve the public IP of your Gaia hub
-
-Your stack can take several minutes to launch. You can monitor the Events tab of your hub to review the current progress of the launch. When the launch is complete, the Outputs tab displays information about the hub. Select the PublicIP and copy it to configure your domain name.
-
-Create an `A` DNS record pointing to the given IP in your domain.
-
-Wait a few minutes for the DNS record to propagate, and your should be able to access your Gaia hub with SSH.
-
-## Accessing your Gaia hub with SSH
-
-To SSH into your Gaia hub EC2 host directly, you must have the keyfile used in container creation. Access the host with the following command in your terminal:
-
-```bash
-ssh -i admin@
-```
-
-:::tip If you can only access SSH with the IP but not with the DNS name and you wish to do so, you can optionally activate it by following these steps:
-
- Open your [AWS Console](https://console.aws.amazon.com)
- Click on `Service` -> VPC
- Open Your VPCs
- Select your VPC connected to your Gaia Hub
- Click `Actions` -> `Edit DNS Hostnames` -> Change `DNS hostnames` to `Enable`
-:::
-## Graphical representation of the cloudformation template
-
-
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/gaia.md b/i18n/fr/docusaurus-plugin-content-docs/current/gaia/gaia.md
deleted file mode 100644
index 1070857350..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/gaia.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Gaia
-description: Decentralized storage architecture for off-chain data
-sidebar_position: 5
-tags:
- - gaia
----
-
-## Introduction
-
-Apps built with the Stacks blockchain store off-chain data using a storage system called Gaia.
-
-Whereas public transactional metadata is best stored on the Stacks blockchain, user application data can often be stored more efficiently and privately in Gaia storage.
-
-Storing data off of the blockchain ensures that Stacks applications can provide users with high performance and high availability for data reads and writes without introducing central trust parties.
-
-:::tip Latest whitepaper of GAIA (May 2022) is available [here](https://dev1-gaia-hub.s3.amazonaws.com/GAIA_Whitepaper.pdf) :::
-
-## Understand Gaia in the Stacks architecture
-
-The following diagram depicts the Stacks architecture and Gaia's place in it:
-
-
-
-Blockchains require consensus among large numbers of people, so they can be slow. Additionally, a blockchain is not designed to hold a lot of data. This means using a blockchain for every bit of data a user might write and store is expensive. For example, imagine if an application were storing every tweet in the chain.
-
-The Stacks blockchain addresses performance problems using a layered approach. The base layer consists of the Stacks blockchain and the Blockchain Naming System (BNS). The blockchain governs ownership of identities in the Stacks network. Identities can be names such as domain names, usernames, or application names.
-
-When an identity is created, its creation is recorded in the Stacks blockchain. Identities make up the primary data stored into the Stacks blockchain. These identities correspond to routing data in the OSI stack. The routing data is stored in the Atlas Peer Network, the second layer. Every core node that joins the Stacks Network is able to obtain an entire copy of this routing data. Stacks uses the routing data to associate identities (domain names, user names, and application names) with a particular storage location in the final layer, the Gaia Storage System.
-
-A Gaia Storage System consists of a _hub service_ and storage resource on a cloud software provider. The storage provider can be any commercial provider such as Azure, DigitalOcean, Amazon EC2, and so forth. Typically the compute resource and the storage resource reside same cloud vendor, though this is not a requirement. Gaia currently has driver support for S3, Azure Blob Storage, Google Cloud Platform and local disk, but the driver model allows for other backend support as well.
-
-Gaia stores data as a simple key-value store. When an identity is created, a corresponding data store is associated with that identity on Gaia. When a user logs into a dApp, the authentication process gives the application the URL of a Gaia hub, which then writes to storage on behalf of that user.
-
-The Stacks blockchain stores only identity data. Data created by the actions of an identity is stored in a Gaia Storage System. Each user has profile data. When a user interacts with a decentralized dApp that application stores application data on behalf of the user. Because Gaia stores user and application data off the blockchain, a Stacks DApp is typically more performant than DApps created on other blockchains.
-
-## User control or how is Gaia decentralized?
-
-A Gaia hub runs as a service which writes to data storage. The storage itself is a simple key-value store. The hub service writes to data storage by requiring a valid authentication token from a requestor. Typically, the hub service runs on a compute resource and the storage itself on separate, dedicated storage resource. Typically, both resources belong to the same cloud computing provider.
-
-
-
-Gaia's approach to decentralization focuses on user control of data and its storage. Users can choose a Gaia hub provider. If a user can choose which Gaia hub provider to use, then that choice is all the decentralization required to enable user-controlled applications. Moreover, Gaia defines a uniform API for applications to access that data.
-
-The control of user data lies in the way that user data is accessed. When an application fetches a file `data.txt` for a given user `alice.id`, the lookup will follow these steps:
-
-1. Fetch the `zonefile` for `alice.id`.
-2. Read her profile URL from her `zonefile`.
-3. Fetch Alice's profile.
-4. _Verify_ that the profile is signed by `alice.id`'s key
-5. Find the read-only url out of the profile's `appsMeta` section (e.g. `https://example-app.gaia.alice.org`).
-6. Fetch the file from `https://example-app.gaia.alice.org/data.txt`.
-
-Because `alice.id` has access to her [zonefile](https://docs.stacks.co/references/bns-contract#name-update), she can change where her profile is stored. For example, she may do this if the current profile's service provider or storage is compromised. To change where her profile is stored, she changes her Gaia hub URL to another Gaia hub URL. If a user has sufficient compute and storage resources, a user may run their own Gaia Storage System and bypass a commercial Gaia hub provider all together.
-
-:::caution
-Users with existing identities cannot yet migrate their data from one hub to another.
-:::
-
-Applications writing directly on behalf of `alice.id` do not need to perform a lookup. Instead, the [Stacks authentication flow](https://stacks.js.org) provides Alice's chosen gaia hub URL to the application. This authentication flow _is also_ within Alice's control because Alice's wallet _must_ generate the authentication response.
-
-## Understand data storage
-
-A Gaia hub stores the written data _exactly_ as given. It offers minimal guarantees about the data. It does not ensure that data is validly formatted, contains valid signatures, or is encrypted. Rather, the design philosophy is that these concerns are client-side concerns.
-
-Client libraries (such as [`Stacks.js`](https://stacks.js.org/)) are capable of providing these guarantees. A liberal definition of the [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end_principle) guides this design decision.
-
-When an application writes to a Gaia hub, an authentication token, key, and the data are passed to the Gaia hub.
-
-
-
-The token ensures the app has the authorization to write to the hub on the user's behalf.
-
-## Gaia versus other storage systems
-
-Here's how Gaia stacks up against other decentralized storage systems. Features that are common to all storage systems are omitted for brevity.
-
-| Features | [Gaia](https://github.com/stacks-network/gaia) | [Sia](https://sia.tech/) | [Storj](https://storj.io/) | [IPFS](https://ipfs.io/) | [DAT](https://datproject.org/) | [SSB](https://www.scuttlebutt.nz/) |
-| ------------------------------------------ | ---------------------------------------------- | ------------------------ | -------------------------- | ------------------------ | ------------------------------ | ---------------------------------- |
-| User controls where data is hosted | X | | | | | |
-| Data can be viewed in a normal Web browser | X | | | X | | |
-| Data is read/write | X | | | | X | X |
-| Data can be deleted | X | | | | X | X |
-| Data can be listed | X | X | X | | X | X |
-| Deleted data space is reclaimed | X | X | X | X | | |
-| Data lookups have predictable performance | X | | X | | | |
-| Writes permission can be delegated | X | | | | | |
-| Listing permission can be delegated | X | | | | | |
-| Supports multiple backends natively | X | | X | | | |
-| Data is globally addressable | X | X | X | X | X | |
-| Needs a cryptocurrency to work | | X | X | | | |
-| Data is content-addressed | | X | X | X | X | X |
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/setup-linux.md b/i18n/fr/docusaurus-plugin-content-docs/current/gaia/setup-linux.md
deleted file mode 100644
index db427f890a..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/setup-linux.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Linux
-description: Steps to setup a GAIA hub on a Linux server (fresh install). This example is using Debian, but should work on any Linux distribution. It uses docker compose in the backgroud.
-tags:
- - tutorial
- - gaia
----
-
-This configuration will setup the following 4 docker containers:
-
-- Nginx with certbot on TCP ports 80 and 443.
-- Gaia hub on TCP port 3000.
-- Gaia admin on TCP port 8009.
-- Gaia reader on TCP port 8008
-
-**1. Update the system and install the dependencies and software we will use to test:**
-
-```bash
-apt update && apt upgrade -y && apt install -y git vim gnupg jq
-```
-
-**2. Install [docker](https://docs.docker.com/engine/install/debian/) and [docker-compose](https://docs.docker.com/compose/cli-command/#install-on-linux)** in your OS.
-For our example we install _docker_ with:
-
-```bash
-curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
-
-echo \
- "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian \
- $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
-
-apt update && apt install -y docker-ce docker-ce-cli containerd.io
-```
-
-Install _docker-compose_ by downloading the [latest-release](https://github.com/docker/compose/releases):
-
-```bash
-VERSION_DC=$(curl --silent https://api.github.com/repos/docker/compose/releases/latest | jq .name -r)
-DESTINATION_DC=~/.docker/cli-plugins
-mkdir -p ${DESTINATION_DC}
-curl -SL https://github.com/docker/compose/releases/download/${VERSION_DC}/docker-compose-linux-x86_64 -o ${DESTINATION_DC}/docker-compose
-chmod +x ${DESTINATION_DC}/docker-compose
-```
-
-**3. Clone the GAIA repository** and enter it's docker directory.
-
-```bash
-git clone https://github.com/stacks-network/gaia.git && cd gaia/deploy/docker
-```
-
-**4. Copy and edit appropiate .env file**.
-In the folder `./deploy/docker/` they are different sample files for different configurations like using aws, azure or disk among others. In this example we will store the data localy so we will copy the _disk_ file and update the domain and email fields. Please change `gaia.site.com` and `gaiarocks@mydomain.com` accordingly. Note you need both for the SSL certificate to be created correctly.
-
-```bash
-export MYGAIADOMAIN=gaia.site.com
-export MYGAIAEMAIL=gaiarocks@mydomain.com
-cp sample-disk.env disk.env
-sed -i 's/my-domain.com/'"$MYGAIADOMAIN"'/g' disk.env
-sed -i 's/my-email@example.com/'"$MYGAIAEMAIL"'/g' disk.env
-
-```
-
-**5. Start GAIA HUB service**
-
-To start GAIA HUB
-
-```bash
-./gaiahub.sh start
-```
-
-To stop GAIA HUB
-
-```bash
-./gaiahub.sh stop
-```
-
-To view GAIA HUB status
-
-```bash
-./gaiahub.sh status
-```
-
-**6. Verify server works locally** with the following command:
-
-```bash
-curl -sk http://localhost/hub_info | jq
-```
-
-A correct result should look similar to this:
-
-```bash
- {
- "challenge_text": "[\"gaiahub\",\"0\",\"gaia-0\",\"blockstack_storage_please_sign\"]",
- "latest_auth_version": "v1",
- "max_file_upload_size_megabytes": 20,
- "read_url_prefix": "https://gaia.site.com/reader/"
- }
-```
-
-**7. Test your GAIA HUB** Running `gaia_test.js` will test your GAIA Hub, by trying to connect to it, uploading a file and downloading it again.
-
-First install all required dependencies with:
-
-```bash
-npm install
-```
-
-Then, from the root folder of the project type:
-
-```bash
-node ./deploy/gaia_test.js https://yourgaiaurl
-```
-
-A correct result will be something like this:
-
-```
-Will run a test for the GAIA HUB: https://gaia.mydomain.com
-Generating some test keys...
-Private key: 5aacc60fc2a429e1f02be139f3cac82061c6a980********************
-Public key: 025691f17f2ab80dc4af363bb9c7aac59e9e1db6ae8ff668202582a3f4ec9678ff
-Address: 15n8Xo8acRvSZghJG2dxJ8dCdzDMYicUuS
-[DEBUG] connectToGaiaHub: https://gaia.mydomain.com/hub_info
-[DEBUG] uploadToGaiaHub: uploading testing.txt to https://gaia.mydomain.com
-File uploaded successfully.
-Upload to gaia hub thinks it can read it from: https://gaia.mydomain.com/reader/15n8Xo8acRvSZghJG2dxJ8dCdzDMYicUuS/testing.txt
-Hub info thinks it can read it from : https://gaia.mydomain.com/reader/15n8Xo8acRvSZghJG2dxJ8dCdzDMYicUuS/testing.txt
-Let's now try to fetch the uploaded file...
-File fetched successfully. Contents of file: GAIA ROCKS!
-```
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/setup-mac.md b/i18n/fr/docusaurus-plugin-content-docs/current/gaia/setup-mac.md
deleted file mode 100644
index 808833b212..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/gaia/setup-mac.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: MacOS
-description: MacOS for local testing/development
-tags:
- - tutorial
----
-
-The following assumes you have [Docker Installed](https://docs.docker.com/docker-for-mac/install/)
-
-- Recommended to also have [MacOS Homebrew](https://docs.brew.sh/Installation) installed
-- Use Homebrew to install jq with `brew install jq`
-
-In your working directory:
-
-**1. Clone a copy of the [gaia repo](https://github.com/stacks-network/gaia):**
-
-```bash
-$ git clone -b master --single-branch https://github.com/stacks-network/gaia
-```
-
-**2. Change your cwd:**
-
-```bash
-$ cd gaia/deploy/docker
-```
-
-**3. Create a copy of sample-disk.env and fill out the values:**
-
-```
-$ cp sample-disk.env disk.env
-# Update the DOMAIN_NAME variable to `localhost`
-```
-
-**4. Start the server:**
-
-```
-$ docker-compose -f docker-compose-base.yaml -f docker-compose-disk.yaml --env-file disk.env up
-```
-
-**5. Verify the server is responding locally:**
-
-```
-$ curl -sk https://localhost/hub_info | jq
- {
- "challenge_text": "[\"gaiahub\",\"0\",\"gaia-0\",\"blockstack_storage_please_sign\"]",
- "latest_auth_version": "v1",
- "max_file_upload_size_megabytes": 20,
- "read_url_prefix": "https://localhost/reader/"
- }
-```
-
-### Modifying the configuration for your gaia-hub
-
-Two methods exist:
-
-1. Edit the `gaia/deploy/configs/gaia/hub-config.json` using `vim` or other
-
-- requires a restart of the containers: `docker-compose -f docker-compose-base.yaml -f docker-compose-disk.yaml --env-file disk.env restart`
-
-2. Use the running `admin` container to modify any config values, and also reload the hub when complete:
-
-- [GitHub - Gaia Admin README.md](https://github.com/stacks-network/gaia/blob/master/admin/README.md)
-
-```
-$ export API_KEY="hello"
-$ curl -s \
- -H "Authorization: bearer $API_KEY" \
- -H 'Content-Type: application/json' \
- -X POST \
- --data-raw '{"serverName": "myserver"}' \
- http://localhost:8009/v1/admin/config
-
-$ curl -s \
- -H "Authorization: bearer $API_KEY" \
- -X POST \
- http://localhost:8009/v1/admin/reload
-
-$ curl -s \
- -H "Authorization: bearer $API_KEY" \
- http://localhost:8009/v1/admin/config | jq
-```
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/governance/_index.md b/i18n/fr/docusaurus-plugin-content-docs/current/governance/_index.md
deleted file mode 100644
index 1ecdf67871..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/governance/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Governance
-description: Governance
-sidebar_position: 9
----
-
-This page needs contributions. Help us write it!
\ No newline at end of file
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/governance/index.md b/i18n/fr/docusaurus-plugin-content-docs/current/governance/index.md
deleted file mode 100644
index 91b0215b5f..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/governance/index.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Governance
-description: Governance
-sidebar_position: 9
----
-
-
-
-This page needs contributions. Help us write it!
-
-Governance in web3 is driven by the community.
-
-How can I get involved ?
-
-[Governance Resources website](https://resources.stacksgov.com)
-
-[Github - Stack Community Governance](https://github.com/stacksgov)
-
-:::tip Community Calls Monthly community calls are recorded and available [here](https://www.youtube.com/playlist?list=PLg717Ri_rTnwwYjQYlc7rIP6x2FaTNn7f) :::
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/governance/sips.md b/i18n/fr/docusaurus-plugin-content-docs/current/governance/sips.md
deleted file mode 100644
index 29ac1ae1ed..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/governance/sips.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: SIPs
-description: SIPs
-sidebar_position: 9
----
-
-## Stacks Improvement Proposals (SIPs)
-
-Stacks improvement proposals (SIPs) are aimed at describing the implementation of the Stacks blockchain, as well as proposing improvements.
-
-The SIP process [(SIP-000)](https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md) describes how to make a SIP and get it ratified.
-
-They should contain concise technical specifications of features or standards and the rationale behind it. SIPs are intended to be the primary medium for proposing new features, for collecting community input on a system-wide issue, and for documenting design decisions.
-
-The SIPs are located in the [stacksgov/sips](https://github.com/stacksgov/sips) repository as part of the [Stacks Community Governance organization](https://github.com/stacksgov).
-
-Anyone in the Stacks community can submit a SIP.
-
-:::tip Stacks Improvement Proposals Community Calls SIP Meeting calls are recorded and available [here](https://www.youtube.com/playlist?list=PLg717Ri_rTnx5kuaWqp3cUAtwQk_yzslT)
-
-More details of the meetings are available [here](https://github.com/stacksgov/sips/issues/79) :::
-
-## Ratified SIPSs
-
-- [x] [SIP 001: Burn Election](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md)
-- [x] [SIP 002: Clarity, a language for predictable smart contracts](https://github.com/stacksgov/sips/blob/main/sips/sip-002/sip-002-smart-contract-language.md)
-- [x] [SIP 003: Peer Network](https://github.com/stacksgov/sips/blob/main/sips/sip-003/sip-003-peer-network.md)
-- [x] [SIP 004: Cryptographic Committment to Materialized Views](https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip-004-materialized-view.md)
-- [x] [SIP 005: Blocks, Transactions, and Accounts](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md)
-- [x] [SIP 006: Clarity Execution Cost Assessment](https://github.com/stacksgov/sips/blob/main/sips/sip-006/sip-006-runtime-cost-assessment.md)
-- [x] [SIP 007: Stacking Consensus](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md)
-- [x] [SIP 008: Clarity Parsing and Analysis Cost Assessment](https://github.com/stacksgov/sips/blob/main/sips/sip-008/sip-008-analysis-cost-assessment.md)
-- [x] [SIP 009: Standard Trait Definition for Non-Fungible Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-009/sip-009-nft-standard.md)
-- [x] [SIP 010: Standard Trait Definition for Fungible Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md)
-- [x] [SIP 012: Burn Height Selection for a Network Upgrade to Introduce New Cost-Limits](https://github.com/stacksgov/sips/blob/main/sips/sip-012/sip-012-cost-limits-network-upgrade.md)
-- [x] [SIP-016: Metadata for Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-016/sip-016-token-metadata.md)
-
-## How to Get Involved
-
-There are several ways you can get involved with the SIP process:
-
-* **Join the weekly SIP Meeting call** listed [here](https://community.stacks.org/events).
-
-* **SIP Editor**. SIP editors help SIP authors make sure their SIPs are well-formed and follow the right process. They help get SIPs ready for deep review by advancing it them from Draft to Accepted status. If you want to become a SIP editor, open an issue with your name and email to ask to be added to the list of SIP editors.
-
-* **Join a CAB** (Consideration Advisory Board). SIPs fall under the purview of one or more considerations. A full list is in [this github](https://github.com/stacksgov/sips/tree/main/considerations) directory. Currently they are: Diversity, Economics, Ethics, Governance and Technical. Members of SIP consideration advisory boards use their domain expertise to give Accepted SIPs a deep read, and give the authors any/all feedback to help make the SIP workable. If you want to join a board, reach out to the board's chairperson via the listed contact information.
-
-* **Steering Committee**. The Steering Committee organizes the consideration advisory boards and votes to advance Recommended SIPs to Activation-in-Progress status, and then to either Ratified or Rejected status. Once they are in the process of being activated, they use a SIP's Activation section to determine whether or not the Stacks ecosystem has ratified or rejected the SIP. Joining this committee requires the consent of the Stacks Foundation board.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/intro.md
deleted file mode 100644
index 7d38997514..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/intro.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-sidebar_label: "Home"
-sidebar_position: 1
----
-
-# Introduction a la Documentation de Stacks
-
-Bienvenue à la documentation officielle de Stacks, apportée par la communautée.
-
-Découvre le minage de Stacks, le jeton STX et le language de programmes Clarity.
-
-
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/digitalocean.md b/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/digitalocean.md
deleted file mode 100644
index dd7194f504..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/digitalocean.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Stacks on DigitalOcean
-description: A guide to setup Stacks on DigitalOcean
-sidebar_position: 4
-tags:
- - tutorial
----
-
-## Introduction
-
-This is a step by step guide to deploy the [Stacks Blockchain on DigitalOcean](https://marketplace.digitalocean.com/apps/stacks-blockchain). Code is hosted on this [Github repository](https://github.com/stacks-network/stacks-blockchain-docker).
-
-## Steps
-
-#### Step 1
-
-Go to the [Stacks Blockchain page](https://marketplace.digitalocean.com/apps/stacks-blockchain) in DigitalOcean's marketplace. Click on `Create Stacks Blockchain Droplet`.
-
-#### Step 2
-
-Choose a plan (it will only allow you to select a plan that meets the minimum requirements) and your prefered datacenter region. 
-
-#### Step 3
-
-Enter a root password or enable SSH keys if your prefer.
-
-
-
-#### Step 4
-
-You can leave the rest of the options as they are and click on `Create Droplet`
-
-#### Step 5
-
-You will need to wait a few seconds for the droplet to get created. Once created click on it to see more information.
-
-
-
-
-
-### Step 6
-
-Congratulations! You are now running the Stacks Blockchain. You can click on `Console` for a terminal window to open or login using SSH to the public IP you've been assigned to with user `root`.
-
- 
-
-## Getting started after deploying Stacks Blockchain
-
-Once droplet is launched, initial startup can take several minutes while BNS data is imported (this is a one time operation).
-
-To keep track of the progress, you can `ssh root@your_droplet_public_ipv4` to the host and run: `/opt/stacks-blockchain-docker/manage.sh -n mainnet -a logs`.
-
-Once the stacks blockchain starts to sync with peers, application ports will open and nginx port 80 will now start proxying requests.
-
-Use `http://your_droplet_public_ipv4` to access the data directly, with output being similar to:
-
-```json
-{
- "server_version": "stacks-blockchain-api v3.0.3 (master:cd0c8aef)",
- "status": "ready",
- "chain_tip": {
- "block_height": 16220,
- "block_hash": "0x3123fba9c0de6b569573494cf83c1d5d198a66bfd5f48ef97949b6bf11ba13be",
- "index_block_hash": "0xeec960fbbd6186b4ccac85ce12adba72be497d881f81e077305c90955b51a6ae"
- }
-}
-```
-
-All services are managed by a [systemd unit file](https://github.com/stacksfoundation/stacks-machine-images/blob/master/files/etc/systemd/system/stacks.service) that is set to start on boot.
-
-Manual control is also possible via the [manage.sh script](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/manage.sh) at `/opt/stacks-blockchain-docker/manage.sh` on the host.
-
-Full details on how to use the manage.sh script is [available here](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/README.md#quickstart).
-
-## API Creation
-
-In addition to creating a Droplet from the Stacks Blockchain 1-Click App via the control panel, you can also use the [DigitalOcean API](https://digitalocean.com/docs/api).
-
-As an example, to create a 4GB Stacks Blockchain Droplet in the SFO2 region, you can use the following curl command. You’ll need to either save your [API access token](https://docs.digitalocean.com/reference/api/create-personal-access-token/) to an environment variable or substitute it into the command below.
-
-```bash
-curl -X POST -H 'Content-Type: application/json' \
- -H 'Authorization: Bearer '$TOKEN'' -d \
- '{"name":"choose_a_name","region":"sfo2","size":"s-2vcpu-4gb","image":"stacksfoundation-stacksblockchain"}' \
- "https://api.digitalocean.com/v2/droplets"
-```
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/index.md b/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/index.md
deleted file mode 100644
index b6cbb9754a..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Nodes and Miners
-description: Nodes and Miners
-sidebar_position: 7
----
-
-Here are all the steps to run nodes and miners, both on mainnet and testnet.
-
-## What's a Stacks node?
-
-## What's a Stacks miner?
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-costs-and-fees.md b/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-costs-and-fees.md
deleted file mode 100644
index 40397a51e0..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-costs-and-fees.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Miner costs and fees
-description: Miner Cost and Fee Estimation
-sidebar_position: 8
----
-
-## Configuring Cost and Fee Estimation
-
-Fee and cost estimators can be configured via the config section `[fee_estimation]`:
-
-```
-[fee_estimation]
-cost_estimator = naive_pessimistic
-fee_estimator = fuzzed_weighted_median_fee_rate
-fee_rate_fuzzer_fraction = 0.1
-fee_rate_window_size = 5
-cost_metric = proportion_dot_product
-log_error = true
-enabled = true
-```
-
-Fee and cost estimators observe transactions on the network and use the observed costs of those transactions to build estimates for viable fee rates and expected execution costs for transactions. Estimators and metrics can be selected using the configuration fields above, though the default values are the only options currently. `log_error` controls whether or not the INFO logger will display information about the cost estimator accuracy as new costs are observed. Setting `enabled = false` turns off the cost estimators. Cost estimators are **not** consensus-critical components, but rather can be used by miners to rank transactions in the mempool or client to determine appropriate fee rates for transactions before broadcasting them.
-
-The `fuzzed_weighted_median_fee_rate` uses a median estimate from a window of the fees paid in the last `fee_rate_window_size` blocks. Estimates are then randomly "fuzzed" using uniform random fuzz of size up to `fee_rate_fuzzer_fraction` of the base estimate.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-mainnet.md b/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-mainnet.md
deleted file mode 100644
index 305ad0b5ca..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-mainnet.md
+++ /dev/null
@@ -1,343 +0,0 @@
----
-title: Mine mainnet Stacks tokens
-description: Set up and run a miner on the Stacks 2.0 mainnet
-sidebar_position: 5
-tags:
- - tutorial
----
-
-## Introduction
-
-Make sure you've followed the [run a node](run-a-node) procedure. Une fois terminé, il ne reste plus que quelques étapes pour faire fonctionner un mineur Proof-of-Burn sur le réseau principal.
-
-If you're interested in mining on the testnet, you can find instructions on how to do that [here](miner-testnet):
-
-If you want to learn more about the technical details of mining, please review the [mining guide](../understand-stacks/mining):
-
-## Running bitcoind locally
-
-To participate as a miner on mainnet, you must have access to a mainnet bitcoin node. One way to accomplish this is to run bitcoind locally. [Ensure your computer meets the minimum hardware requirements before continuing.](https://bitcoin.org/en/bitcoin-core/features/requirements)
-
-First, download the bitcoind software for your platform from https://bitcoin.org/en/download.
-
-Next, start bitcoind with the following configuration:
-
-```toml
-server=1
-rpcuser=your-bitcoind-username
-rpcpassword=your-bitcoind-password
-txindex=0
-listen=1
-rpcserialversion=0
-maxorphantx=1
-banscore=1
-bind=0.0.0.0:8333
-rpcbind=0.0.0.0:8332
-rpcport=8332
-```
-
-Finally, start bitcoind as follows:
-
-```bash
-bitcoind -conf=path/to/bitcoin.conf
-```
-
-It may take a few days for the node to synchronize with the Bitcoin mainnet.
-
-## Exécution d'un mineur
-
-First, a keychain needs to be generated. With this keychain, we'll purchase some BTC from a crytpocurrency exchange, and then use that BTC to start mining.
-
-To get a keychain, the simplest way is to use the `stacks-cli`. We'll use the `make_keychain` command.
-
-```bash
-npx @stacks/cli make_keychain 2>/dev/null | json_pp > keychain.txt
-```
-
-After this runs, you should see some JSON in the new `keychain.txt` file that looks like this:
-
-```json
-{
- "mnemonic": "exhaust spin topic distance hole december impulse gate century absent breeze ostrich armed clerk oak peace want scrap auction sniff cradle siren blur blur",
- "keyInfo": {
- "privateKey": "2033269b55026ff2eddaf06d2e56938f7fd8e9d697af8fe0f857bb5962894d5801",
- "address": "STTX57EGWW058FZ6WG3WS2YRBQ8HDFGBKEFBNXTF",
- "btcAddress": "mkRYR7KkPB1wjxNjVz3HByqAvVz8c4B6ND",
- "index": 0
- }
-}
-```
-
-**Don't lose this information** - we'll need to use the `privateKey` field later on.
-
-The above BTC address will then need to be imported into the BTC network.
-
-```bash
-bitcoin-cli -rpcport=8332 -rpcuser=your-user -rpcpassword=your-password importaddress
-```
-
-
-
-Once imported, we need to get some BTC to that address. You should be able to transfer BTC to this address using a crytpocurrency exchange such as [Coinbase](https://www.coinbase.com), [Binance](https://www.binance.com), or [Kraken](https://www.kraken.com).
-
-
-
-Now, we need to configure our node to use this Bitcoin keychain. Clone the [stacks-blockchain repository](https://github.com/stacks-network/stacks-blockchain) to your local machine if you haven't already. In the `stacks-blockchain` folder, modify the file at [`testnet/stacks-node/conf/mainnet-miner-conf.toml`](https://github.com/stacks-network/stacks-blockchain/blob/master/testnet/stacks-node/conf/mainnet-miner-conf.toml).
-
-Mettez à jour les propriétés suivantes :
-
-```toml
-[node]
-...
-# Enter your private key here
-seed = "replace-with-your-private-key"
-local_peer_seed = "replace-with-your-private-key"
-...
-
-[burnchain]
-...
-# To mine on mainnet, you need to run bitcoind locally
-# Details can be found in above section, 'Running bitcoind locally'
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-...
-```
-
-Now, grab your `privateKey` from earlier, when you ran the `make_keychain` command. Replace the `seed` field with your private key. Save and close this configuration file.
-
-To run your miner, run this in the command line:
-
-```bash
-stacks-node start --config=./testnet/stacks-node/conf/mainnet-miner-conf.toml
-```
-
-Your node should start. It will take some time to sync, and then your miner will be running.
-
-### Creating an optimized binary
-
-The steps above are great for trying to run a node temporarily. If you want to host a node on a server somewhere, you might want to generate an optimized binary. To do so, use the same configuration as above, but run:
-
-```bash
-cd testnet/stacks-node
-cargo build --release --bin stacks-node
-```
-
-The above code will compile an optimized binary. To use it, run:
-
-```bash
-cd ../..
-./target/release/stacks-node start --config=./mainnet-miner-conf.toml
-```
-
-To read more about the technical details of mining on the Stacks 2.0 network, have a look at [the mining guide](../understand-stacks/mining).
-
-### Enable debug logging
-
-In case you are running into issues or would like to see verbose logging, you can run your node with debug logging enabled. In the command line, run:
-
-```bash
-STACKS_LOG_DEBUG=1 stacks-node mainnet
-```
-
-## Running a miner in Windows
-
-### Prerequisites
-
-Make sure are [running a node](run-a-node) and [running bitcoind locally](#running-bitcoind-locally) before starting this tutorial.
-
-### Generate keychain and get mainnet tokens in Windows
-
-To setup the miner, first we need to generate a keychain. With this keychain, we'll purchase some BTC from a crytpocurrency exchange, and then use that BTC to start mining.
-
-To get a keychain, the simplest way is to use the `stacks-cli`. To get a keychain, the simplest way is to use the `stacks-cli`.
-
-Generate a keychain:
-
-```bash
-npm install --global @stacks/cli
-stx make_keychain > cli_keychain.json
-type cli_keychain.json
-```
-
-After this runs, you'll probably see some installation logs, and at the end you should see some JSON that looks like this:
-
-```json
-{
- "mnemonic": "exhaust spin topic distance hole december impulse gate century absent breeze ostrich armed clerk oak peace want scrap auction sniff cradle siren blur blur",
- "keyInfo": {
- "privateKey": "2033269b55026ff2eddaf06d2e56938f7fd8e9d697af8fe0f857bb5962894d5801",
- "address": "STTX57EGWW058FZ6WG3WS2YRBQ8HDFGBKEFBNXTF",
- "btcAddress": "mkRYR7KkPB1wjxNjVz3HByqAvVz8c4B6ND",
- "index": 0
- }
-}
-```
-
-:::tip Check out the [Stacks CLI reference](https://docs.hiro.so/references/stacks-cli) for more details :::
-
-The above BTC address will then need to be imported into the BTC network.
-
-```bash
-bitcoin-cli -rpcport=8332 -rpcuser=your-user -rpcpassword=your-password importaddress
-```
-
-Once imported, we need to get some BTC to that address. You should be able to transfer BTC to this address using a crytpocurrency exchange such as [Coinbase](https://www.coinbase.com), [Binance](https://www.binance.com), or [Kraken](https://www.kraken.com).
-
-### Update configuration file
-
-Now, we need to configure our node to use this Bitcoin keychain. Clone the [stacks-blockchain repository](https://github.com/stacks-network/stacks-blockchain) to your local machine if you haven't already. In the `stacks-blockchain` folder, modify the file at [`testnet/stacks-node/conf/mainnet-miner-conf.toml`](https://github.com/stacks-network/stacks-blockchain/blob/master/testnet/stacks-node/conf/mainnet-miner-conf.toml).
-
-Mettez à jour les propriétés suivantes :
-
-```toml
-[node]
-...
-# Enter your private key here
-seed = "replace-with-your-private-key"
-local_peer_seed = "replace-with-your-private-key"
-...
-
-[burnchain]
-...
-# To mine on mainnet, you need to run bitcoind locally
-# Details can be found in above section, 'Running bitcoind locally'
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-...
-```
-
-Now, grab your `privateKey` from earlier, when you ran the `stx make_keychain` command. Replace the seed field with your private key. Save and close this configuration file.
-
-### Run the miner
-
-To start your miner, run this in the command line:
-
-```bash
-stacks-node start --config=testnet/stacks-node/conf/mainnet-miner-conf.toml
-```
-
-:::note
-While starting the node for the first time, windows defender might pop up with a message to allow access. If so, allow access to run the node.
-::: 
-
-Your node should start. It will take some time to sync, and then your miner will be running.
-
-### Enable debug logging in Windows
-
-In case you are running into issues or would like to see verbose logging, you can run your node with debug logging enabled. In the command line, run:
-
-```bash
-set RUST_BACKTRACE=full;
-set STACKS_LOG_DEBUG=1;
-stacks-node start --config=mainnet-miner-conf.toml
-```
-
-## Optional: Running with Docker
-
-Alternatively, you can run the mainnet node with Docker.
-
-:::caution Ensure you have [Docker](https://docs.docker.com/get-docker/) installed on your machine. :::
-
-### Generate keychain and get tokens
-
-Generate a keychain:
-
-```bash
-docker run -i node:14-alpine npx @stacks/cli make_keychain 2>/dev/null
-```
-
-We need to get some BTC to that address. You should be able to transfer BTC to this address using a crytpocurrency exchange such as [Coinbase](https://www.coinbase.com), [Binance](https://www.binance.com), or [Kraken](https://www.kraken.com).
-
-### Update configuration file
-
-Now, we need to configure our node to use this Bitcoin keychain. Clone the [stacks-blockchain repository](https://github.com/stacks-network/stacks-blockchain) to your local machine if you haven't already. In the `stacks-blockchain` folder, modify the file at [`testnet/stacks-node/conf/mainnet-miner-conf.toml`](https://github.com/stacks-network/stacks-blockchain/blob/master/testnet/stacks-node/conf/mainnet-miner-conf.toml).
-
-Mettez à jour les propriétés suivantes :
-
-```toml
-[node]
-...
-# Enter your private key here
-seed = "replace-with-your-private-key"
-local_peer_seed = "replace-with-your-private-key"
-...
-
-[burnchain]
-...
-# To mine on mainnet, you need to run bitcoind locally
-# Details can be found in above section, 'Running bitcoind locally'
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-...
-```
-
-Now, grab your `privateKey` from earlier, when you ran the `stx make_keychain` command. Replace the seed field with your private key. Save and close this configuration file.
-
-### Start the miner
-
-:::info The ENV VARS `RUST_BACKTRACE` and `STACKS_LOG_DEBUG` are optional. If removed, debug logs will be disabled :::
-
-```bash
-docker run -d \
- --name stacks_miner \
- --rm \
- --network host \
- -e RUST_BACKTRACE="full" \
- -e STACKS_LOG_DEBUG="1" \
- -v "$(pwd)/testnet/stacks-node/conf/mainnet-miner-conf.toml:/src/stacks-node/mainnet-miner-conf.toml" \
- -p 20443:20443 \
- -p 20444:20444 \
- blockstack/stacks-blockchain:latest \
-/bin/stacks-node start --config /src/stacks-node/mainnet-miner-conf.toml
-```
-
-You can review the node logs with this command:
-
-```bash
-docker logs -f stacks_miner
-```
-
-## Optional: Running in Kubernetes with Helm
-
-In addition, you're also able to run a mainnet node in a Kubernetes cluster using the [stacks-blockchain Helm chart](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
-
-Ensure you have the following prerequisites installed on your machine:
-
-- [Docker](https://docs.docker.com/get-docker/)
-- [minikube](https://minikube.sigs.k8s.io/docs/start/) (Only needed if standing up a local Kubernetes cluster)
-- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-- [helm](https://helm.sh/docs/intro/install/)
-
-### Generate keychain and get some tokens
-
-Generate a keychain:
-
-```bash
-docker run -i node:14-alpine npx @stacks/cli make_keychain 2>/dev/null
-```
-
-We need to get some BTC to that address. You should be able to transfer BTC to this address using a crytpocurrency exchange such as [Coinbase](https://www.coinbase.com), [Binance](https://www.binance.com), or [Kraken](https://www.kraken.com).
-
-### Install the chart and run the miner
-
-To install the chart with the release name `my-release` and run the node as a miner:
-
-```bash
-minikube start # Only run this if standing up a local Kubernetes cluster
-helm repo add blockstack https://charts.blockstack.xyz
-helm install my-release blockstack/stacks-blockchain \
- --set config.node.miner=true \
- --set config.node.seed="replace-with-your-privateKey-from-generate-keychain-step" \
- --set config.burnchain.mode="mainnet"
-```
-
-You can review the node logs with this command:
-
-```bash
-kubectl logs -l app.kubernetes.io/name=stacks-blockchain
-```
-
-For more information on the Helm chart and configuration options, please refer to the [chart's homepage](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-testnet.md b/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-testnet.md
deleted file mode 100644
index fbc4c25f00..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/miner-testnet.md
+++ /dev/null
@@ -1,336 +0,0 @@
----
-title: Mine testnet Stacks tokens
-description: Set up and run a miner on the Stacks 2.0 testnet
-sidebar_position: 4
-tags:
- - tutorial
----
-
-## Introduction
-
-Make sure you've followed the [Run a node](run-a-node) procedure. Once completed it's only a few more steps to run a proof-of-burn miner on the testnet.
-
-If you want to learn more about the technical details of mining, please review the [mining guide](../understand-stacks/mining).
-
-## Running bitcoind locally
-
-To participate as a miner on Testnet, you must have access to a testnet bitcoin node. One way to accomplish this is to run bitcoind locally. [Ensure your computer meets the minimum hardware requirements before continuing.](https://bitcoin.org/en/bitcoin-core/features/requirements)
-
-First, download the bitcoind software for your platform from https://bitcoin.org/en/download.
-
-Next, start bitcoind with the following configuration:
-
-```toml
-server=1
-rpcuser=your-bitcoind-username
-rpcpassword=your-bitcoind-password
-testnet=1
-txindex=0
-listen=1
-rpcserialversion=0
-maxorphantx=1
-banscore=1
-
-[test]
-bind=0.0.0.0:18333
-rpcbind=0.0.0.0:18332
-rpcport=18332
-```
-
-Finally, start bitcoind as follows:
-
-```bash
-bitcoind -conf=path/to/bitcoin.conf
-```
-
-It may take a few hours for the node to synchronize with the Bitcoin testnet.
-
-## Exécution d'un mineur
-
-First, a keychain needs to be generated. With this keychain, we'll get some testnet BTC from a faucet, and then use that BTC to start mining.
-
-To get a keychain, the simplest way is to use the `stacks-cli`. To get a keychain, the simplest way is to use the `stacks-cli`.
-
-```bash
-npx @stacks/cli make_keychain -t 2>/dev/null | json_pp > keychain.txt
-```
-
-After this runs, you should see some JSON in the new `keychain.txt` file that looks like this:
-
-```json
-{
- "mnemonic": "exhaust spin topic distance hole december impulse gate century absent breeze ostrich armed clerk oak peace want scrap auction sniff cradle siren blur blur",
- "keyInfo": {
- "privateKey": "2033269b55026ff2eddaf06d2e56938f7fd8e9d697af8fe0f857bb5962894d5801",
- "address": "STTX57EGWW058FZ6WG3WS2YRBQ8HDFGBKEFBNXTF",
- "btcAddress": "mkRYR7KkPB1wjxNjVz3HByqAvVz8c4B6ND",
- "index": 0
- }
-}
-```
-
-**Don't lose this information** - we'll need to use the `privateKey` field later on.
-
-The above BTC address will then need to be imported into the BTC testnet network.
-
-```bash
-bitcoin-cli -rpcport=18332 -rpcuser=your-user -rpcpassword=your-password importaddress
-```
-
-Once imported, we need to get some testnet BTC to that address. Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/). You'll be sent `0.01` testnet BTC to that address.
-
-Now, we need to configure our node to use this Bitcoin keychain. Clone the [stacks-blockchain repository](https://github.com/stacks-network/stacks-blockchain) to your local machine if you haven't already. In the `stacks-blockchain` folder, modify the file at [`testnet/stacks-node/conf/testnet-miner-conf.toml`](https://github.com/stacks-network/stacks-blockchain/blob/master/testnet/stacks-node/conf/testnet-miner-conf.toml).
-
-Mettez à jour les propriétés suivantes :
-
-```toml
-[node]
-...
-seed = "replace-with-your-private-key"
-local_peer_seed = "replace-with-your-private-key"
-...
-
-[burnchain]
-...
-# To mine on Testnet, you need to run bitcoind locally
-# Details can be found in above section, 'Running bitcoind locally'
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-...
-```
-
-Now, grab your `privateKey` from earlier, when you ran the `make_keychain` command. Replace the `seed` field with your private key. Save and close this configuration file.
-
-To run your miner, run this in the command line:
-
-```bash
-stacks-node start --config=./testnet/stacks-node/conf/testnet-miner-conf.toml
-```
-
-Your node should start. It will take some time to sync, and then your miner will be running.
-
-### Creating an optimized binary
-
-The steps above are great for trying to run a node temporarily. If you want to host a node on a server somewhere, you might want to generate an optimized binary. To do so, use the same configuration as above, but run:
-
-```bash
-cd testnet/stacks-node
-cargo build --release --bin stacks-node
-```
-
-The above code will compile an optimized binary. To use it, run:
-
-```bash
-cd ../..
-./target/release/stacks-node start --config=./testnet/conf/testnet-follower-conf.toml
-```
-
-To read more about the technical details of mining on the Stacks 2.0 network, have a look at [the minig guide](../understand-stacks/mining):
-
-### Enable debug logging
-
-In case you are running into issues or would like to see verbose logging, you can run your node with debug logging enabled. In the command line, run:
-
-```bash
-STACKS_LOG_DEBUG=1 stacks-node testnet
-```
-
-## Running a miner in Windows
-
-### Prerequisites
-
-Make sure are [running a testnet node](run-a-node) before starting this tutorial.
-
-### Generate keychain and get testnet tokens in Windows
-
-To setup the miner, first, we need to generate a keychain. With this keychain, we'll get some testnet BTC from a faucet, and then use that BTC to start mining.
-
-To get a keychain, the simplest way is to use the `stacks-cli`. We'll use the `stx make-keychain` command, and pass `-t` to indicate that we want a testnet keychain.
-
-Generate a keychain:
-
-```bash
-npm install --global @stacks/cli
-stx make_keychain -t > cli_keychain.json
-type cli_keychain.json
-```
-
-After this runs, you'll probably see some installation logs, and at the end you should see some JSON that looks like this:
-
-```json
-{
- "mnemonic": "exhaust spin topic distance hole december impulse gate century absent breeze ostrich armed clerk oak peace want scrap auction sniff cradle siren blur blur",
- "keyInfo": {
- "privateKey": "2033269b55026ff2eddaf06d2e56938f7fd8e9d697af8fe0f857bb5962894d5801",
- "address": "STTX57EGWW058FZ6WG3WS2YRBQ8HDFGBKEFBNXTF",
- "btcAddress": "mkRYR7KkPB1wjxNjVz3HByqAvVz8c4B6ND",
- "index": 0
- }
-}
-```
-
-:::tip Check out the [Stacks CLI reference](https://docs.hiro.so/references/stacks-cli) for more details :::
-
-Request BTC from faucet:
-
-We need to get some testnet BTC to that address. Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/). Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/).
-
-### Update configuration file
-
-Now, we need to configure our node to use this Bitcoin keychain. Clone the [stacks-blockchain repository](https://github.com/stacks-network/stacks-blockchain) to your local machine if you haven't already. In the `stacks-blockchain` folder, modify the file at [`testnet/stacks-node/conf/testnet-miner-conf.toml`](https://github.com/stacks-network/stacks-blockchain/blob/master/testnet/stacks-node/conf/testnet-miner-conf.toml).
-
-Mettez à jour les propriétés suivantes :
-
-```toml
-[node]
-...
-seed = "replace-with-your-private-key"
-local_peer_seed = "replace-with-your-private-key"
-...
-
-[burnchain]
-...
-# To mine on Testnet, you need to run bitcoind locally
-# Details can be found in above section, 'Running bitcoind locally'
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-...
-```
-
-Now, grab your `privateKey` from earlier, when you ran the `stx make_keychain` command. Replace the seed field with your private key. Save and close this configuration file.
-
-### Run the miner
-
-To start your miner, run this in the command line:
-
-```bash
-stacks-node start --config=testnet/stacks-node/conf/testnet-miner-conf.toml
-```
-
-
-
-:::note
-While starting the node for the first time, windows defender might pop up with a message to allow access. If so, allow access to run the node.
-::: 
-
-
-
-Your node should start. It will take some time to sync, and then your miner will be running.
-
-### Enable debug logging in Windows
-
-In case you are running into issues or would like to see verbose logging, you can run your node with debug logging enabled. In the command line, run:
-
-```bash
-set RUST_BACKTRACE=full;
-set STACKS_LOG_DEBUG=1;
-stacks-node start --config=testnet-miner-conf.toml
-```
-
-## Optional: Running with Docker
-
-Alternatively, you can run the testnet node with Docker.
-
-:::warning Ensure you have [Docker](https://docs.docker.com/get-docker/) installed on your machine. :::
-
-### Generate keychain and get testnet tokens
-
-Generate a keychain:
-
-```bash
-docker run -i node:14-alpine npx @stacks/cli make_keychain -t 2>/dev/null
-```
-
-We need to get some testnet BTC to that address. Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/). Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/).
-
-### Update config file
-
-Now, we need to configure our node to use this Bitcoin keychain. Clone the [stacks-blockchain repository](https://github.com/stacks-network/stacks-blockchain) to your local machine if you haven't already. In the `stacks-blockchain` folder, modify the file at [`testnet/stacks-node/conf/testnet-miner-conf.toml`](https://github.com/stacks-network/stacks-blockchain/blob/master/testnet/stacks-node/conf/testnet-miner-conf.toml).
-
-Mettez à jour les propriétés suivantes :
-
-```toml
-[node]
-...
-seed = "replace-with-your-private-key"
-local_peer_seed = "replace-with-your-private-key"
-...
-
-[burnchain]
-...
-# To mine on Testnet, you need to run bitcoind locally
-# Details can be found in above section, 'Running bitcoind locally'
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-...
-```
-
-Now, grab your `privateKey` from earlier, when you ran the `stx make_keychain` command. Replace the seed field with your private key. Save and close this configuration file.
-
-### Start the miner
-
-:::info The ENV VARS `RUST_BACKTRACE` and `STACKS_LOG_DEBUG` are optional. If removed, debug logs will be disabled :::
-
-```bash
-docker run -d \
- --name stacks_miner \
- --rm \
- --network host \
- -e RUST_BACKTRACE="full" \
- -e STACKS_LOG_DEBUG="1" \
- -v "$(pwd))/testnet/stacks-node/conf/testnet-miner-conf.toml:/src/stacks-node/testnet-miner-conf.toml" \
- -p 20443:20443 \
- -p 20444:20444 \
- blockstack/stacks-blockchain:latest \
-/bin/stacks-node start --config /src/stacks-node/testnet-miner-conf.toml
-```
-
-You can review the node logs with this command:
-
-```bash
-docker logs -f stacks_miner
-```
-
-## Optional: Running in Kubernetes with Helm
-
-In addition, you're also able to run a testnet node in a Kubernetes cluster using the [stacks-blockchain Helm chart](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
-
-Ensure you have the following prerequisites installed on your machine:
-
-- [Docker](https://docs.docker.com/get-docker/)
-- [minikube](https://minikube.sigs.k8s.io/docs/start/) (Only needed if standing up a local Kubernetes cluster)
-- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-- [helm](https://helm.sh/docs/intro/install/)
-
-### Generate keychain and get some testnet tokens
-
-Generate a keychain:
-
-```bash
-docker run -i node:14-alpine npx @stacks/cli make_keychain -t 2>/dev/null
-```
-
-We need to get some testnet BTC to that address. Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/). Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/).
-
-### Install the chart and run the miner
-
-To install the chart with the release name `my-release` and run the node as a miner:
-
-```bash
-minikube start # Only run this if standing up a local Kubernetes cluster
-helm repo add blockstack https://charts.blockstack.xyz
-helm install my-release blockstack/stacks-blockchain \
- --set config.node.miner=true \
- --set config.node.seed="replace-with-your-privateKey-from-generate-keychain-step"
-```
-
-You can review the node logs with this command:
-
-```bash
-kubectl logs -l app.kubernetes.io/name=stacks-blockchain
-```
-
-For more information on the Helm chart and configuration options, please refer to the [chart's homepage](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/run-a-node.md b/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/run-a-node.md
deleted file mode 100644
index 94d938c5ca..0000000000
--- a/i18n/fr/docusaurus-plugin-content-docs/current/nodes-and-miners/run-a-node.md
+++ /dev/null
@@ -1,351 +0,0 @@
----
-title: Run a node
-description: Set up and run a Stacks node
-sidebar_position: 1
-tags:
- - tutorial
----
-
-## Stacks Blockchain with Docker
-
-Run your own Stacks Blockchain node easily with just few commands.
-
-This tutorial describes a simple and effective [quickstart](#quickstart) to run a Stacks node using public scripts hosted in [Stacks Blockchain repository](https://github.com/stacks-network/stacks-blockchain-docker). Valid for mainnet, testnet and mocknet.
-
-## **Quickstart**
-
-1. **Clone the stacks-blockchain-docker repository locally**
-
-```bash
-git clone https://github.com/stacks-network/stacks-blockchain-docker && cd stacks-blockchain-docker
-```
-
-2. **Optionally, create/copy `.env` file**. If file `.env` doesn't exist when launched it will be created from `sample.env` automatically.
-
-```bash
-cp sample.env .env
-```
-
-_You may also use a symlink as an alternative to copying: `ln -s sample.env .env`_
-
-3. **Optionally, ensure all images are up to date**
-
-```bash
-./manage.sh -n -a pull
-```
-
-4. **Start the Services**
-
-```bash
-./manage.sh -n -a start
-```
-
-- With optional proxy:
-
-```bash
-./manage.sh -n -a start -f proxy
-```
-
-- With optional bitcoin node:
-
-```bash
-./manage.sh -n -a start -f bitcoin
-```
-
-5. **Stop the Services**
-
-```bash
-./manage.sh -n -a stop
-```
-
-6. **Retrieve Service Logs**
-
-```bash
-./manage.sh -n -a logs
-```
-
-- Export docker log files to `./exported-logs`:
-
-This will create one log file for every running service, for example: postgres.log, stacks-blockain.log, stacks-blockchain-api.log and bitcoin-core.log.
-Notice that each time you run this command the log files will be overwritten.
-
-```bash
-./manage.sh -n -a logs export
-```
-
-7. **Restart all services**
-
-```bash
-./manage.sh -n -a restart
-```
-
-- With optional proxy:
-
-```bash
-./manage.sh -n -a restart -f proxy
-```
-
-8. **Delete** all data in `./persistent-data/` and/or data of the Bitcoin blockchain.
-
- This data is owned by root, so you will need to run it with sudo privileges so it can delete the data.
-
-```bash
-$ sudo ./manage.sh -n -a reset
-
-Please confirm what persistent data you wish to delete:
-
-0. Cancel
-1. Delete Persistent data for Stacks testnet only and leave Bitcoin blockchain data unaffected.
-2. Delete Persistent data for Stacks testnet and Bitcoin blockchain data in ./persistent-data/blockchain-bitcoin
-3. Delete Persistent data for Bitcoin blockchain data in ./persistent-data/blockchain-bitcoin only.
-Please note that BNS data will never get deleted.
-
-Type 0, 1, 2 or 3: 2
-
-Ok. Delete Stacks and Bitcoin data.
-[ Success ] Persistent data deleted for Bitcoin blockchain.
-[ Success ] Persistent data deleted for Stacks testnet.
-
-```
-
-9. **Download BNS data to** `./persistent-data/bns-data`
-
-```bash
-./manage.sh bns
-```
-
-10. **Export stacks-blockchain-api events** (_Not applicable for mocknet_)
-
-```bash
-./manage.sh -n -a export
-# check logs for completion
-./manage.sh -n -a restart
-```
-
-11. **Replay stacks-blockchain-api events** (_Not applicable for mocknet_)
-
-```bash
-./manage.sh -n -a import
-# check logs for completion
-./manage.sh -n -a restart
-```
-
-## **Running also a bitcoin node (Optional)**
-
-Stacks needs to use a Bitcoin node, and by default when you run a Stacks node you will be using a public Bitcoin node, which is configured in the `.env` file. Default values is `BITCOIN_NODE=bitcoin.mainnet.stacks.org`.
-
-However, you can optionaly run both nodes together and configured in a way that you Stacks node will use your own Bitcoin node instead of a public one.
-
-If you run the script with a bitcoin node it will download and build it directly from source for increased security. This process which only needs to happen once can take up to 20-30 minutes depending on the speed of your system. Also, once the bitcoin node is up and running it will need an additional time for sync for the first time (can be hours for testnet and days for mainnet).
-
-### Why run Stacks node with your own Bitcoin node?
-
-Because running your own Bitcoin node will give you higher security and improved perfomance.
-
-* **Improved perfomance**: The Bitcoin node will serve you blocks faster, as well as UTXOs for your miner (if you run one).
-* **Higher security**: The Bitcoin node will also have validated all bitcoin transactions the Stacks node consumes. If you don't run your own Bitcoin node, you're relying on the SPV headers to vouch for the validity of Bitcoin blocks.
-
-The disadvantage of running your own Bitcoin node is that you need the extra space to store the Bitcoin blockchain (about 500GB) and the initial time it will take to download this data the first time.
-
-### Example
-
-You can run easily run your Stacks node with your own Bitcoin node by adding the flag `bitcoin`. This is available only for testnet and mainnet.
-
-Example: `./manage.sh -n mainnet -a start -f bitcoin` or `./manage.sh -n testnet -a start -f bitcoin`
-
-### Bitcoin node configuration
-
-In the `.env` file there is the variable `BITCOIN_BLOCKCHAIN_FOLDER`. As the bitcoin blockchain can be large (over 500GB) you optionally change this variable to any location of your choosing. If you have previously used the [bitcoin core application](https://bitcoin.org/en/bitcoin-core/) and already have the bitcoin blockchain synced, you can use the same data folder and avoid redownloading the entire bitcoin blockchain.
-
-## **Accessing the services**
-
-:::tip For networks other than `mocknet`, downloading the initial headers can take several minutes. Until the headers are downloaded, the `/v2/info` endpoints won't return any data.
-
-Use the command `./manage.sh -n -a logs` to check the sync progress. :::
-
-**stacks-blockchain**:
-
-- Ports `20443-20444` are exposed to `localhost`
-
-```bash
-curl -sL localhost:20443/v2/info | jq
-```
-
-**stacks-blockchain-api**:
-
-- Port `3999` are exposed to `localhost`
-
-```bash
-curl -sL localhost:3999/v2/info | jq
-```
-
-**proxy**:
-
-- Port `80` is exposed to `localhost`
-
-```bash
-curl -sL localhost/v2/info | jq
-curl -sL localhost/ | jq
-```
-
----
-
-## Upgrades
-
-⚠️ For upgrades to running instances of this repo, you'll need to [run the event-replay](https://github.com/hirosystems/stacks-blockchain-api#event-replay):
-
-```bash
-./manage.sh -n -a stop
-./manage.sh -n -a export
-./manage.sh -n -a import
-./manage.sh -n -a restart
-```
-
----
-
-## **Workarounds to potential issues**
-
-_**Port(s) already in use**_:
-
-- If you have a port conflict, typically this means you already have a process using that same port.\
- To resolve, find the port you have in use (i.e. `3999` and edit your `.env` file to use the new port.
-
-```bash
-netstat -anl | grep 3999
-```
-
-```
-tcp46 0 0 *.3999 *.* LISTEN
-```
-
-_**Containers not starting (hanging on start)**_:
-
-- Occasionally, docker can get **stuck** and not allow new containers to start. If this happens, simply restart your docker daemon and try again.
-
-_**Database Issues**_:
-
-- For any of the various Postgres/sync issues, it may be easier to simply remove the persistent data dir. Note that doing so will result in a longer startup time as the data is repopulated.
-
-```bash
-./manage.sh -n