Documentation Discussion

If anyone finds an issue with the documentation for this fork of grbl-mega; or needs something documented that isn't yet documented --- this is the place to talk about it.
😄

WARNING!!!
I just spotted an error in the Wiring Overview that I had up on the wiki... the 5v and ground pins were reversed on the keypad connector (RAMPS Aux 2).
I've corrected the Wiring Overview image and uploaded it - but if anyone has downloaded the WiringOverview.png file; you should delete the old one and download a fresh copy.
Fortunately I don't think it's caused any issues, because the 4x4 matrix keypad is a completely passive device; it doesn't hook up to the power lines at all... but... better safe than sorry!
:flushed:

Wiring Hookup for CNC with RAMPS 1.4
sorry for the google translator text
there is an error in the aux 4 photos with the pins disconnected loses the card,

I'm not sure I understand...
You are saying cycle start needs USE_UI_ENCODER_B and USE_UI_ENCODER_B_ISR turned on to work?

bdurbrow great job thanks
basic setup
ramps 1.4
lcd
4x4 keyboard
bent aux 4 connectors
sd card not work
cicle start not work
i can't start gcode
interface read from card and can't give circle start.
only change in arduino was to uncomment the lines for the second encoder
bdurbrow great job thanks

Have you gotten the hard limits to work

sd card not work in this mode
original ramps works sd card
gcode only does not start
double translation is terrible

I appreciate the help.
gcode error
first line% symbol
in ugs it works

Grbl's g code interpreter does not support the % marker. UGS strips that out when sending the file to Grbl.
To make it work from the SD card; remove the %.
I will add a filter to the SD support library to automatically strip it from the file as it is being read by Grbl; but this won't be available to download for a little while. Perhaps next week.

How do the Part Zero, Probe-, Probe+, and LPAB keypad buttons work?
I can not seem to find any documentation for these buttons.
For the LPAB button, I figured out how to get the L and P characters but not the A and B characters. I have not needed these yet but curious how this works. I feel like it is a configuration that needs updating because I see in the UI Support folder you have 3 images and that button is the only one that changes.
Also, I finally found documentation on how to use the jog command, specifically how to switch jog increments. This would be useful info in the wiki as well as some more info in the keypad.
https://github.com/bdurbrow/grbl-Mega/issues/22#issuecomment-546717817

I'm working on the documentation as I get time; and hope to have some new pages up in the wiki this week.
The A and B functions of that key are only enabled on machines that have a 4th or 5th axis --- but support for that is currently not present in the core Grbl-Mega firmware on which this is based, so you can ignore them for right now.
The UI support layer was written with the intent to support future versions that have 4th and 5th axis functionality; as well as being portable to ARM processors. There is currently a version of Grbl-Mega that does have that support; and at some point I do intend to extend this version with that functionality.
FWIW, this is the 4/5 axis version I'm talking about:
https://github.com/fra589/grbl-Mega-5X

More documentation would be great but no rush, I know its a lot to document.
Adding support for 4tha and 5th axis would be great. Looking forward to seeing that added in the future. The project you tagged looks promising.


Port forwarding is broken in insiders build

Issue Type: Bug
I'm not sure how to help narrow this down, but as of yesterday's (1/4/2021) insider build, SSH port forwarding seems to be completely broken. This is still a problem with today's build. The prior build (pre-holiday break) was working normally.
I am forwarding a few ports (one via workspace config), and they still show in the ports list on remote explorer, but do not appear to work. They don't work if I add them manually in remote explorer, either. I'm forwarding localhost ports only, so I don't think this is #113763, though it could be related.
Manually creating the forwards with ssh -L 15432:localhost:15432 -L 4000:localhost:4000 works fine.
If there is any additional info I can provide, please let me know!
Extension version: 0.62.0
VS Code version: Code - Insiders 1.53.0-insider (a48ef56fbf7767f55a193d7d5687addd1fc9239c, 2021-01-05T05:33:42.154Z)
OS version: Darwin arm64 20.2.0
Remote OS version: Linux x64 5.9.10-200.fc33.x86_64

System Info

Item
Value

CPUs
undefined

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
1, 2, 2

Memory (System)
8.00GB (0.25GB free)

Process Argv
--crash-reporter-id 14c50ee1-a00b-46b0-abaf-6965d9e59493

Screen Reader
no

VM
0%

Item
Value

Remote
SSH: putz

OS
Linux x64 5.9.10-200.fc33.x86_64

CPUs
AMD Ryzen 9 3900X 12-Core Processor (24 x 2196)

Memory (System)
31.33GB (6.21GB free)

VM
0%

I've gotten two new Insider builds, and this problem is not fixed in them. This might be expected, as I'm not sure which branch you target for those builds. Just wanted to mention, if it should be fixed... it isn't, yet. 😄

I've gotten two new Insider builds, and this problem is not fixed in them. This might be expected, as I'm not sure which branch you target for those builds. Just wanted to mention, if it should be fixed... it isn't, yet. 😄

@tetious Could you please try with today's Insiders for example:
Version: 1.53.0-insider
Commit: 3ceb3a100ed0ad5f3238b5022d9d64353a1cc31e
Date: 2021-01-11T05:12:22.156Z

I have tested SSH from a macOS client to a Windows server and forwarding ports worked for me.
@alexr00 Could you please also double check?

@tetious Could you please try with today's Insiders for example:
Version: 1.53.0-insider
Commit: 3ceb3a100ed0ad5f3238b5022d9d64353a1cc31e
Date: 2021-01-11T05:12:22.156Z

I have tested SSH from a macOS client to a Windows server and forwarding ports worked for me.
@alexr00 Could you please also double check?

This is indeed now fixed for me in that build. Thanks for tracking this down so quickly. 👍

This is indeed now fixed for me in that build. Thanks for tracking this down so quickly. 👍

