diff --git a/docs/dev/v2/contracts/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md b/docs/dev/v2/contracts/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md index 47c22793..2407d552 100644 --- a/docs/dev/v2/contracts/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md +++ b/docs/dev/v2/contracts/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md @@ -80,7 +80,7 @@ function recordUsedAllowanceOf( * [`controllerOf`](/docs/dev/v2/contracts/jbdirectory/properties/controllerof.md) * [`overflowAllowanceOf`](/docs/dev/v2/contracts/or-controllers/jbcontroller/read/overflowallowanceof.md) * [`token`](/docs/dev/v2/contracts/or-payment-terminals/or-abstract/jbsingletokenpaymentterminal/properties/token.md) -4. Make sure there's enough allowance left to accomodate the new used amount. +4. Make sure there's enough allowance left to accommodate the new used amount. ``` // Make sure the new used amount is within the allowance. diff --git a/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/addtobalance.md b/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/addtobalance.md index 048e4c3c..79123341 100644 --- a/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/addtobalance.md +++ b/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/addtobalance.md @@ -21,7 +21,7 @@ event AddToBalance( ``` * `projectId` is the ID of the project who received any leftover funds after splits were paid out. -* `beneficiary` is the address that received the project's tokens, or recieved the leftover funds if there was no project ID. +* `beneficiary` is the address that received the project's tokens, or received the leftover funds if there was no project ID. * `token` is the token that was paid. * `amount` is the amount that was paid, as a fixed point number. * `decimals` is the amount of decimals in the amount. diff --git a/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/pay.md b/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/pay.md index 2947d783..5d2b76d3 100644 --- a/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/pay.md +++ b/docs/dev/v2/contracts/or-utilities/jbetherc20splitspayer/events/pay.md @@ -23,7 +23,7 @@ event Pay( ``` * `projectId` is the ID of the project who received any leftover funds after splits were paid out. -* `beneficiary` is the address that received the project's tokens, or recieved the leftover funds if there was no project ID. +* `beneficiary` is the address that received the project's tokens, or received the leftover funds if there was no project ID. * `token` is the token that was paid. * `amount` is the amount that was paid, as a fixed point number. * `decimals` is the amount of decimals in the amount. diff --git a/docs/dev/v3/build/treasury-extensions/data-source.md b/docs/dev/v3/build/treasury-extensions/data-source.md index fcf7c052..faffcb98 100644 --- a/docs/dev/v3/build/treasury-extensions/data-source.md +++ b/docs/dev/v3/build/treasury-extensions/data-source.md @@ -136,7 +136,7 @@ contract AllowlistDataSource is IJBFundingCycleDataSource { { if (!allowed[_data.payer]) revert NOT_ALLOWED(); - // Forward the recieved weight and memo, and use no delegate. + // Forward the received weight and memo, and use no delegate. return (_data.weight, _data.memo, IJBPayDelegate(address(0))); } diff --git a/docs/dev/v3/build/treasury-extensions/pay-delegate.md b/docs/dev/v3/build/treasury-extensions/pay-delegate.md index 97d94a28..fcdb9269 100644 --- a/docs/dev/v3/build/treasury-extensions/pay-delegate.md +++ b/docs/dev/v3/build/treasury-extensions/pay-delegate.md @@ -76,7 +76,7 @@ contract NFTPayDelegate is ERC721, IJBFundingCycleDataSource, IJBPayDelegate { IJBPayDelegate delegate ) { - // Forward the recieved weight and memo, and use this contract as a pay delegate. + // Forward the received weight and memo, and use this contract as a pay delegate. return (_data.weight, _data.memo, IJBPayDelegate(address(this))); } diff --git a/docs/dev/v3/deprecated/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md b/docs/dev/v3/deprecated/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md index c8bf7602..e741bf7e 100644 --- a/docs/dev/v3/deprecated/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md +++ b/docs/dev/v3/deprecated/jbsingletokenpaymentterminalstore/write/recordusedallowanceof.md @@ -80,7 +80,7 @@ function recordUsedAllowanceOf( * [`controllerOf`](/docs/dev/v3/api/contracts/jbdirectory/properties/controllerof.md) * [`overflowAllowanceOf`](/docs/dev/v3/deprecated/or-controllers/jbcontroller/read/overflowallowanceof.md) * [`token`](/docs/dev/v3/api/contracts/or-payment-terminals/or-abstract/jbsingletokenpaymentterminal/properties/token.md) -4. Make sure there's enough allowance left to accomodate the new used amount. +4. Make sure there's enough allowance left to accommodate the new used amount. ``` // Make sure the new used amount is within the allowance. diff --git a/town-hall/2022-06-07/index.md b/town-hall/2022-06-07/index.md index ca44e928..051edeb1 100644 --- a/town-hall/2022-06-07/index.md +++ b/town-hall/2022-06-07/index.md @@ -31,7 +31,7 @@ So we're now minting this thing through the website which is cool. The stuff is **jango**: We need V1 > V2 migration to do it for JuiceboxDAO. We can deploy this for an arbitrary project though. We can launch a new project and just has it work there, so you can start minting stuff, just as normal treasury and lock it there, at which point there's not much difference between test and rinkeby as we currently are. But to get the JuiceboxDAO version of this and the Bannyverse version at least from a ecosystem perspective, we need to get V1 > V2 migration, and then there might be other technical things along the way. -**Jmill**: From a front end perspective, there are a couple of things that would be helpful so that there's some kind of indexing data you can easily pull user's NFT statistics. That's a more simple and scalable way to do with subgraph query. It would be really usefull if the ve NFT contract deployer also deploy a single consolidated metadata file. Let's say veBanny has 60 characters and they all have a name and staking ranges, it'll be really nice that the contract generate that as one file that front end could grab and parse to display without going to 60 metadata files individually. That would be a quality-of-life thing from the contract side for the front end. +**Jmill**: From a front end perspective, there are a couple of things that would be helpful so that there's some kind of indexing data you can easily pull user's NFT statistics. That's a more simple and scalable way to do with subgraph query. It would be really useful if the ve NFT contract deployer also deploy a single consolidated metadata file. Let's say veBanny has 60 characters and they all have a name and staking ranges, it'll be really nice that the contract generate that as one file that front end could grab and parse to display without going to 60 metadata files individually. That would be a quality-of-life thing from the contract side for the front end. **tankbottoms**: We could add another function for that metadata, basically something that will conform with an NFT but also has pointers to all assets you need, because you can pick them through the JSONs however you want. @@ -55,7 +55,7 @@ I'm certainly with you that we have a lot of work to do with explaining what peo I think now we're definitely buckling for more long term investments both from a building perspective and the relationship perspective with other communities. I'm eager to see how that project chart changes over time. I think from my personal perspective and talking to projects, the recent lows haven't been very encouraging for projects to launch. But now that V2 is out, we're going to see a lot more of that. -**nicholas**: When I did onboarding with Austin from BuildGuild and he had some feedback about simplifying. It's a little bit difficult for someone on the outside to know exactly which simplifying approach will be successfull on the market aside from just iterating on simplifying the existing one. But I do have some suspicion that there are a larger category of people who are not so inclined to use Juicebox in its current form but might be inclined to do so for this example we're talking couple of times about NFT collections, splitting off a portion of their primary and/or secondary to Juicebox and letting the holders manage it, which doodles, cryptopunks and a bunch of other projects already do. That's a category I'm super interested in getting on the creation flow for that. It could be just like presets on what we've already got, or maybe an entirely separate creation flow where you can imagine entirely different front ends that just make creation really tight for a specific use case and then you can go use Juicebox.money's full advanced front end and subsequently managing those things but make it easier for people to get onboard. It could be pretty integrated at Juicebox.money. There's a lot to explore. +**nicholas**: When I did onboarding with Austin from BuildGuild and he had some feedback about simplifying. It's a little bit difficult for someone on the outside to know exactly which simplifying approach will be successful on the market aside from just iterating on simplifying the existing one. But I do have some suspicion that there are a larger category of people who are not so inclined to use Juicebox in its current form but might be inclined to do so for this example we're talking couple of times about NFT collections, splitting off a portion of their primary and/or secondary to Juicebox and letting the holders manage it, which doodles, cryptopunks and a bunch of other projects already do. That's a category I'm super interested in getting on the creation flow for that. It could be just like presets on what we've already got, or maybe an entirely separate creation flow where you can imagine entirely different front ends that just make creation really tight for a specific use case and then you can go use Juicebox.money's full advanced front end and subsequently managing those things but make it easier for people to get onboard. It could be pretty integrated at Juicebox.money. There's a lot to explore. **filipv**: One thng that we've discussed that might be interesting would be if there's a way to easily import and export project configurations which Austin Griffith originally brought up, for exporting a project that was made on testnet to mainnet. That might be cool because you can use that feature to set up templates that have base project configurations. diff --git a/town-hall/2022-12-06/index.md b/town-hall/2022-12-06/index.md index cea95957..ac57885f 100644 --- a/town-hall/2022-12-06/index.md +++ b/town-hall/2022-12-06/index.md @@ -13,7 +13,7 @@ Art by [Sage Kellyn](https://twitter.com/SageKellyn) This is something Jango has been thinking about for a while, seeing it in different context, and something he has been trying to take as a lens to view through proposal in previous funding cycles. It's the idea about our current decisions in spending, in versioning the protocol to different improved contracts, in suggesting front end to also follow suit in other clients, as well as the protocol fees and the JBX token issuance. -There seem to be a pressure to expand them in one direction to grow it out and accomodate more thing, more people, more expenditures and more commitments. But on the other side, there is also a pressure to reduce it down towards zero, which means to shrink it and to essentially create few points of governance fragility and JBX decision making, and instead to have a techologically more stable treasury that projects aren't expecting changes while their fees are consistently tending downwards, neither do they have any real working party commitments to it. +There seem to be a pressure to expand them in one direction to grow it out and accommodate more thing, more people, more expenditures and more commitments. But on the other side, there is also a pressure to reduce it down towards zero, which means to shrink it and to essentially create few points of governance fragility and JBX decision making, and instead to have a techologically more stable treasury that projects aren't expecting changes while their fees are consistently tending downwards, neither do they have any real working party commitments to it. Both these two pressures make sense. It's just piecing together where we already are in the progress of this development effort and operation effort as of JuiceboxDAO and Juicebox protocol, and where we want to go. And ackonwledging that if we want to go towards zero, sometimes we have to think about how to get there sustainably. In a network's context, sustainability means the network should work and has properties to support new members or new projects to learn how to help something flourish. diff --git a/town-hall/2023-01-17/index.md b/town-hall/2023-01-17/index.md index 8e9913c9..93e1ba82 100644 --- a/town-hall/2023-01-17/index.md +++ b/town-hall/2023-01-17/index.md @@ -75,7 +75,7 @@ Jmill and Genekogan came to our town hall introducing Banny Warhol last December [Gabriel Haines](https://twitter.com/gabrielhaines) is a KOL on Twitter with 43.9k followers. He has been famous for making videos of himself shirtless yelling and waving a machete in his backyard. -Nicholas was working with him to create a new Juicebox project, where Gabriel Haines will be selling NFTs and doing roast or pep talk for the minters of those NFTs. By the time of this town hall summary, this project has been created successfully and has recieved quite a few payments. +Nicholas was working with him to create a new Juicebox project, where Gabriel Haines will be selling NFTs and doing roast or pep talk for the minters of those NFTs. By the time of this town hall summary, this project has been created successfully and has received quite a few payments. ![Gabriel Haines project](gabriel_rantsforyou.webp) diff --git a/town-hall/2023-02-21/index.md b/town-hall/2023-02-21/index.md index 4419dfea..e2106fd3 100644 --- a/town-hall/2023-02-21/index.md +++ b/town-hall/2023-02-21/index.md @@ -60,7 +60,7 @@ Now the `addToBalanceOf` call will not do so automatically any more. There is a - `useAllowanceOf`, we don't even expose this in the client yet, but we probably should consider doing some version, or at least alerting in the project page when there is an allowance in the contract, even though the UI doesn't facilitate it. - Its API is also changing to include the `_metadata` parameter alongside `_memo`. As this will only be called by the project owner, so it's usefull to keep the `_memo` there. + Its API is also changing to include the `_metadata` parameter alongside `_memo`. As this will only be called by the project owner, so it's useful to keep the `_memo` there. ![the useAllowanceOf function](useallowanceof.webp)