(doubled check, it's working from Windows to an Ubuntu remote too)

(doubled check, it's working from Windows to an Ubuntu remote too)

marking as verified by comments above

marking as verified by comments above


Cannot find module 'react-test-renderer/packages' from 'ReactSixteenAdapter.js'

Current behavior
Tests are failing due to the below error.
Cannot find module 'react-test-renderer/package' from 'ReactSixteenAdapter.js'

    However, Jest was able to find:
    	'./ReactSixteenAdapter.js'

Expected behavior
Your environment
  System:
    OS: Linux 4.15 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Memory: 2.44 GB / 15.11 GB
    Container: Yes
    Shell: 4.4.19 - /bin/bash
  Binaries:
    Node: 8.15.1 - /usr/bin/node
    npm: 6.4.1 - /usr/bin/npm
  Browsers:
    Chrome: 72.0.3626.121
    Firefox: 65.0.1
  npmPackages:
    react: ^16.4.0 => 16.8.4
    react-dom: ^16.4.0 => 16.8.4
    react-test-renderer: ^16.8.4 => 16.8.4

Version

library
version

enzyme
^3.3.0

react
^16.4.0

react-dom
^16.4.0

react-test-renderer
^16.8.4

adapter (below)

Adapter

[ -] enzyme-adapter-react-16

Do you have a jestsetup file?
It should have something like this inside it:
import Adapter from 'enzyme-adapter-react-16';

 Enzyme.configure({ adapter: new Adapter() });

Yes I do.

Duplicate of #2046. Fixed in v1.11.1.
It's also caused by having a broken jest config - ie, by not including json in your moduleFileExtensions.


Implement AddressForm and StateForm with Styled Modal using custom hooks and Context API

What has been done

Moved StateForm to a Modal to avoid scrolling around in the page
Added custom hook useModal to manage the opening and closing of the modal globally
Added Provider and Context for Styled Modal
Added Modal component which can be custom styled with ThemeProvider for different implementations across the app
On success of AddressForm API call to fetchContactAddress we invoke the Modal Context to show the StateForm inside the custom modal
On submit we call the Modal Context again to close the Modal upon successful submit from states Base Component

How to test it

Go to Deployed Staging FE app link and Deployed staging Google Cloud with organisation FE app
Fill in the Zipcode either manually or select from the dropdown below and fill Zipcode and address
After address is filled in, click Find My Election Official button

Notes

We can use Theme context to completely customise the Modal
The real-benefit of using a Modal for StateForm is that its a definitive UX step for the user to understand that some new change is expected instead of scrolling because its a bit more responsive and for cases like mobile and tablet with touch capability, the webpage might not scroll to the desired location

@tianhuil I added a bunch of comments to your questions, let me know!

@tianhuil Its probably a good idea to check out state management library from Facebook as an alternative of redux or unstated https://recoiljs.org/
It has an edge over these two with easier implementation


Insert emoji character rather than shortcode

Requires the bootstrap.php changes from #16 for it to work or test it.
Closes flarum/core#1331.
String.fromCodePoint (ES6) uses ints to transform them into unicode characters, but automatically converts strings into numbers as well. It uses the image name, aka unicode string, and splits it & converts it, and then uses spread.
Output in Babel dist should be compatible with IE

8MB GIF Preview

@datitisev Are you able to test this in multiple browsers?

Wait, how is this different to #16? @sijad's PR already inserts the emoji instead of the shortcode 🤔

Uuuuh.... it only mentioned using a client side implementation, not inserting the emoji (at least in main description), and I didn’t look at all the code.
Ignore me 😁🤦♂.


Code samples

Hi I updated ARDrivingCarDemo to work with starter-kit. It still gives a yellow warning: Animated: useNativeDriver was not specified.

Thanks for the effort, we all appreciate it! However I'm not sure if it's a good idea to have the code samples in this starter-kit repo. It would probably be better to keep this one just for the basic stuff and create a new one for code samples.

Ok, good idea
On Tue, Aug 3, 2021, 10:52 AM Marian Šámal @.***> wrote:

Thanks for the effort, we all appreciate it! However I'm not sure if it's
a good idea to have the code samples in this starter-kit repo. It would
probably be better to keep this one just for the basic stuff and create a
new one for code samples.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ViroCommunity/starter-kit/pull/19#issuecomment-891912852,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APTFWJ5YYO7LHLZQNWLARR3T277CDANCNFSM5BNLDIZA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.


remove sync system test

Motivation

remove unused and unmaintained code

Changes

remove sync system test
DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors merge


Can not install with different ssh port than 22

how can I install use a different ssh port than 22 ?

This is not supported at the moment. We do have a low priority tracker for it that was closed by automation last year. I reopened it and linked this issue so we can get it scheduled. If you want to open a PR with the change, we'll take a look.


Cannot select an AnimatedSprite3D node by clicking on it in the scene view

Godot version
Godot v4.1.1.stable.mono
System information
Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; <IP_ADDRESS>42) - 11th Gen Intel(R) Core(TM) i5-11400F @ 2.60GHz (12 Threads)
Issue description
An AnimatedSprite3D node (with a SpriteFrames) cannot be selected by clicking on its sprite in the scene view.
It can be selected by clicking on it in the node hierarchy. This issue is essentially about usability/QOL.
The use case would be, for example, making a 2.5D-style game where a lot of AnimatedSprite3Ds are its main actors and props.
It is still possible to select a Sprite3D node by clicking on it in the scene view, which is why I'm reporting this as a bug.
Steps to reproduce
In the reproduction project,

Open the scene named node_3d.tscn => It should have an AnimatedSprite3D visible at the origin.
In the scene view, click on the sprite => The node is not selected.

Minimal reproduction project
AnimatedSprite3DBug.zip

Can a normal Sprite3D be selected just fine?

Can a normal Sprite3D be selected just fine?

Yes, but not AnimatedSprite3D


RavenDB-20137 - 5.4 to 6.0 merge

https://issues.hibernatingrhinos.com/issue/RavenDB-20137/Invalid-query-results-when-using-paging-different-results-on-different-nodes

Do the 5.2 to 5.4 first, bump version there and then do the 5.4 to 6.0


Fix typos

Sorry I need to fix some CI workflows in order to let people outside of this repo create PR that pass CI

I don't mind if you merge when the checks are failing here - they will be green when the CI runs on main.
btw I had a look into the Makefile , and came across https://github.com/EmbarkStudios/gsutil which has slightly different syntax but does the same job as the very outdated PyPI equivalent which uses a bunch of unmaintained dependencies.  Might be worth using.

I don't mind if you merge when the checks are failing here - they will be green when the CI runs on main.
btw I had a look into the Makefile , and came across https://github.com/EmbarkStudios/gsutil which has slightly different syntax but does the same job as the very outdated PyPI equivalent which uses a bunch of unmaintained dependencies. Might be worth using.

I'll give it a try, asap.

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


neonKUBE installer for Windows

Potential Bugs:

[x] It appears that the installer is not exiting after it launches neonKUBE Desktop.
[x] The installer is picking up the wrong version some somewhere.

Advanced features:

[ ] PuTTY (optional)
[ ] WinSCP (optional)

I'm going to punt on the including PuTTY and WinSCP in setup.  This doesn't really make sense anyway unless we add the integrated VPN back.

Reopening, maybe I should include these after all.

Punting again on PuTTY and WinSCP.  We'll reconsider this as part of the neonDESKTOP revamp.


[0.9.2] Panic: slice bounds out of range (tsdb/shard.go:959)

Seeing the following panic in influx 0.9.2
[http] 2015/08/14 08:48:27 <IP_ADDRESS> - user_username [14/Aug/2015:08:48:27 +0200] POST /write?db=databasename HTTP/1.1 204 0 - - 7785f1fc-4250-11e5-8904-000000000000 1.501138ms
panic: runtime error: slice bounds out of range

goroutine 59817 [running]:
github.com/influxdb/influxdb/tsdb.(*FieldCodec).DecodeFields(0xc208f7f5b0, 0x7f646aea12b6, 0x3b, 0x7fffffff, 0x7fffffff, 0x0, 0x0)
	/root/go/src/github.com/influxdb/influxdb/tsdb/shard.go:959 +0x78b
github.com/influxdb/influxdb/tsdb.(*FieldCodec).DecodeFieldsWithNames(0xc208f7f5b0, 0x7f646aea12b6, 0x3b, 0x7fffffff, 0x7fffffff, 0x0, 0x0)
	/root/go/src/github.com/influxdb/influxdb/tsdb/shard.go:974 +0x72
github.com/influxdb/influxdb/tsdb.(*tagSetCursor).Next(0xc20a62cbd0, 0x11bb3e19d77c0000, 0x11bb8cae68bbbdc0, 0xc2099d4420, 0x6, 0x6, 0xc208d85990, 0x1, 0x1, 0x11bb55052c886000, ...)
	/root/go/src/github.com/influxdb/influxdb/tsdb/mapper.go:570 +0x1a1
github.com/influxdb/influxdb/tsdb.(*RawMapper).NextChunk(0xc2095fc0b0, 0x0, 0x0, 0x0, 0x0)
	/root/go/src/github.com/influxdb/influxdb/tsdb/mapper.go:169 +0x139
github.com/influxdb/influxdb/tsdb.(*StatefulMapper).NextChunk(0xc20925ccc0, 0x0, 0x0, 0x0)
	/root/go/src/github.com/influxdb/influxdb/tsdb/engine.go:54 +0x5c
github.com/influxdb/influxdb/tsdb.(*RawExecutor).execute(0xc208b95770, 0xc2099d43c0)
	/root/go/src/github.com/influxdb/influxdb/tsdb/engine.go:125 +0x1012
created by github.com/influxdb/influxdb/tsdb.(*RawExecutor).Execute
	/root/go/src/github.com/influxdb/influxdb/tsdb/engine.go:93 +0x5a

full stacktrace here: https://gist.github.com/consense/693af492ef9cf9faa68a
This occurs during our automated integration tests (resulting in ~500 writes, 200 selects into influx). Not reproducable on each run of the test suite (happens roughly every 10th run) and not always occuring at the same point during the test run.
Gladly suggest a way to make this more reproducable for you, but currently I wouldnt be able to provide a simple curl example resulting in the above panic.

@consense Do your tests operate on the same databases and measurements every time? Are you running them repeatedly against the same running InfluxDB cluster without restarts in between? We've seen some other issues where the churn from dropping a database, recreating it, writing to it, and then repeating the cycle soon and often can eventually lead to issues. It's perfectly reasonable integration test behavior, but it's somewhat pathological for the actual use case of InfluxDB. We're still tracking down all the related issues, but many have been mitigated in 0.9.3, which will be out next week.

Thanks @beckettsean
Yes, situation is basically as you already guess: we scaffold/teardown in rapid succession (only difference being that we are using DROP MEASUREMENT, not DROP DATABASE in between tests. DELETE FROM SERIES was even more unstable to use in v0.8 at least so we switched to DROP MEASUREMENT).
In that case closing the issue and will reopen if the problem persists in 0.9.3

Hello,
Me too.
0.9.2 from rpm.
Similar context.
Regards,
Yves


Formulas with IFS result in #NAME error.

Looked and did not see this previously reported, if you assign a cell a formula with IFS() -- there may be others, but that is the one I had issue with -- the resulting spreadsheet will display #NAME error. However, if you click in the cell and hit return, it displays the result of the formula as expected. If you save that excel sheet and then unarchive it, you will find the entry in the corresponding XML file is not IFS, but _xlfn.IFS. When I altered my code to specify the formula prefaced with 'xlfn.', it displayed as expected.

@zawarski I just ran into the same issue. Were you able to resolve it?

same here, any ideas?

For me, switching out semicolons with commas did the trick!
When opening in excel, they show up as semicolons again.
{ formula: `=IF([SomeColumn]=TRUE; [SomeOtherColumn]; 0)` } // not working
{ formula: `=IF([SomeColumn]=TRUE, [SomeOtherColumn], 0)` } // working


How-to: Migrate from spring-security-oauth2

It would be great if we had a guide on how to migrate from spring-security-oauth2 with DB stored opaque tokens to this project. Preferably without loosing existing tokens or refresh tokens.

The Spring Security OAuth project has reached EOL and therefore it doesn't make sense to allocate any efforts to this project. We need to focus our efforts with Spring Authorization Server and keep building out features and documentation.
Furthermore, Spring Authorization Server is a complete re-write of spring-security-oauth so the core classes and components are not a simple 1-1 mapping. The migration guide would take too much effort to write.
There have been quite a few projects (comments from the community) that have already migrated from the old spring-security-oauth to Spring Authorization Server so it is doable without a migration guide. The best place to start understanding how to migrate is by learning the samples.


add audio facet

I really wand @dschmidt to work on a music app for ocis ;-)

Let's make it happen?


Stardust Algorithmic Stablecoin Proposal

Project Abstract
This is a follow on to our stablecoin research project. After analyzing the failure modes of extant solutions and the collapse of Terra, we've identified the key weaknesses of those models. Specifically the inability to manage demand contractions and susceptibility to runs on the network that leads to a "death spiral" ultimately inflating the currency to nothing. In order to solve these weaknesses we have developed a new structure that tightly integrates the operations of the stablecoin with the market to redirect seigniorage profits into a treasury and then uses the stable cashflow coming out of the automatic investing operations of the treasury to compensate the bond token holders who ultimately underwrite the stability risk. This ultimately creates a stable demand and allows us to disincentive runs by allowing users to exit only by surrendering access to these future cash flows.
For which grant level are you applying?

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $50,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied, renamed ( project_name.md) and updated.
[x] I have read and understood the FAQs, application guidelines and announcement guidelines.
[x] A BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) address for the payment of the milestones is provided inside the application.
[x] I have read and acknowledge the terms and conditions.
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted.
[ ] I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: @_______

How Did You Hear About our grants program?

[ ] Social Media
[ ] Hackathon
[ ] Personal Recommendation
[ ] Substrate Builders Program
[ ] Investor/VC
[ ] Online Search
[x] Other: Previous Grant Recipient

Hey @adit313, thanks for the interesting proposal and great research so far! I have a few questions about this approach, I hope it's fine if I challenge it:

Do I understand it correctly that the entire supply is issued in response to heightened demand and sold in DEXs?
Don't you think doing so plays against the stability of the price by creating sell-side pressure, since arbitrageurs can no longer speculate on the price increasing above 1 and can only profitably trade in below value, "de-pegged" ranges - hence decreasing liquidity around the peg?
Also, you will be competing with arbitrageurs.
What do you mean by the treasury's "dynamic APR rate"?
Assuming the answer to 1) is yes, the supply will be backed solely by a basket of crypto-assets, which are highly volatile and correlated. It is very likely that at some point, the market value of these assets drops by more than the excess size + interest pool. What happens then? What really prevents a death spiral in all this? If the stablecoin de-pegs, everyone tries to redeem it for bondcoins and immediately sells those bondcoins, how won't you end up with 6 trillion worthless bondcoins? As soon as the market value of the assets in the reserves drops below the stablecoin market cap, a death spiral can still happen - it will just be delayed.
Doesn't the treasury entirely depend on the assets it contains appreciating, apart from the small lending interest in the long run? How else can it reach the excess size?

Hey
Thanks for this proposal. I took a look at it and I'm trying to understand it, so the following comments are not mean to be critical but rather help clarify how your proposal works exactly.

The Open Market Operations lack quite a bit of detail. I'm not sure if it's a good idea to integrate with (existing) DEXes, instead of having the treasury put out offers that traders/arbitrageurs can buy directly (i.e. deposit assets in exchange for newly printed stablecoins, probably at a premium). But maybe this is meant here, I'm not certain. If it's the former, you must expand on:

How the treasury deals with a liquidation crisis. Meaning: what happens if not enough assets can be bought.

(This somewhat also applies to the later)

How the treasury deals with slippage.
How the fees are managed.

It will require a consistent amount of funding to pay for gas.
What issues could occur during unusual/high trading activities (such as gas wars).

How the DEXes are managed, whether those are fixed or can be modified via some sort of governance mechanism.

The lending part seems to imply that the treasury will lend out its stable assets to buyers directly, which has full control over the APR and adjusts it until all reserves have been deployed (collateralized, hopefully). Is there some sort of interval on how often the APR is increased? What decisions does the treasury make to set the APR?
Lastly, in case the stablecoins drops below the peg: you say that stablecoins can be burned in exchange for bonds, so I assume those bonds are newly printed. For this to work and not to scare off current bond holders, you must make sure that the treasury has enough stable asset reserves to cover the newly printed bonds + interest (is this were the "excess size" comes into play?). You describe:

Not illustrated: The treasury, if it falls below the excess, claws back assets from the interest pool. The treasury has the ability to make uncollateralized, interest free loans from the stablecoin smart contract, which it can then loan out at a fixed interest rate. This functionality is not designed for long-term use, but more as a tool if the system needs to perform an emergency liquidity injection into the market for very short-term demand. (Note this is VERY complex economically and designed to function primarily as a way to control the interest rate of the stablecoin currency, similar to how central banks control overall USD interest rates. Due to its complexity, it must be a carefully managed process that is entrusted to the bondholders as it cannot be automated.)

I'm not quite sure I understand this part, it does not clarify what kind of uncollateralized, interest free loans the treasury takes from the stablecoin contract... I hope not newly printed stablecoins while the price of the stablecoin is below the peg? You're basically trying to give out newly printed stablecoins in exchange for stable assets while trying to convince (potential) bond buyers to burn their stablecoins in exchange for bonds, so now you have to create new loans of newly printed stablecoins in exchange for stable assets and the cycle continues... is this correct? This VERY complex economically and designed function should be explained further.
In summary, please expand on:

How the Open Market Operations will work exactly, respectively with whom the treasury will/should interact with.
The lending mechanism.

How often and by how much does the treasury hike the APR?

Where this "excess interest" comes from.
Most importantly: Explicit description of the asset type every time it's mentioned: stablecoin, bond or "stable asset" (DOT/ETH). While reading the proposal it was kind of hard to decipher what kind of asset type you're referring to in each section or sentence.

Also:

Bondcoin supply can be burned at anytime for an equal % of the interest.

Principal + interest, you mean?
Maybe in general, a list of assumptions that you make for this system to work might be useful.

Hi Alexio, all good questions. They are all things we've put a ton of thought behind and we're happy to explain it in detail. Also, I appreciate you playing devil's advocate to every single one of our ideas and appreciate being challenged and having to prove the stability of the idea especially during contractions. The last thing I'd want to do is introduce risks for the general public and we need to deliver a solution that has been rigorously challenged and tested.
Do I understand it correctly that the entire supply is issued in response to heightened demand and sold in DEXs?
Exactly, we're trying to integrate it tightly with real financial infrastructure (DEXs) and perform the stabilization through open market operations so that it is transparent, automatic, and quickly reacts to real world market changes. One of our learnings with extant algo coins is that there was rapid and sizable appreciation in the price of Luna tokens because you could gain access to the minting arbitrage opportunity. However, that's a double edged sword that unwinds just as fast, characterized by the classic "death spiral" as users rush to the exit. We are redirecting these seigniorage profits into an automated treasury that can perform market stabilizing functions automatically instead of relying on the bond holders or the price of the token itself to insure that.
Don't you think doing so plays against the stability of the price by creating sell-side pressure, since arbitrageurs can no longer speculate on the price increasing above 1 and can only profitably trade in below value, "de-pegged" ranges - hence decreasing liquidity around the peg?
You are correct that it creates less incentives for arbitrageurs (aka our bond token holders) as there is no immediate upside benefit like there was with Terra or still is with Waves. This is a purposeful choice. The primary design challenge of an algorithmic coin, in our opinion, is on the downside during market contractions. Printing money is easy, burning supply is the real challenge. Instead of realizing an immediate profit from seigniorage, our bond token holders instead realize a long-term, profit from excess investment interest from treasury operations, a process they are responsible for managing.
In essence, the bondholders don't get the seigniorage profits immediately, and instead need to properly manage the treasury to continue to profit off the interest, a much slower process. In full transparency, I don't really have a good understanding for how bond holders value this tradeoff or if it will be sufficiently attractive. Obviously, most users prefer the immediate profit of seigniorage tokens, but the recent collapse of Terra demonstrates the converse risks of that strategy. Directing seigniorage profits to a smart contract controlled treasury allows our proposal to offer a fundamental utility of a profit stream to bond holders that could one day be several multiples of the immediate seigniorage profit, if they do a good job managing the network and hedging risk.
Also, you will be competing with arbitrageurs.
Sort of, the treasury is designed to step in and issue new tokens when there is an overall imbalance in supply and demand at a market level. It's not planned to be implemented in such a way that the treasury is going to be trying to find opportunities for every pair where the price is >$1.00 USD generally. In the current design it is supposed to watch a few highly liquid, specific pools. A good hypothetical example would be something like 3Pool on Curve, but that choice of what pools it watches is ultimately down to the bondholders. Pool choice is important because it determines the makeup of the treasury, and as such should be carefully managed by the bondholders. All of the traditional arbitrage opportunities and movements across the 100,000s of other pools would be left to searchers on the market, it's not something the treasury is planning to compete with. Ultimately, if there is a consistent supply/demand imbalance, it should also show up in the largest pools where it will be caught by the treasury. If arbitragers can keep the price in large, liquid pools at $1.00, then there really isn't a need for any market operations.
What do you mean by the treasury's "dynamic APR rate"?
The treasury is by far the most complex construct. I used to be a banking analyst, and I know first hand the difficulty and time-consuming nature of making investing decisions. Deploying the funds of the treasury efficiently is a non-trivial task, and is difficult to do without any form of centralization. We could try to leave the process up to the bond holders, as they have a vested interest in making the most efficient allocations, but it needs to be highly streamlined as it would quickly become a full time job and become a very expensive process if investment decisions were made on-chain.
In order to solve this, the treasury itself needs to be smart enough to make investment decisions. I stole the logic of AMMs for this, but the treasury responds to market forces of supply/demand. Similar to other borrowing protocols, anyone can borrow treasury assets provided they post collateral. The APR they pay for this is dynamic and adjusts based on how far off the treasury is from a target deployment threshold set by the bondholders. This is very similar to how a traditional bank aims to deploy most of its funds at the highest APR it can manage. US banks are legally required to hold 10% capital in reserve, so let's say the bond holders set a similar 90% deployment ratio. The treasury dynamically changes APR based on how much of its capital is deployed. If it is failing to find borrowers and only 70% of its capital is borrowed, it automatically drops borrowing rates. If it has 95% of its capital deployed, it increases borrowing rates until 5% of capital is retuned. Bond holders are responsible for setting a target deployment ratio through a vote.
(This is primarily because we want to keep this automatic, decentralized, and algorithmically driven. This process can also be managed by a DAO that's takes charge of treasury deployment. Though there is a large trade-off in terms of centralization and autonomy.)
Assuming the answer to 1) is yes, the supply will be backed solely by a basket of crypto-assets, which are highly volatile and correlated. It is very likely that at some point, the market value of these assets drops by more than the excess size + interest pool. What happens then? What really prevents a death spiral in all this? If the stablecoin de-pegs, everyone tries to redeem it for bondcoins and immediately sells those bondcoins, how won't you end up with 6 trillion worthless bondcoins? As soon as the market value of the assets in the reserves drops below the stablecoin market cap, a death spiral can still happen - it will just be delayed.
These are very good points and you are exactly right, the treasury will ultimately hold some basket of crypto-assets. I'm going to separate the death spiral and then address the real failure mode. First off, as far as we're concerned, death spirals are THE major problem of algorithmic stablecoins. Everything needs to be built to manage a recession or demand contractions. Our hope, is that by leaving the allocation of this crypto-asset basket up to the bond holders and only paying out interest to the bond holders if the treasury is above excess size, bond token holders will be able to manage it and respond to market dynamics with a better understanding of then-current market conditions than any pre-built algorithm can or we can set in the present. This however is not assumed, we assumed that at some point, perhaps consistently, they will fail to maintain the peg.
This proposal is primarily designed to manage what would be the ensuing run of a depeg through several separate mechanisms. Crypto-assets are notoriously volatile and can lose 20%+ overnight. Even slight volatility in stablecoin prices can spark a run as seen with many previous algorithmic implementations such as Terra, Waves, and Iron. At the first sign of trouble, holders will start to burn for bond tokens due to the arbitrage opportunity. There are a few important dynamics here that differentiate our model from traditional stablecoins. Normally, printing 6 trillion tokens degrades the price, which is the sole utility of the bond token, however our bond token gives you a right to the interest payments in the future. Even though trillions of bond tokens might get minted, what matters is what % of outstanding supply you hold as that gives you access to a proportional interest stream from the treasury. The best way to increase that %, is to be the LAST person to burn your tokens when the peg has slipped the furthest, this would give you the largest proportion of interest bearing tokens.
You might be thinking that when the treasury has a deficit, there would be no possibility of interest payments. However as the stablecoin supply gets burned, the capital requirements for the treasury also drop. At a certain point, the treasury will begin liquidating its assets as it now has excess capital. At this inflection point, every stablecoin token burned will release a larger amount of treasury assets into the interest pool, helping stabilize the price of the bond tokens during a significant contraction and allowing for a natural release of all treasury assets. Ultimately, the original bond holders are the ones who would be forced to absorb the majority of the losses. However as they have failed to properly manage the treasury, they also deserve to ultimately hold the risk.
Our model also gives bond holders additional tools to mitigate runs. In the event of an emergency, bondholders can opt to require some of the collateral for treasury borrowing to be in the native stablecoin, temporarily creating additional demand to smooth an extreme contraction. This mimics one of the main tools of a central bank in managing inflation which is to increase the reserve ratio of banks. Here we artificially create a reserve ratio for the treasury, which locks up stablecoins and slowly releases them when the system can absorb the demand. Note: I personally don't believe native stablecoins serving as collateral should be an ongoing requirement during standard operations and kept only for emergency use, but that power is left up to the discretion of the bond holders.
We've tried to break the incentive to run by instead using the interest payments to create a strong incentive to wait when the price depegs, as that will maximize the profits of a stablecoin holder. Ultimately, you'd like to be one of the last stablecoin holders to burn your tokens, as that will give you the highest proportion of tokens, and the interest payments from the liquidation of treasury capital ensures that token holders will see some profits.
In the long-run, the system attempts to close any deficit between treasury assets and the market cap of the stable coin through continued investing operations.
What this model hasn't addressed and is its primary failure mode is related to the below question.
Doesn't the treasury entirely depend on the assets it contains appreciating, apart from the small lending interest in the long run? How else can it reach the excess size?
This is correct. Integral to the foundation of this proposal, is the assumption that the overall cryptocurrency industry will at a minimum shrink slower than the risk-free interest rate. While an appreciating and growing industry will make the model more resilient, even if the market is slowly shrinking, as long as it doesn't shrink faster than the risk-free interest rate, investing will still be a profitable endeavor allowing the model to work. However, this is far from a given, and is the primary failure mode of this model.
A diversified treasury portfolio will help insure against shocks in specific projects and closely track the overall performance of the industry, however a few notable events could collapse the cryptocurrency industry as a whole. Events such as Tether depegging, or if it is discovered they lack backing reserves, would cripple the industry and crater prices across the board. As would any sort of regulatory action or crypto bans by western authorities.
This model would strongly suffer in this case as the treasury is not sufficiently diversified outside of crypto. Outside of the scope of this proposal are two main defenses that are relatively unfeasible either practically or philosophically.
The first would be for the treasury itself to purchase significant insurance on its assets. This is possible thanks to modern financial constructs such as perpetuals and insurance. The downside is that liquidity completely dries up during a crash and it is unlikely that DeFi markets would have enough liquidity to guarantee coverage.
The second prevention mechanism is the proven financial principle of diversification. Specifically trusting the treasury to a DAO that can invest in assets that are either uncorrelated or contra-correlated to the broader cryptocurrrency industry. These would be real world assets like bonds, metals, stocks, commercial paper etc. This would necessarily centralize a lot of the control and bring assets off chain and as such is out of scope for this proposal. Synthetix did attempt to bridge these assets to the chain, however the liquidity isn't there to sustain anything at the scale of a stable coin.
From a design perspective, we don't really have a good way to make a stablecoin that is protected against these kinds of vulnerabilities without centralizing and taking assets off chain. Solving the issue of the portfolio composition of on-chain assets is left up to the bond holders who are incentivized to efficiently manage it, and has a relatively well-proven solution of broad diversification across many different projects and long-term horizons. The larger question we have is how to diversify the correlation to the cryptocurrency industry as a whole. Ultimately, we are okay assuming that there is an enduing use case to cryptocurrencies as a central hypothesis, as without believing that, there really is no point to any stablecoin arcitecture.
Sorry for the long-reply, we ideally wanted to provide this level of details in the design proposal for milestone 1, but happy to share ahead of time.

Hi Fabio, don't feel bad, this model needs to stand up to intense scrutiny and it should be well thought out and have very defendable design decisions.
The Open Market Operations lack quite a bit of detail. I'm not sure if it's a good idea to integrate with (existing) DEXes, instead of having the treasury put out offers that traders/arbitrageurs can buy directly (i.e. deposit assets in exchange for newly printed stablecoins, probably at a premium). But maybe this is meant here, I'm not certain. If it's the former, you must expand on:
Yes, it's an equally valid idea to have a bidding system that offers out newly minted stablecoins that traders can buy directly, in fact it's how the US treasury injects new supply. The challenge in implementing a bidding model for us, is knowing how much stablecoin supply to inject. The US government has a flexible inflation target so it doesn't need the accuracy of our system, which is trying to anchor very closely to a peg. With a bidding or offer model, it is very difficult to figure out exactly how much supply to offer, and who should hold that decision power. Performing the operation on a DEX, you can look at the imbalance in the pool and calculate the size of the injection needed to bring the AMM back to parity. With the bidding system, it has a lot of room for error in the lot size, unless you offer unlimited stablecoins at a slight premium and let the market sort it out. However, if you went that route, the only time anyone would buy these tokens is when there is an arbitrage opportunity on the open market and they can turn around and inject it themselves into these pools for a profit. In which case you've distributed away some of your seigniorage profits to no advantage.
I might be misunderstanding your model, or I've overlooked something. I'd love to hear what you were recommending in terms of a bidding or offering model, and what hesitations you have about integrating with existing DEXs. There are always oversights we haven't thought of.
How the treasury deals with a liquidation crisis. Meaning: what happens if not enough assets can be bought.
From our side, this isn't a real crisis as not being able to purchase enough assets simply inflates the price of the coin above $1. At that point, the bond holders would simply have to add new pools to be tracked for newly minted stablecoin, which would have the added advantage of diversifying its assets. Generally, if the price temporarily exceeds $1, it isn't really a major issue in this design as it is trivial to print more coins and issue them on the market, have the bond holders vote to just add a few more asset pairs and it'll figure it out.
I'm reading deeper into your question and assuming it is, what is the threshold at which the open market operation causes too much slippage and buys tokens for far too high a price and how do you stop that. That's related to your next question.
How the treasury deals with slippage.
When the smart contract mints new stablecoins and buys tokens on the DEX, it's only going to do so up until it hits parity with $1 USD. As an example, if the pool was our stablecoin:ETH on Uniswap, it would first query the Chainlink oracle to get the price of ETH:USD. Let's say it's $2,000 USD. It would then get the actual coins and liquidity in the watched pool and construct a trade such that the final coin of the order transacts at 2,000 Stablecoins for 1 ETH token. We can look into the pool on Uniswap (Note: I'm aware there are some complications here if you are using V3 because it has smart routing, but I'm ignoring that for this quick example) and figure out the exact order size to bring it to parity and execute that amount. Obviously the transaction would be failed if that price was not possible.
How the fees are managed. It will require a consistent amount of funding to pay for gas. What issues could occur during unusual/high trading activities (such as gas wars).
Our current implementation has the fees paid for by the initiator of the process. The bond holders are strongly incentivized to maximize the size of the treasury since this increases the interest flows, so they'll be responsible for initiating the process. If successful and over a sufficient proceed size the smart contract can refund the gas costs using some of the proceeds, otherwise the bond holder pays it as a penalty for a false initiation. By proportioning the "sufficient size" to the gas used hopefully the bond holders smartly manage unusual/high trading timeframes.
How the DEXes are managed, whether those are fixed or can be modified via some sort of governance mechanism.
The choice of DEXes, or more specifically the particular pools is left to the bond holders to decide. This has a major impact on the composition of treasury assets, and as such is up to the bond holders to manage and sequence in terms of priority. It's their job to manage and ensure the stability of the treasury and one of the primary ways to ensure that is to craft a well diversified portfolio of assets.
The lending part seems to imply that the treasury will lend out its stable assets to buyers directly, which has full control over the APR and adjusts it until all reserves have been deployed (collateralized, hopefully). Is there some sort of interval on how often the APR is increased? What decisions does the treasury make to set the APR?
Investing decisions are very complex and can't be managed by the bond holders efficiently. Instead the bond holders set a "target deployment ratio". This is the targeted ratio of capital that should be deployed. The treasury updates a dynamic APR every fixed period, likely 8 hours based on perpetual best practices, in order to maintain this ratio. Too little capital deployed and it drops the APR, too much capital deployed and it increases it. In order to borrow the assets, users have to post collateral. APR changes work similarly to an AMM where it is an exponential curve based on how far from the target deployment ratio the current deployment ratio is.
Also, depending on what the bond holders have decided, none, some, or all of this collateral must be denominated in the stablecoin itself. This gives the bond holders a tool to quickly increase demand for the stablecoin and lock it up, similar to how central banks use the reserve ratio at banks. Note: I personally would not advise keeping any requirement during normal market conditions as that would create artificial demand for the token, but ultimate control rests with the bond token holders.
Lastly, in case the stablecoins drops below the peg: you say that stablecoins can be burned in exchange for bonds, so I assume those bonds are newly printed. For this to work and not to scare off current bond holders, you must make sure that the treasury has enough stable asset reserves to cover the newly printed bonds + interest (is this were the "excess size" comes into play?). You describe:
"Scaring off" current bond holders is purposeful design decision. In extant solutions, these tokens had no utility and as such,  bankrupting current bond holders was seen to be a negative. In our solution, being a bond holder confers a responsibility to manage the treasury and ensure that it is well diversified and generating stable returns. In exchange for efficiently managing the network and fulfilling their obligations, they have the potential to receive a revenue stream. If they fail to properly discharge their duties, they lose their investment and will be quickly replaced by the newly minted bond holders. This is a know design feature and serves to ensure that the risk ultimately land on those with the ultimate responsibility.

Not illustrated: The treasury, if it falls below the excess, claws back assets from the interest pool. The treasury has the ability to make uncollateralized, interest free loans from the stablecoin smart contract, which it can then loan out at a fixed interest rate...

I'm not quite sure I understand this part, it does not clarify what kind of uncollateralized, interest free loans the treasury takes from the stablecoin contract... I hope not newly printed stablecoins while the price of the stablecoin is below the peg? You're basically trying to give out newly printed stablecoins in exchange for stable assets while trying to convince (potential) bond buyers to burn their stablecoins in exchange for bonds, so now you have to create new loans of newly printed stablecoins (or shift those "burnt" stablecoins?) in exchange for stable assets and the cycle continues... is this correct? This VERY complex economically and designed function should be explained further.
This is emergency functionality for the bond holders to use to manage the risk free interest rate of the stablecoin. An example of something that would need to be managed by this functionality is Anchor. While Anchor was a first party app used to grow the Terra network through a massive subsidy, it also set an interest floor of 20%. Other stablecoin architectures have popped up with incredibly high interest rates on their tokens. While all of these have so far been first party, subsidized Dapps, it is possible that a third party could launch one using this system's stablecoin or these interest rates would have knock-on effects in our ecosystem.
One of the most important functions, and an often overlooked one, of a central bank is managing borrowing rates. While our system manages supply and demand for tokens, it doesn't directly affect interest rates. Most stablecoins leave interest rates entirely up to the market. We wanted to give our bond holders a way to enforce a risk-free interest rate floor so that users can borrow stablecoins at a fixed APR from the treasury if interest rates get too high. Now deciding when interest rates are "too high" is more an art than a science, and changing the risk-free rate comes with a lot of macroeconomic effects, which is where the high level of economic complexity comes in.
Also, these are indeed, newly minted stablecoin tokens that are burned at the completion of the loan. When I say "uncollateralized" I meant the treasury doesn't provide the stable coin smart contract anything in return for borrow tokens, the users borrowing from the treasury need to provide collateral. In terms of borrowing while the currency is depegged at less than $1, the treasury would always assume loaned stablecoins were worth $1 and would demand a commensurate level of collateral. In terms of a cycle of borrowing, burning for bond tokens and then trading those tokens to get more ETH that could be used as collateral, and endlessly repeating, it would be far more profitable to instead borrow from AAVE who would loan you far more stablecoins for a given amount of collateral. I assume in a depegging crisis, the bond holders would not have this functionality enabled, it's more for managing a crisis if borrowing costs become untenably high.
Also, I didn't put this in the summary, but the Treasury doesn't accept it's own bond token as collateral, that's just a bad idea.
Bondcoin supply can be burned at anytime for an equal % of the interest. Principal + interest, you mean?
Nope, just interest. It is integral to the system to think of principle as property of the treasury. This isn't collateral, it a pool of assets controlled by the bond token holders that is deployed to maintain stability, generate returns, and grow. These bond holders only get paid the interest so they better do a good job managing the assets as if they fall below the market cap of the stable coins, their interest payments quickly disappear. If they do such a bad job that tokens start to get burned they'll quickly lose their ability to make decisions. The ability to redeem for some of the interest pool is a way for bond holders to exit early if they feel like they don't want the responsibility of managing the treasury. It also helps set a floor for the bond token prices though I imagine it will trade much higher than the worth of the redemption outside of crises.
Maybe in general, a list of assumptions that you make for this system to work might be useful.
Yup, we definitely plan to provide that along with references in the design docs.
A question for you on this is that a lot of these questions are very detailed and are more things we were planning to put into the design docs with pictures, charts and references instead of trying to squeeze it all into our proposal. Would you prefer that we go into this level of detail in the actual grant proposal? We thought it would be better in the design docs as there we can use diagrams and go into the full depth of the model.
As this is still an experimental architecture and invites a ton of questions, we're also happy to pull together a presentation and jump on a call. It might be faster to cover it in 30 minutes with diagrams and talk through any potential oversights or limitations you see.

@takahser
Our mistake, I just copied our old submission without thinking. We'll add those back in. :)

@adit313 Thank you for the quick response!

A question for you on this is that a lot of these questions are very detailed and are more things we were planning to put into the design docs with pictures, charts and references instead of trying to squeeze it all into our proposal. Would you prefer that we go into this level of detail in the actual grant proposal? We thought it would be better in the design docs as there we can use diagrams and go into the full depth of the model.

I'm generally not involved in grant proposal, I was asked to take a look at this. So whether this information is sufficient I don't know. While I do remain highly skeptical of this proposal, I'm quite interested on where it might go. I'd fully support having you write a more enhanced design document and a working proof-of-concept/implementation.

As this is still an experimental architecture and invites a ton of questions, we're also happy to pull together a presentation and jump on a call. It might be faster to cover it in 30 minutes with diagrams and talk through any potential oversights or limitations you see.

I'd happily join the talk, assuming we want to do that.

On hold pending legal approval.

Hi Alexio, just saw the hold for legal approval. We obviously understand that uncollateralized algorithmically managed stablecoins are a highly sensitive space at the moment. In light of those sensitivities, do you think it makes more sense to pare back this proposal to just milestone 1 as a level 1 grant, with a very explicit caveat that it is a purely exploratory analysis being performed for research purposes? Dropping the code deliverables would help make it explicit that this is just a research exercise, and not a real attempt to actually build a stablecoin.
I obviously don't know what your legal team's specific sensitivities are, but we're happy to accommodate any concerns they have to the best of our ability. We're glad they are being brought in early in the process as we also feel that it's a politically sensitive space currently.

@adit313 personally I do think that your suggestion to drop M2 and M3 could indeed increase the chances for this grant application to be considered compliant by our legal team. However, that's just my personal opinion and I'm definitely not a legal expert. For now, I think the best approach is to wait for our legal team's feedback and plan the next steps from there.

Sounds good, we'll be on the lookout for any updates.

@alxs, @takahser Hey there, any updates?

@adit313 legal is still working on it, we'll get back to you as soon as we have an answer.

@adit313 sorry for the delay here. I just received feedback from the legal team.
I'm quoting your earlier comment here:

(...) do you think it makes more sense to pare back this proposal to just milestone 1 as a level 1 grant, with a very explicit caveat that it is a purely exploratory analysis being performed for research purposes?

From a legal perspective, there's no problem with M1. Hence, limiting the grant to M1 and converting it into a level 1 grant would be the recommended way forward. Of course, you'd still need to reach a sufficient number (=2) of approvals from the grants committee to get the grant accepted.

@adit313 thanks a lot for the elaborate reply. That's quite a lot to dive into. In general, I have to say like Fabio I remain sceptical. I've highlighted a few passages where I see potential issues below, I'm trying to explain why I'm not convinced so please understand if I'm critical. I really enjoyed thinking about this and in principle, I like the idea.

We are redirecting these seigniorage profits into an automated treasury that can perform market stabilizing functions automatically instead of relying on the bond holders or the price of the token itself to insure that.

These aren't "profits" in the first place - you'll likely be buying assets at, basically, market price and then you indeed don't rely on the price of your token to insure that, but on that of some third-party assets.

bond token holders instead realize a long-term, profit from excess investment interest from treasury operations, a process they are responsible for managing.

It's unclear to me where you intend for this capital to be invested - you talk about investment interest and a "diversified treasury portfolio", but you also clearly describe effectively launching your own lending platform later on ("similar to other borrowing protocols, anyone can borrow treasury assets provided they post collateral"). This would be an unrelated product whose risk stablecoin users would also need to carry. However that is, there will always be a risk involved, and I'm not sure the treasury would be able to generate enough interest to not only attract users but also make up for the risk of the entire thing.

In essence, the bondholders don't get the seigniorage profits immediately, and instead need to properly manage the treasury to continue to profit off the interest, a much slower process.

Again, the treasury's performance will largely depend on the performance of a few selected crypto assets, not on the interest. The way it's currently described in the proposal, the profits in case these assets appreciate would also overflow into the interest pool and render the actual interest returns irrelevant once the excess size is reached. You also claim that "the treasury, if it falls below the excess, claws back assets from the interest pool", which means effectively these two pools are one and the same, and the whole system is a bet on one external variable, the market.

The best way to increase that %, is to be the LAST person to burn your tokens when the peg has slipped the furthest, this would give you the largest proportion of interest bearing tokens.

Assuming they can only periodically be redeemed? Because otherwise, the last person to arrive may get the largest share of all tokens in the interest pool at the time they redeem, but by then it will have been reduced to pennies. And if they can only periodically be redeemed, that doesn't stop people from selling them in the open market until their market cap matches the value of the interest pool, which may even be empty if the treasury has "clawed back" the returns. You mention in your application that being able to exchange bond tokens for a share of the treasury pool "gives the bond tokens a material non-zero intrinsic value at any given moment", but that value seems to 1) not necessarily be non-zero and 2) be largely dependent on external factors, i.e. again the market.

We've tried to break the incentive to run by instead using the interest payments to create a strong incentive to wait when the price depegs, as that will maximize the profits of a stablecoin holder.
In the long-run, the system attempts to close any deficit between treasury assets and the market cap of the stable coin through continued investing operations.

Again, that's not a strong incentive, and it will certainly not maximise the profits if it depegs, which would be the most natural outcome in case the assets in the treasury drop below the market cap. Liquidating these assets will cause them to drop further in value, exacerbating the problem, and only absorb sell pressure until they've been completely liquidated and the remaining stablecoin supply is unbacked, which is very much death-spiraly. By then, any long-run attempts by the system to "close any deficit" will not matter in the least.

This is correct. Integral to the foundation of this proposal, is the assumption that the overall cryptocurrency industry will at a minimum shrink slower than the risk-free interest rate.

So if you'd launched half a year ago, the project would most certainly have ended in a death spiral? I don't understand how you can claim the project is "death-spiral resistant" and at the same time depend on an assumption that simply doesn't hold in the real world.
Even though I would certainly like to support an algorithmic stablecoin which eventually succeeds, and it is clear to me there's a lot of work behind this proposal apart from it certainly being novel approach, looking at this objectively I can't support any of the current milestones. However, I really enjoyed your previous research deliveries and I'd be more than happy to support more work along those lines, or if you'd like to implement something maybe you could work on something with less inherent risk? Feel free to pick a slot so we can chat here or let me know if those don't work for you.

Hi Alexio, you are perfectly right, because the basket is only of crypto currencies, you'd never really be able to hedge against gross movements in the industry. All non-custodied stablecoins expereince this issue in their collateral pools. most solve it like MakerDAO does with PSM and USDC and allow for 1:1 redemption for a custodied stablecoin, but at that point, you haven't really solved any issues. That's the one thing we found during our state of the stablecoin report is that most of these projects have collateral from other projects until you get down to the two main collateral sources USDC or USDT.
It's really hard to create a diversified portfolio with only crypto assets today without centralizing which is what we are trying to avoid. You are completely right, a crypto-only asset portfolio wouldn't work because every crypto asset is ultimately STRONGLY correlated to Bitcoin.
One of the solutions we were thinking of is: can one diversify the portfolio with off-chain assets using synthetic products, kind of like what Mirror and Synthetix were attempting to do. This would allow you to bring things like bonds and stocks on chain, and ideally synthetic treasury bonds from multiple countries which would form a strong backbone of stability. We actually went to ETHGlobal NYC this past weekend and met with the founder of Sythetix and got some feedback on that idea. Ultimately, the issue becomes the collateral required to cover any movements in the price of crypto. The amount quickl becomes untenable and capital inefficient unless the collateral is in stablecoins with low collateral margins. There are a lot of open questions with that idea as even Synthetix haven't really made it work, and this would be highly experimental in a soon to be heavily regulated space, so we understand the hesitancy to pursue it at this time.
We'd love to follow up on future research projects with the team. After the hackathon, I had 2 weeks of weddings, but I should be free sometime the week of July 11th. I'll book some time later this upcoming week once I talk to Theresa and coordinate some mutual availability.

Thanks for offering your perspective, I completely agree with your points. I also think that's an interesting approach to consider but also quite complex and not at all straightforward to implement. Sounds good, I'll put the application on hold for now.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Sounds good, just booked time for this Friday, let me know if that time suits, otherwise I can move it.

@adit313 was great chatting with you last time, I hope all is well.
Here are again the two RFPs I shared during our call:
https://github.com/w3f/Grants-Program/blob/master/rfps/open/ISO_8583.md
https://github.com/w3f/Grants-Program/blob/master/rfps/open/ISO_20022.md
As I mentioned, we'd be interested in supporting research and/or implementation on how to integrate with these payment standards in Substrate. I think you'd be a great fit for these, but let us know in case you're still interested in pursuing the Stardust project instead or something else.

Hi Alexio, happy to help with the ISO-8583 and ISO-20022 RFPs. I've taken a look at the open source tools and projects that can help integrate them into Substrate. I have an early-stage implementation plan that integrates the JS open-source libraries for ISO-8583 into substrate as JS and Rust have good inter-compatibility.
There is major issue though, Blockchains can't actually conform to ISO-8583. One of the most notorious and important events in a credit card is transaction reversals, colloquially called "chargebacks". The bane of every card accepting merchant, issuing banks and the networks themselves have full power to reverse transactions unilaterally. This kind of centralized control and authority doesn't exist within blockchains as finality is incredibly important to the consensus mechanism. Satoshi himself was really against chargebacks, and instead prefered escrow accounts.
 The 400 codes are all for reversals and that's a bigger strategic question of how the team would like to see those implemented. (Questions like "Do users have the ability to reverse transactions", "How long is the dispute window") Obviously, you can design a new token standard that is ISO-8583 compatible, but there are a lot of strategic questions. The strategic questions are really the hard part. In terms of coding, you'd just literally build a bridge from Rust to the open-source JS implementation, no sense in reinventing the wheel when the users most likely to use this pallet will already be familiar with the JS implementation anyway.
The closer traditional financial analogue to blockchains are things like wire transfers, which are irreversible. Those conform to ISO-15022 which seems like what is really being deprecated in favor of ISO-20022.
ISO-20022 is more broad and designed to work for generic financial exchanges including wire transfers, so it should be applicable to DLT and blockchains. However, even though I was just an analyst and didn't touch the tech stack at the bank, I completely agree with the ISO-8583 RFP language of "it might take some time before it’s actually fully replaced". There's no reason to "upgrade" to ISO-20022 for an institution for card payments or Mastercard/Visa and there is no deadline. As far as I've seen, the ISO-20022 is only really relevant for large European bank wires.
In terms of ISO-20022 compatibility, none of the major blockchain players seem to be there. I've taken a surface level look at their implementations, and it's seems to be a strategic decision because things like Ripple and Stellar are aiming to be at the interface of fiat and crypto, but everyone on the list is not exactly a traditional blockchain. Impel recently "made bitcoin ISO-20022 compliant"
 but it seems like more of a marketing stunt to get you to use the XDC network than anything material. Basically wrapped BTC tokens can be attached to ISO-20022 messages that are already on their XDC network.
I really don't think their implementation makes sense, it seems like it's the equivalent of if I just made my own Substrate chain but the transaction objects were ISO-20022 compliant XMLs instead of the normal Substrate transaction objects. ISO-20022 isn't optimized for message size or retrieval so it would really impact performance. A far better solution is to just have an API you call when you need to convert a Substrate transaction to an ISO-20022 compliant XML for external use or vice-versa. The problem becomes blockchains like Polkadot can't support all ISO-20022 transactions as there are reversals there as well.
If the team is open to it, I'm happy to pull together a deep dive for both as milestone 1. For ISO-20022 there is enough material for an in-depth summary on how competitors have integrated the standard, their limitations and what's likely to be the best implementation based on their experience. For ISO-8583, I can provide a summary of the strategic tradeoffs of implementing ISO-8583 in Substrate and a summary of the high-level decision you'd have to make regarding dispute windows, chargebacks, etc to create a compliant token standard.

Thanks Adit, that was a fascinating read and it's clear you have a lot to contribute in this area. Regarding the reversals issue, leaving aside the philosophical aspect, it shouldn't be a problem to implement this on Substrate, as you say, as a new token standard using ink! or even as a pallet enabling a parachain to support transactions which are compliant with one of these standards.
I can't speak for the entire team, but as far as I'm concerned I'd be more than happy to support such a grant and if other team members have any feedback they can share it with you once you've submitted the application.
In the meantime, I'll go ahead and close this one. Feel free to reach out if you have any questions.

Sounds good, I'll start by submitting a proposal for ISO-8583. Let me know if you'd prefer I start with ISO-20022 first.

Great! I thought you meant both in one grant - however you prefer.

I can make them into one giant proposal, but the logistics of it are probably more complicated than I think you are expecting when you wrote the RFP. As an example, one of the super complicated aspects of it is going to be making it PCI-DSS compliant, ISO-8583 messages contain PAN numbers, i.e. your credit card numbers. You can't exactly store those on a publicly accessible blockchain ledger... or at least I personally wouldn't want my credit card numbers on a peer to peer blockchain. PCI-DSS compliance is currently voluntary compliance in EU and the US on a Federal level, but states like Minnesota require you to delete the information within 48 hours.
I was thinking Milestone 1 for ISO-8583 was going to be work to identify and summarize all of these open challenges, and then research into how to logistically manage these requirements on the blockchain. Security/Reversals/Authority, the list goes on, and there are a lot of open questions that need some research to start making this work with decentralized ledgers. For example you could solve that privacy issue of revealing PAN numbers with one time use virtual cards. Or you can centralize, or maybe there is a decentralized solution. Obviously Visa/Mastercard/Baking just lock down the networks so only analysts can access the data with plenty of oversight, that's not quite going to work for blockchains.
ISO-20022 has some of the same issues, but it's not just credit card information so you'll have other things to worry about. That's why I think it makes sense to systematically approach this one at a time.

That does sound like quite the rabbit hole. Makes sense, in that case I fully agree it's a better idea to focus on one thing at a time.


Sharing Environment in Arc deadlocks

Because I seem to create environment quite a lot, I thought I could simply reuse in a server making frequent connections and so wrapped it in an arc.
It compiles without warning.
However this seems to lead to deadlocks in the c grpcio threads; perhaps a warning would be good ?

Close now. If you have further questions, feel free to reopen it.


html_use_smartypants deprecated in Sphinx 1.6; use docutils.conf

In Sphinx 1.6, html_use_smartypants is deprecated. To avoid typographical (curly) quotes, one must use a docutils.conf file at the same level as the conf.py file with the following setting:
[parsers]
smart_quotes: false

See also http://docutils.sourceforge.net/docs/user/config.html#smart-quotes

I don't see that option on the current template https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/doc_builder/templates/doc_builder/conf.py.tmpl

@stsewd because of https://github.com/rtfd/readthedocs.org/blob/master/requirements/pip.txt#L6


Assertion failure during inlining with --noopt

runtime/vm/intermediate_language.cc:821: error: expected: other->env() != NULL
Command[vm]: DART_CONFIGURATION=DebugX64 out/DebugX64/dart --noopt --ignore-unrecognized-flags --package-root=out/DebugX64/packages/ /usr/local/google/home/rmacnak/dart1/sdk/tests/language/do_while_test.dart
Took 0:00:01.178000
Short reproduction command (experimental):
python tools/test.py --noopt --exclude-suite pkg -t120 language/do_while_test
@fsc8000 @mraleph

Fixed by 2306f29cc42590143a6b29048186f8a7e4a11e37


Error while ionic start - "There was an error with the spawned command: npminstall"

Hi,
I searched an answer but don't find any concrete solution to my problem.
I work on Linux Ubuntu (latest) and on Windows 10 as well on DualBoot.
Commands that doesn't work

ionic start
ionic start projectName
sudo ionic start
sudo ionic start projectName

What version of softwares are you using?
Cordova CLI: 6.5.0
Ionic CLI Version: 2.2.1
Ionic App Lib Version: 2.2.0
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Linux 4.4
Node Version: v7.6.0
Xcode version: Not installed
Short description of the problem:
When I try to create a new project with CLI passing his name, I have this issue:
Creating an Ionic app in /mydocs/APP/testIonic based on the tabs template.
Downloading: https://github.com/driftyco/ionic-app-base/archive/master.zip
Downloading: https://github.com/driftyco/ionic-starter-tabs/archive/master.zip
Installing npm packages (may take a minute or two)...
Running exec command: npminstall
Spawn command completed
Error with start undefined
Error Initializing app: There was an error with the spawned command: npminstall
There was an error with the spawned command: npminstall
When i try with ionic start wizard, after a few minutes it return "undefined" in red on the webpage.
What behavior are you expecting?
Try to create a project.

I have got any more informations as a npmdebug.log or anything. The folder exists and there's some files in it.

My windows ionic info

Dependency warning - for the CLI to run correctly,
it is highly recommended to install/upgrade the following:
Please update your Cordova CLI to version  >=4.2.0 npm install -g cordova

Your system information:
Cordova CLI:
Ionic CLI Version: 2.2.1
Ionic App Lib Version: 2.2.0
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Windows 10
Node Version: v6.9.2
Xcode version: Not installed

Dependency warning - for the CLI to run correctly,
it is highly recommended to install/upgrade the following:
Please update your Cordova CLI to version  >=4.2.0 npm install -g cordova

Cordova is installed but ionic don't want to give me version, may be an installation problem

Hi, I'm upping this issue because I still have the problem.

I have same problem....

I fexed it is. useing "npm cache clean"  and then "ionic start myApp --v2"

It's finally working.
To make it work, I just have to set my global node_modules folder restrictions to 777. It can be an issue for security.
However, thank you.
Elric Reffuveille


Integration fails to set up after update/restart

Hello,
Thank you for building this integration and app.
I had set it set up successfully and it appeared to be working. After an update/restart of HA the integration then fails to set up. Attempts to reload/restarts haven't worked so thought I should report it here.
HA 2024.1.0b5
App 0.1.1
Log as follows:
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 406, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/companion_bt_proxy/__init__.py", line 39, in async_setup_entry
    scanner = CompanionBLEScanner(hass, entry)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/companion_bt_proxy/scanner.py", line 11, in __init__
    super().__init__(hass, entry.entry_id, entry.title, bluetooth.async_get_advertisement_callback(hass), None, False)
  File "src/habluetooth/base_scanner.py", line 194, in habluetooth.base_scanner.BaseHaRemoteScanner.__init__
TypeError: __init__() takes exactly 4 positional arguments (6 given)

There was indeed a number of breaking changes (which weren't considered breaking by their authors). I've updated the integration to 0.1.1 which should hopefully restore the functionality

Thank you, your latest version has resolved the error - I appreciate the fast response and fix. I've got quite a few android phones with broken screens or in use as touch screen controls that I will be ideal as bluetooth proxies. so will be adding a few more to fix my flakey HA bluetooth devices.
I had a feeling the issue may have been the bluetooth code changes,  there has been a lot of BT code changes lately and I noticed a conscious decision not to publicise the breaking changes as they assumed no bluetooth proxies had been developed as custom components outside of HA core.
Thanks again for writing it!

Fixed


Download paper

This updates the build to build typst in the action. If you are using latex, that is going to be quite a bit harder in github. Docx should work in a similar way if you want it as well.

Default typst template does an ok job, certainly some improvements we would want to make!

This is awesome! I've never used typst but to be honest this is fine for us for now. When we get to producing the final copy of the paper we might muck around converting to latex or just go ahead and use typst, but this will do brilliantly for now. Thanks!


Toggle developer tools in preferences

The developer tools are currently on in preferences by default. This should be a toggle and off by default. It could be a keyboard shortcut or an environment variable. Or, something else.

Done already!


fix: too many open files error

as a team: fix the "too many open files error"
in order to stabilize the task listener
Dod:

The task listener is running without error
To validate, execute at least 20 bridge operation

Here is a error message:
Task exception was never retrieved
future: <Task finished name='Task-113' coro=<consumer() done, defined at /Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/.venv/lib/python3.12/site-packages/aio_pika/queue.py:31> exception=OSError(24, 'Too many open files')>
Traceback (most recent call last):
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/.venv/lib/python3.12/site-packages/aio_pika/queue.py", line 37, in consumer
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/src/relayer/provider/relayer_register_aio_pika.py", line 196, in _callback
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/src/relayer/application/consume_events.py", line 576, in callback
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/src/relayer/application/consume_events.py", line 537, in manage_event_with_rules
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/src/relayer/application/consume_events.py", line 435, in execute_smart_contract_function
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/src/relayer/application/execute_contracts.py", line 30, in init
File "/Users/arnaudsene/Documents/Code/blockchain/projects/Allfunding/bridge-relay-poc/relayer-py/src/relayer/application/base_logging.py", line 73, in init
File<EMAIL_ADDRESS>line 1214, in init
File "", line 423, in abspath
OSError: [Errno 24] Too many open files

Add a new repository provider using sqlite Async
Unit test done
Need to implement the logic

Fixed issue with logging
Implemented databases (sqlite, postgres, leveldb)
Need to validate rocksdb and/or lmdb for concurrent


mpirxx.lib

vcpkg install mpir mpir:x64-windows mpir:x86-windows-static mpir:x64-windows-static
But where is the mpirxx.lib?

Hi @huyuguang thanks for posting this issue.
I submitted a PR to add mpirxx.lib to mpir. Could you help take a look and confirm if this can work for you?


Username

The instructions in the README say that the password is jetson, but what's the username? I'm trying to use your image on a headless jetson nano and to SSH into it (hoping there's an SSH server running out of the box) I also need the username. I tried to connect via serial but it didn't work.

The username is also jetson.
SSH is running out of the box as you can see below.

Thank you


Setting styles

Really happy with how Anvil is working, and I'm writing new functionality for my app using it.
I'm having trouble assigning styles to elements created by anvil. For example, I want to add a shadow to the text on a button. Using standard layouts I can do something like the following:
<style name="ButtonText">
        <item name="android:shadowColor">#000000</item>
        <item name="android:shadowDx">1</item>
        <item name="android:shadowDy">1</item>
        <item name="android:shadowRadius">2</item>
    </style>

and then set the style from XML. However, it doesn't look like there is a way to set the style on an element programmatically, and thus no way to do it from anvil. Am I missing something?

Glad to hear you're making progress with an app using Anvil!
As for the styles - I'm open to any suggestions. Meanwhile I'm using good old functions to style views. In your case (using java) shadows can be set in java using setShadowLayer(r, dx, dy, color) view method, or with Anvil:
public AttrNode buttonTextStyle() {
  return attrs(
    shadowLayer(2, 1, 1, Color.BLACK)
    // maybe some other style attributes go here as well
  );
}

v(Button.class,
  buttonStyle());

Does it make sense? In my experience every XML attributes corresponds to some java method of a certain view class. We're just too much used to the (misleading) names of the XML attributes, that it may be really hard to find a matching view method.

Oops. I see what you mean. There is no generated shadowLayer() method because it takes 4 arguments and generated methods use only one (since it's a typical case to set just one attribute value). Here I see three ways:

Write your own AttrNode generator in your app (see examples in the Attrs.java, you may put 4 parameters into a List, so that equals() will be true iff all 4 parameters are equal). I did similar for admob views and my own custom views.
This may be a common case, so your AttrNode generator can be added to trikita.anvil.v15.V15Attrs, which is hand-written parent of the trikita.anvil.v15.Attrs class
If there is a lot of setters with more than one parameter - it would make sense to fix gen.gradle to generate methods in Attrs class for those setters as well.

One more option would be to add some style() generator to Anvil that will add some style ID to the view properties without applying it. Then fix Anvil renderer to look for that style ID and use ContextThemeWrapper if ID is not zero. This will bring the support of styles. I personally find styles XMLs very ugly and of course prefer pure java styling, but Anvil users might think the opposite. Also this solution requires hacking renderer to look into AttrNodes, which are treated as black box right now. So it would be another leaking abstraction forced by the broken android API design.

Good suggestions. I agree that the Android API (including the divide between styles vs themes vs attributes... wat) is very painful to work with -- that's why I'm using Anvil despite its early state. :) If I can do everything I need to through the Anvil API without having to use styles that would be preferable from my perspective.
I ended up going with option (1) because it seemed the easiest to implement. I can add it to V15Attrs or BaseAttrs in a PR if you think it would be generally useful. And if we run into this more frequently (3) might make sense -- I don't have a good idea of how common these multi-method setters are yet, since I've mainly used the xml layouts for styling and layout up to now.
	public static AttrNode shadowLayer(final float radius, final float dx, final float dy, final int color) {
		final List<Object> params = new ArrayList<Object>() {{
			add(radius); add(dx); add(dy); add(color);
		}};

		return new SimpleAttrNode(params) {
			public void apply(View v) {
				if(v instanceof TextView)
					((TextView) v).setShadowLayer(radius, dx, dy, color);
			}
		};
	}

I scanned the android.jar in API levels 10 and 15 - it looks like there is only about 40 setters with more than one parameter. However, most of them are the ones I never heard of:
API level 15 (in API level 10 there's even less):
setAppWidget
setChildIndicatorBounds
setColorFilter
setColumnCollapsed
setColumnShrinkable
setColumnStretchable
setCompoundDrawables
setCompoundDrawablesWithIntrinsicBounds
setDate
setEGLConfigChooser
setError
setHttpAuthUsernamePassword
setImageState
setImeActionLabel
setInAnimation
setIndicatorBounds
setInterpolator
setItemChecked
setLayerType
setLineSpacing
setOutAnimation
setPadding
setParentTitle
setPopupOffset
setPrevNextListeners
setQuery
setScrollIndicators
setSelectedChild
setSelection
setSelectionFromTop
setShadowLayer
setSwitchTextAppearance
setSwitchTypeface
setTag
setText
setTextAppearance
setTextKeepState
setTextSize
setTitle
setTypeface

Most of them are just advanced versions of single parameter methods like setTag or setTypeface.
Probably they should be added manually on-demand, like setShadowLayer since most of them will never be used anyway.

Yeah adding them on demand is probably fine, there aren't many of those that I know what do that don't have single-parameter equivalents.

I've added the suggested shadowLayer to Anvil's BaseAttrs, so I'm closing this.

I've added the suggested shadowLayer to Anvil's BaseAttrs, so I'm closing this.

I think the bigger issue is that I currently have an app with a defined theme and style structure.  I don't want to be able to just add a single attribute such as match parent but instead add a style for example "MyTextViewStyle"

Here's some thoughts about how one can organize view styles in Anvil: http://zserge.com/blog/anvil-howto-style-views.html

There is some way to easily translate the android predefined themes to anvil? For example Widget.AppCompat.Button.Borderless and other Material elements. It's a pain having to hunt on all the sub definitions of the theme to recreate them in anvil.


Figure out why turns take longer as the game goes on, and fix it

Flintlock mentioned semi-recently that after about turn 20 things slowed down, and it sure does.  I've started investigating this, and found that galleys are always slow, and they're slow due to trying to find a path to their exploration destination.  Probably related to this, they can't move currently.  But sometimes other units are slow, too.  Log sample:
-> Begin Rome turn
Unit processing time for Chariot: 0 ms
Pre found new path time = 0 ms
Found new path time = 633 ms
Moved to new path time = 633 ms
Unit processing time for Galley: 633 ms
-> Begin Babylon turn
Unit processing time for Chariot: 0 ms
Set NEAR_CITIES exploration AI for Catapult with 1 movement points and 3 hit points, guid = 7130dd5f-c053-468f
-8257-2241ac68574b
Unit processing time for Catapult: 245 ms
Unit processing time for Warrior: 0 ms
Unit processing time for Chariot: 0 ms
Unit processing time for Warrior: 0 ms
Unit processing time for Chariot: 0 ms
Unit processing time for Warrior: 230 ms
Unit processing time for Chariot: 0 ms

I've added some logging on the SlowTurnsInvestigation branch to produce this, using the Stopwatch class for the timings.  200+ ms for one unit is obviously too slow.
This is tested by fortifying all my units at game start, and then pressing down both the Enter and Shift keys at the same time.  Enter keeps turns rolling, Shift skips all the animations.  So the only thing it's doing is processing the mechanics/AI.
The catapult happens to be bombarding a city in this log, so it's possible that some of the slowness is when combat occurs (even if animations are shift-skipped).  But the galleys are definitely pathfinding-related or pathfinding-adjacent.
(This is also an area where nifty logs might be useful.  For example, if we detect a unit taking longer than, say, 100ms, we should increase logging so we can investigate why (although this depends on having useful logging in the first place.  But at least a warning would be nice regardless).    Rome is at 67, 35, and built a galley.  With more logs, it prints:
--> Begin Rome turn
Unit processing time for Warrior: 0 ms
Unit processing time for Chariot: 0 ms
Pre found new path time = 0 ms
Valid explorer tile time = 0 ms
Pre algo time = 0 ms
Algo time for [67, 31] (Coast on Coast) = 16 ms
Algo time for [66, 32] (Coast on Coast) = 33 ms
Algo time for [63, 35] (Forest on Grassland) = 33 ms
Algo time for [68, 30] (Coast on Coast) = 49 ms
Algo time for [71, 33] (Coast on Coast) = 65 ms
Algo time for [69, 29] (Coast on Coast) = 81 ms
Algo time for [70, 30] (Coast on Coast) = 99 ms
Algo time for [71, 31] (Grassland on Grassland) = 99 ms
Algo time for [72, 32] (Coast on Coast) = 117 ms
Algo time for [72, 34] (Coast on Coast) = 134 ms
Algo time for [73, 35] (Coast on Coast) = 152 ms
Algo time for [72, 36] (Coast on Coast) = 169 ms
Algo time for [65, 31] (Coast on Coast) = 187 ms
Algo time for [63, 33] (Coast on Coast) = 205 ms
Algo time for [64, 32] (Coast on Coast) = 223 ms
Algo time for [62, 34] (Coast on Coast) = 240 ms
Algo time for [62, 36] (Coast on Coast) = 257 ms
Algo time for [64, 40] (Forest on Grassland) = 258 ms
Algo time for [69, 41] (Jungle on Grassland) = 259 ms
Algo time for [68, 42] (Grassland on Grassland) = 259 ms
Algo time for [67, 43] (Hills on Grassland) = 260 ms
Algo time for [66, 42] (Forest on Grassland) = 260 ms
Algo time for [65, 41] (Forest on Grassland) = 261 ms
Algo time for [61, 39] (Coast on Coast) = 278 ms
Algo time for [60, 38] (Coast on Coast) = 294 ms
Algo time for [61, 37] (Coast on Coast) = 312 ms
Algo time for [63, 41] (Grassland on Grassland) = 312 ms
Algo time for [62, 42] (Grassland on Grassland) = 313 ms
Algo time for [61, 41] (Coast on Coast) = 330 ms
Algo time for [60, 40] (Coast on Coast) = 346 ms
Algo time for [72, 38] (Coast on Coast) = 363 ms
Algo time for [73, 37] (Coast on Coast) = 380 ms
Algo time for [73, 39] (Coast on Coast) = 397 ms
Algo time for [72, 40] (Coast on Coast) = 414 ms
Algo time for [71, 41] (Jungle on Grassland) = 415 ms
Algo time for [70, 42] (Jungle on Grassland) = 416 ms
Post algo time = 416 ms
Debugging hopefully is useful

So it's doing pathing for 36 tiles, about 11.5 milliseconds per tile, though with some considerable variation.
It's noteworthy that all the tiles that take > 1 ms are coast.  Coast takes 16-18 ms typically.
I highly suspect this is due to our DijkstrasLandAlgorithm not being able to find a path to a sea tile, but trying everything in the book in the attempt.  But I'm a bit too tired to investigate that definitively right now.
It's also worth noting that each of those "algo time" statements is re-computing using Dijkstra from the same starting tile.  We knew this could be a hazard, as seem in the comment:
				// TODO: this is fastest if recomputing Dijkstra's for each unit
				// and ignoring that units may path from the same starting tile
				if (closest.Key == destination) {
					break;
				}

At a higher level, the reason the ExplorerAI is calling pathing from the same starting tile so many times is that it's trying to figure out what the shortest path is to an area where exploration is needed, and to do that, it's looking at all possible places to explore, and asking, "how far away is this tile from where this unit is located?"
Now in this particular case I don't think the "not caching if it's from the same start tile" case is making things worse for galleys, since we're asking for impossible routes, and that's causing exhaustive searches that are in vain.  Although in the cases where there are non-impossible routes, the well-intentioned ExplorerAI looking for the shortest route, and the well-intentioned Dijkstra short-circuiting for the fastest results assuming the start tile will change, happen to interact in a way that produces the slowest possible results.  But they're still dwarfed by the impossible galley searches.
My guess is the slow Warriors/Catapults/etc. may also be due to seeking impossible routes to water tiles.  They'll eventually get a path to somewhere they can reach, so they don't necessarily run into this every turn like the immobile galleys do.
Short term solution: Have the pathing return "no can do" for routes from land to sea (other than harbor to sea, if it's a sea unit).
Longer term, there's definitely the potential for caching if the algorithm detects the same start tile twice in a row, without the cache having been invalidated.  Or perhaps there's the possibility of adding a method that takes a list of tiles that we're looking for.    Just didn't expect it to crop up quite this early.

Plot twist - logging is slow.  Not sure why/what part of it is slow (beyond the Filter.ByIncludingOnly part of LogManager not making a difference).  But even if I just log a hard-coded string, in my seeded-random-number example where it looks at 6 paths, it takes the average from 2 to 11 milliseconds, or +1.5ms per path.  This means that the log statements are responsible for over 80% of the run time.
It's a sort of Heisenbug situation where applying debug methods to evaluate the state changes the characteristics of what you're trying to debug.

Once I got the logs fixed up a bit, I figured out some of what's going on.  Basically, when a unit finished exploring an area, it needed a path to a new area to explore.  It evaluated all the possible places it could explore, which took a long time, especially with fresh paths to the farthest places.  Now, it'll start with the closest tiles (as the crow flies), and if it can get to them quickly, it won't even bother with ones farther away.  In testing, this saved 85/86ths of the time in my Babylon test case.
This also allowed turns to be speedy until about turn 200, which is when they used to slow down.  While I'm not sure this is all of it, the improved logging also allowed me to see that every turn the Dutch AI was burning time asking for a route to tile 37, 27, which they knew existed but which was on another continent.  This led to an exhaustive search, taking 21 milliseconds, for a route for every request, and they were asking 155 times, for every spare unit, taking 3.255 seconds on turn 291.  They had over 40 cities by this point, so the number of units was increasing quickly.
The other AIs were also spazzing out a bit trying to send their units on boats (and some of the AI actually figured out how to move boats, I didn't know they could do that), but their actions did not take nearly as much time as the Dutch pathing requests.
I suspect there are other inefficiencies as well, which improved logs will help us spot.  Notably, the city graphics blink in the late game, and I'm sure they're not optimized given they were quite early on, so I suspect lots of city graphics = late game slowdowns as well.


Issue and PR Templates

We need to make some clean and useful Issue creating templates as well as some PR templates. @WallyThePenguin Would you be able to take this on?

Sure, I'll send a draft and we'll edit it from there.


boolean is highlighted incorrectly in JavaScript

It should not be highlighted when called as a function.

In all 3 cases above, boolean is scoped as storage.type.js.ts, other is scoped as js.

This issue was moved to Microsoft/TypeScript-TmLanguage#68