Try   HackMD

UX Working Group

Working Group Repository
Video Meeting Link
Telegram Invite
Calendar Invite

Mission Statement

Highlight, discuss and solve the emerging challenges that need to be addressed by application level developers to ensure a high quality user experience when dealing with an IBC connected Internet of Blockchains. This is part User Interface questions (how to display an IBC connected asset? What level of transparency or insight on security should be my responsibility as an interface developer?) as well as developer experience questions (how do I query the balance of a user with mutli-chain assets and display those assets in a clear and friendly manner?).

15th Meeting: Monday JUNE 8th 3:00 - 4:00pm UTC

Introductions:

Updates:

  • Andrew to discuss latest on Registry

New Topics:

  • Discuss what further items to include in the Registry (Sunny)

Discussion:

Registry not just useful for verifying chain identity. It's also useful to bootstrap new nodes. Especially automated deployment of new nodes.

  • version number, binary location, genesis may seem superfluous but are important if you want to run a node (nowhere else to get all this info in one place)
  • maybe home directory is a bit much
  • take everything from Sunny's tm-network json
  • Denominations, fee denoms
  • Faucet URLs (for testsnets)
  • ETH TokenLists for Cosmos is needed too

Discusssion: Best approaches for crawling the network, check if nodes are really active

  • Some tools are already out built by the community
  • Adam: relatively easy to get blacklisted by nodes on the P2P port
  • 26656 is usually the only port exposed. security reasons
  • 26657 usually not exposed because easily DoSed, but useful for any browser/webapp that needs to query stuff
  • 9090 GRPC mostly used for backends querying nodes, but needs batched requests
  • having a list of 5-6 publicly (i think he means all available ports?) available nodes really helps for ux.
  • Sunny really wants batched RPC requests on 9090, similar to GraphQL would be super useful, since for osmosis a lot of requests are necessary.

Misc Topics:

Next Meeting:

14th Meeting: Monday MAY 25th 3:00 - 4:00pm UTC

Introductions:

  • Cullen - Billy invited to get more involved with IBC related topics get the lay of the land
  • Laura Sauer - gone

Update:

  • Andrew
    • Registry
      • Working Demo
      • one outstanding buig peer list only records a single node
      • the person who claimed that chain id would set up their own cron job
      • this could use github actions to set it up
        • only those in the codeownerfile and registry admins / maintainers
    • Asset guide
    • Question for Josh
      • how does Keplr do this?
        • not verifying atm

New Topics

  • IBC Asset Registry
    • Denom paths for validators
    • https://tokenlists.org/
    • Antoine's token registry
    • Tip function
      • Keplr API is implementing this
      • specific format of a memo
      • front end tells keplr i woudl like to tip this person this amoutn (as part of the memo)
        • keplr reads this, the memo is used and then keplr standizes a tip interface
        • Relayer fees

Misc topics

  • demo for consensys talk
    • there's not a good place to find token decimals, icons
    • trust wallet / CAIP
    • the chain registry could verify all tokens on each of the chains
  • Pieter from Confio
    • want to present soon

Next meeting

  • Pieter from Confio
  • Denis from Starport

13th Meeting: Monday MAY 10th 3:00 - 4:00pm UTC

Update:

Recap & Outlook presentation:

https://hackmd.io/@apeunit/ryY773LOu

Improvements suggestions:

  • General sentiment: Focus on everything that the DEX needs to move assets around

Individual Suggestions:

  • (Jack) Most pressing issue registrar and registry running, doesn't make sense to focus on other topics before that one is solved.
  • (Josh), registry and registrar, IBC Asset handling, DEX vs Osmosis
  • (Rowland) Helping developers
  • (Billy) Walk-through sessions
  • (Jack) Integrate it with a relayer, doesn't have to be golan.

Twelfth Meeting: Monday APR 26 3:00 - 4:00pm UTC

  • Welcome:
    • Jessica (Interchain)
    • Pieter (Confio)
    • Ethan Frey (Confio)
    • Gautier (Tendermint)
      • navigator wallet
      • relayer user
      • starport network
      • chain name service
  • Updates
    • Chain Registry & Guides / Tutorials
      • IBC tutorial link
        • initial feedback
        • how to use via gaiad
        • how to detect a fake token
          • an invalid asset
        • getting lower level querying via gaia rpc endpoint
      • Chain Registry
        • README
        • get people using it
    • Jessica IBC visualizer preview
    • Gautier topic

Eleventh Meeting: Monday APR 12 3:00 - 4:00pm UTC

  • Welcome:
    • Vanessa from Agoric
  • Updates:
    • Chain registry github:
      • Updated to latest sdk version
      • Testing a new version that can check chains periodically
      • Goes beyond seed nodes
      • Open questions: When shall chains be declared as "inactive", current suggestion 5 re-tries
    • Update tutorial to verify IBC assets:
      • Necessary cosmjs code is present but released yet
      • Client sync status is currently difficult to determine, will probably not be fixed before the release of the tutorial
    • Project Intros:
      • Nass working on a Navigator with a focus on DeFi:
        • Currently focusing on "single-hop" assets
        • Multi-hop assets need to be redeemed
        • Covering tx fees, for redeeming assets is currently an open issue leading to a sub-optimal UX, but there is hope for the next version

Tenth Meeting: Monday MAR 29 3:00 - 4:00pm UTC

  • Welcome🤝
    • Sam Panter
      • Multi-Sig Web Application
  • Updates🚀
    • IBC Token Transfers are eabled
      • dev.wallet.keplr.app allows transfer over channel-66
    • Agoric
      • Working on a demo to take an ATOM into tesnet and lock into a vault
  • Wallets: Verifying IBC Assets🙇
    • gaiad q ibc --help
    • gaiad q ibc-transfer --help
  • Discuss upcoming topics
    • token transfers
    • chain registry
    • scaffolding tools

Ninth Meeting: Monday MAR 15 3:00 - 4:00pm UTC

  • Introduction:

    • Gautier

    • Ape Unit / Andrea

      • github chain registry
      • close to complete working version
      • can be executed as a service
      • state of the chain ID
      • were dealing with a race condition
      • 1 week for a PR
      • SDK version dependent?
        • hasn't tested with latest v0.42.0
        • tested with v0.41?
        • if no breaking changes related to the endpoint
        • using REST endpoints

    • Asset registry / Antoine

    • Billy proposing the idea of asset families, where one asset can have "children" on different chains

  • Updates:

Eighth Meeting: Monday, Feb 15⋅3:00 – 4:00pm UTC

Focus Topic: Interchain Accounts

  • Introduction of new-comers
    • Bastian
      • trust infrastructure, endorsements
      • on chain endorsements
      • support multiple blockchains
    • Hyung from B-Harvest
      • follow up progress on ICS-27
      • Implementation planning for Cosmos Hub Mainnet
  • Updates on existing working tracks
  • Focus topic: Interchain Accounts

Seventh Meeting: Monday, Feb 1⋅3:00 – 4:00pm UTC

Focus Topic: Blockchain Explorers

  • Welcome new members
    • Mira from Map of Zones
    • Rick from Vulcanize
      • working on Tendermint / Cosmso for a long time
      • Chain registry with Auctions
  • Updates from other projects (12 mins)
    • Chain working Group (Denis)
      • first call was last week
      • adding new chain ids
      • mapping chain id and seednodes and correlating via IBC versus correlating via governance
      • GitHub Issue 100
    • GitHub Registry
      • testing access rights
      • tmcrawl learnings
      • plan to bring learings back to on-chain registry WG
      • next steps is a tutorial
    • Map of Zones
      • Mira presenting
      • Where they're at not
        • explorer of all the zones with an IBC connection with at least one zone
        • only focus on IBC interactions between zones
        • can only show one hub of tokens
        • showing a single testnet right now (not a lot of activity)
        • Map of Zones 4 node testnet
        • some zones may only focus on outgoing transactions
        • percentage of IBC transactions vcompared to total transactions
        • TBD: What is most interesting to the user
        • number of connections
        • Outsider wants to see: Where can I send my tokens directly from one zone to another
          • I can see there are only 3 options, can use the map of zones to see options as well as paths to a far away zone.
          • Click a spceific zone to reveal more of network topology
      • Furutre Direction
        • once multi-hop IBC transfers take place will be better informed
        • making map 3d and with more data
        • What additional metrics for a specific zone
        • topology at large
      • mapofzones.com
      • github.com/cosmos/registry
        • what zones are online, what is their topology, where are the active relayers that one can use (do they do it automatically or not)
        • No incentive at the moment to close channels, find out which relayers are active might be difficult
        • Do we need a relayer registry?
        • Denom might be missing
      • Who is the primary user?
        • token holder, intersted in looking at where they can hold / send tokens
        • Mira: under active discussion, hard to predict
        • They think right now to focus on the metrics, select one particular zone, more data and stats compared to other zones
        • Where is it connected and where is the zone at?
        • less information abuot standalond and more how it acts
        • also to show new people in the ecosystem how active cosmos is
        • network discovery
          • new zone i haven't heard of, i want to go and look at it
      • initial use and values
        • started as a hackatom project (hackatomV) then came game of zones
          • wasn't an actual leader board
          • focus was on keeping the connection alive (needed to send a particular type of transaction that wasn't available to the user)
          • phase 2 and 3 were more relevant
            • the most amount of packets (that was a highlight for map of zones)
        • increased expectations on how many zones could be there
        • some people were blocking IPs so data wasn't correct, reaching out to those people to get a good relationship to track the RPC endpoing
        • What can we do with that dry data and how to surface it to users who are less technical but interested in zones and interactions
      • Do you see this more as a tool or as a future of how this could developer—for users to trade an asset back to the origin—or more as a tool for developers to better understand what is going on in the network
        • less about token history (right now there isn't a clear desicn for multi-hop interactions)
          • not clear to track where the token came from
          • hard to figure out that the token went out successfully but failed to come into zone b
          • how do we surface that information to the user
          • tracking token transfers historically
        • for developers
          • i'm a new zone, where do i need to be connected
          • other hubs available, or if my goal is to connect to 3 zones how do i get the best connection there
        • for investors
          • want to see how "connected" that zone is
        • tool to surface information that isn't otherwise available
        • much easier to tell if a chain-id is legit from looking on map of zones compared to making all of the queries necessary to do the same
  • Relayer group needed
    • set up a relayer chat on discord or telegram and invite initial group + relevant wallets
  • Recap & Takeaways (schedule topic specific talks, 10min)

Sixth Meeting: Monday, Jan 18⋅3:00 – 4:00pm UTC

  • Welcome new people
    • Rowland from Agoric
      • Joined Fall
    • Vanessa from Agoric
      • Director of Partnerships
    • Benedict Lau
      • new to ecosystem, bg in engineering ?& mesh networks and dweb
      • work with group in Tornoto called Hyperworker Cooperative
    • Sean King (Interchain GmbH)
      • Engineering at SAP and BrickBlock mostly in Eth
    • Kwun (Forbole & Desmos)
      • BigDipper & Desmos
    • Alex Bez (Interchain GmbH)
      • Tendermint Core team
    • Deepanshu (Persistence)
      • NFT working group
    • Philipp Klein (Ape Unit)
      • Full Stack Blockchain
    • Peng Zhong (Tendermint Inc)
      • CEO
      • Chain Name System
      • Starport
  • Chain Registry Updates
    • Atlas (Bez)
      • Weights for nodes?
      • For every node we reach we can set metadata about it
        • inbound and outbound connections
        • syncing or caught up
        • liveness
      • Attribute a health score / weight
      • Crawls every configurable duration
    • ApeUnit
    • New Working Groups
      • Wallets and Explorers
      • Chain Naming Service / Registry
        • Topics
          • Auctions on hub
          • Starport
        • Tasks
          • More chains use the github registry with contributors permissions
            • Desmos
            • Agoric (testnet)
          • New Registry Topics
            • Chain-ID
            • Genesis?
            • Account addresses?
            • IPFS?
            • SeedNodes
          • Registration System
            • Buy & Sell IDs
            • Register for free with certain prefixes?
            • Shorter Chain IDs could be purchased, proceeds could go to community pool
            • Blockstack Method
              • put money in a wallet and allow to spend from it for new project(?)
            • Weekly call & write a spec
      • DID / Accounts
  • Block Explorers
    • ZTake & Map of Zones [WAIT TIL NEXT WEEK]
    • Welcome BigDipper
  • Mobile Development Survey
  • Survey from ApeUnit
    • Future topics
      • WalletConnect
      • Interchain Accounts
      • Flutter and Mobile Development
      • Groups and Sub-Keys Modules
      • Identity

Fifth Meeting: Monday, Dec 21⋅3:00 – 4:00pm UTC

  • DNS for IBC
    • Dennis
      • Chain name service
      • Tendermint Inc / Starport Cloud / Starport Network
      • Interchan Conversations Demo
      • Handy way to launch blockchains
        • Coordinate the creation of the genesis command
      • Uses starport network (github.com/tendermint/spn)
      • Could store information about chains
    • Could some chain information be on the Hub?
      • Possible upstreaming of chain information SPN -> Hub
      • Hub Minimalism
        • IBC enables scaling hub capabilities outside of the hub
        • Cross chain validation allows hub security
      • SPN could have enough momentum to warrant be canonical location
      • Disadvantage of having it on the hub?
        • Risky, doesn't allow fast iteration, might take a long time to get there and no guarantee
        • Cosmos vision includes many blockchains so putting every feature on one goes against that vision
      • Pedro
        • Overhead of data on chain might as well be at a place of high discoverability, hub has strong network effects, hub denotes discoverability along with routing
      • Denis
        • Using SPN is also a path towards the hub
        • Test new features on separate networks and aim towards hub after iterative approach
      • Iteration
        • First github, then separate zone, then hub
        • Be wary of competing versions
      • Context of Starname and Chain information
        • Focusing on people and organizations for human readable account address
        • Interested in getting asset id's configured properly
      • Github solution could use redundancy
        • Radicle approach
        • Gitbackup
        • IPFS
  • Update on the Registry
  • Map of Zones
    • Mira Storm
    • maps
  • Messaging on wallets?
    • Sunny wants to send a message to all delegators of his validator
    • This is more of an interface question—would wallets want to start supporting the memo field better
  • Chain Agnostic Standard Alliance
  • Any working examples of cross chain contract call proxying system on top of IBC?

Fourth Meeting: Monday, Dec 7⋅3:00 – 4:00pm UTC

Recording: https://youtu.be/mX4g1WKdDu0

  • ApeUnit Stewarding
    • Neueux.com (tba)
    • Reaching out to participants to collect emerging ux challenges
  • Welcome New Faces
    • Andrew Chiw
    • Shaun Conway
    • James with ApeUnit
      • Communications and marketing
  • High level priorities
    • Next steps on registry
      • Concrete tasks
        • Cron
        • CODEOWNERS
        • tm-crawl
        • Create cosmos repos for further mgt
      • Location
        • If in cosmos, can be automated to be included in chain agnostic registry
          • Recommended by Pedro (?)
    • Separation of DevX and UX
      • Emerging CosmJS working group as well as dev adoption working group
    • Discuss extensions ot CAIP 27
      • Contact Pedro and Fede to push this topic forward
      • Multi-query seems to be the way to go
      • Rick scenario
        • Imagine there’s a chain with a fork
        • Who knows what kind of node you need to be running in order to resolve that query
          • Full node? Light node?
        • Abstraction
          • Find what an origin is
            • Hash linked data structure in order to provide verification
          • Assume these all exist at a single endpoint
          • Example: Rick’s chain
            • It’s like iota (no provenance for all assets created)
              • Can’t access this system, needs to be a blockchain or a state channel (hash linked data structure)
            • If we have that structure and all the assets needed to link that hach linked data structure (assuming they all can do this)
            • We have a pool of all checkpoints we’d ever need within our registry
              • Can’t come in if there’s not someone providing checkpoints
              • This is the cron for keeping these in sync
              • Fine to use github as the initial solution
              • Needs more than the automation of a cron job doing this work
              • Find out where the Filecon work is on this topic
        • Question
          • If a denom is being renamed does it break everything?
          • IBC Question
            • Do denom changes cascade?
          • Chain ID is stored on the client side
            • Just needs the validator set
  • Future topics / projects
    • Mintscan
      • Multi chain Block explorer
    • ZTake
      • Map of zones
    • Confio
      • IBC visualizer
    • Filecoin
      • Verifiable checkpoints
    • UCRegistry
    • Starport
      • Genesis coordination for onboarding validators
    • Chainapsis Keplr IBC findings
      • Reach out to Josh
      • Customer view would be helpful
    • CAIP - Deep Linking
      • Trust Wallet, Starname (Antoine)
  • New Members
    • UX improvements on Tendermint
      *

Third Meeting: Monday, November 23⋅3:00 – 4:00pm UTC

  • Status update on github discoverability progress
  • New Questions
    • Priority: Give feedback!
    • TODO: Automating the checkpoints (cron)?
    • What does it look like to build a node?
    • What does it look like to build a relayer with this information?
      • RPC endpoints are needed for statesync
      • In order to enable statesync you need to pass tendermint two RPC endpoints, anyone who wants to run a new node needs to run their own two nodes
      • Small critical mass of RPC endpoints and create a culture of people building RPC endpoints
        • ICF?
        • AiB?
        • Chainapsis?
        • Some Validators
        • Chainlayer => Quicksync
          • Still takes ~12 hours
        • Forbole
        • Figment => DataHub
        • Social pressure + small grants
          • Bounty program for uptime
          • Fixed amount distributed to nodes that are up
          • Automated polling
        • Statesync specific endpoint
          • Need RPC for light client
          • Why don’t we expose / integrate the light client into the P2P layer, then you don't need RPC for light client or state sync
          • Lean archival node
            • Only runs fast sync, always in fast sync mode, fetches new blocks and exposes RPC and only exposes data from the block store (commit, blockhashes) everything needed for a light client
            • DDoS vectors are still there
        • Minimal Viable Node
          • NGINX config
          • Cheapest plan possible
            • 4GB minimum
            • 2CPUs 8GB Ram
            • 500GB Disk
            • $80-$100/mo
              • GCP (Google Compute)
          • Enable State Sync
        • Easy to run solutions
          • EVENTEVIZE EZ Deploy
          • Validator package manager
        • Node service
          • Ping each node
            • 10 blocks from chain tip
            • 500ms latency
            • How much data is it holding
              • Pruning enabled?
          • Keep track of uptime
            • Rank and pay out top 10—100
        • Tm-crawler
      • People need to regularly run these on cron
        • Find someone from each network to run
    • TODO: CODEOWNERS enforcement
    • chainlayer/quicksync — potential user
  • https://github.com/ChainAgnostic/CAIPs/issues/27
    • Is it necessary to have a fully automated list of asset verification?
      • Alternatively you just limit views of assets you’ve personally verified
    • Manual or Automated process will need to have access to all relative blockchain RPC endpoints
      • Alternatively it would have to be network by network via communication channels
    • Query verification
    • Use Case
      • Resolving a chain id
      • Resolving an asset
      • Tied to each other
        • Once you’ve got the asset id you need the chain id
      • User perspective
        • The dapp needs the RPC endpoints
      • Who should be running the RPC
        • Wallet doesn’t have capacity to be infrastructure for various networks
        • Best interest in applications to provide
        • Wallets can bridge these services
    • Just saw Lunie sunset their infrastructure
      • Can’t sustain running servers
    • JS light client
      • Still needs RPC endpoints
    • Compensation for node operators
      • Pay on delivery
      • Pay for storage?
        • IPFS
      • Eth land
        • Celo has something similar already
  • Vulcanize
    • Generic IPFS blockexplorer
    • Convert blocks to IPLD blocks
    • Blockchain specific block explorer based on top of that
    • Generated IPLD data for Cosmos SDK apps
  • \

Second Meeting: Friday, November 13⋅2:00 – 3:00pm UTC

  • https://github.com/ChainAgnostic/CAIPs/issues/27
  • Link?
  • Discoverability
    • Yahoo
    • DNS
    • Search Engines
  • Relayer is similar to discoverability service
  • Naming Chain?
    • Peer discovery looking for RPC endpoints?
  • Ease of use
    • Relayer that allows querying many chains at once
      • Very doable
      • Blocker is finding RPC endpoints that is reliable for each of those chains
      • The logical service that is running all of these
        • Gets expensive quickly but with funding could set up for a year or two
    • Centralized version of name chain
      • Github registry
      • Code owners / roles for repos
      • Bot that easily updates the information
        • RPC that queries against all that it knows as well as pulling net info for
      • RPC crawler from bez
    • Name Chain
      • Some sort of oracle like properties for RPC endpoings
      • Continually update headers for these chains
      • DNS chain
      • Disambiguating human readable chains
      • Token Curated Registries
  • Data Provider
    • Data hub
    • Infura
    • For cosmos
      • What’s an easy way to pay for data provider access
      • This service exists
  • Uniswap’s token list
  • In Cosmos we need chain-ids
    • Not token lists
  • Denis
    • People will create different solutions
    • Whichever works will get critical mass
    • Chains start from starport network, DNS for chain ids
    • A chain is identified by an ID
    • Better not to make a standard that everyone will follow
    • Is it a goal of starport to become a chain naming service?
      • For the chains launching form starport network yes
      • It would naturally align itself to be the go to chain id name service
      • Register upgrades and genesis files here
  • Github idea again
    • It was a failure because it was more important for wallets to worry about asset ids rather than chain ids
    • The need may be back though
    • Need to access node IP address
    • When tey started, they realized what was most important was asset ID
    • P2P identifiers versys RPC identifiers
      • Slightly susceptible to DDOS so most people don’t make them public
    • Roots of trust for stake sync
    • Genesis files
    • Chain ids
    • ICF most trustworthy host
    • Cosmos most views
  • Seed Nodes as a service
    • What exists for ethereum or btc
    • Hard coded in the clients
  • Github list
    • What’s the risk?
    • What’s the vulnerability?
    • We don’t want infura because we can’t unseat it
      • Centralized points of failure because people start leaning on them
    • 6 month project with a 2 person team?
    • Chain starter / DID module
    • No one needs to run the nodes, just a service that queries the RPC for peers, genesis file and roots of trust for the light client and regularly updates the repo (via CI)
      • Requires at least one open RPC endpoint
    • Each chain project that exists should want to list their chain on this service
    • If we make the burden of running minimalist, otherwise as a validator i’m happy to run a daemon on one of my sentry nodes and provide the info for the networks i validate on
  • Brian
    • Validators could keep running this, why not include it in the relayer itself?
    • Relayer that connects to intermediary chains, lists all endpoints available for that chain, each validator of that network is already connected to that relayer
    • When the relayer bootstraps it requires a bootstrap root of trust for the light client
    • Relayer is pulling it from naked RPC endpoint
  • Josh
    • Native support on keplr, need this info on the repo and they will support it natively
  • Provider list
    • How to authenticate the provider
    • How to rank the provider?
    • RPC endpoints is a DDOS threat
      • They’re secured through anonymity
      • Initial goal maybe isn’t the RPC, build to that
      • Initially, peers, genesis and light client roots of trust allow anyone to build a new node trustworthy
      • Would allow bringing new nodes online very quickly
  • Data will change
    • Should we use a chain-id as the identifier?
    • Yes
    • Then you don’t need to worry about who is the “true” chain
    • Wallets want to know who is the “true” chain
  • This is just a building block
    • A relayer that can use this repo can provide other future services regarding the asset denominations and IBC

First Meeting: 10/29/2020

  • Attending:
    • Emil (ApeUnit), Dogemos (Chainapsis/Tendermint), Max (ApeUnit), Antoine (StarName), Dario (ApeUnit), Sasha (ApeUnit), Pedro (WalletConnect), Billy (ICF)
  • Agenda:
    • Intro
    • Identify the problems
      • IBC Coin Denoms
      • Reliable Chain IDs
      • Relaying IBC Packets
      • Interacting with Multichains with Wallets
    • We build interfaces around the technology
      • It’s nice if we can build the technology around the user experience
      • We all want to build our own applications for our own use cases but we also want to interface with each other with no conflict
      • CAIPs began highly opinionated
      • Universal Chain Registry
      • CAIPs and DIDs have a self explanatory pattern
        • protocol: method: value
      • Asset ID needs attention from this group
        • Resolution procedure
          • Put it into a client library?
          • Offers example as well as tool
          • Library should ask for a node provider tht can help resolve nodes?
        • CosmJS?
      • IBC x identifies how to query a node for IBC info to identify the asset
        • If that asset query returns another CAIP19, if i have prior knowledge of that chain I will use it or i will revert to a registry
  • Telegram Invite
  • Email invite
    • Chainapsis (Tony & Josh)
    • Lunie (Jordan & Fabo)
    • Akash (Jack)
    • Confio (Simon)
    • WalletConnect (Pedro)
    • ApeUnit (Emil, Max, Sascha)
    • Agoric (Dean, …)
    • 3box (Joel)
    • Cosmostation/Stamper (David, …)
    • Starname (Antoine)
  • Suggested times to meet (all of these are suggestions)
    • 7pm CET (4pm ET, 10am PT, 2am KT 😖)
      • Billy: 10/22, 10/23, 10/26, 10/27, 10/29, 10/30
      • Antoine: 10/22, 10/23, 10/26, 10/27, 10/29, 10/30
    • 6pm CET (3pm ET, 9am PT, 1am KT 😖)
      • Billy: 10/30
      • Antoine: 10/23, 10/26, 10/27, 10/29, 10/30
      • Emil: 10/27, 10/28, 10/29, 10/30
    • 5pm CET (2pm ET, 8am PT 😖, 12am KT 😖)
      • Billy: 10/27, 10/30
      • Antoine: 10/26, 10/28
      • Emil: 10/27, 10/28, 10/30
    • 4pm CET (1pm ET, 7am PT 😖, 11pm KT 😖)
      • Billy: 10/20, 10/27/, 10/29, 10/30
      • Antoine: 10/23, 10/27, 10/28
      • Emil: 10/27, 10/28, 10/30
  • Format
    • Does this google doc make sense as a format?
    • Should this go on the forum?
    • A HackMD?
  • Multi-chain Assets
    • Connected via IBC
      • Single Hop
      • Multi-Hop
      • Querying the path via IBC
        • gRPC
    • Connected via Bridge
      • Eth
      • BTC
    • Balancer
      • Should all similar origin assets be bundled in a balancer style basket per chain?
    • Chain Agnostic Improvement Proposals
      • Info
        • These are proposals for standards for storing chains and asset references for client libraries to maintain integrity (and sanity!) while tracking assets across multiple blockchains.
      • **CAIP-2: **Blockchain ID Specification
        • Summary: Chain ids should have a namespace (like eip155 which describes eth specific chain-ids, or bip122 which describes btc specific chain ids) and then a reference to a specific chain within that reference (like “1” for mainnet ethereum or “cosmoshub-3” for the current cosmos mainnet).
        • Examples:

          • Ethereum mainnet

            • eip155:1

          • Bitcoin mainnet

            • bip122:000000000019d6689c085ae165831e93

          • Litecoin

            • bip122:12a765e31ffd4059bada1e25190f6e98

          • Cosmos Hub (Tendermint + Cosmos SDK)

            • cosmos:cosmoshub-2
            • cosmos:cosmoshub-3

          • Binance chain (Tendermint + Cosmos SDK; see https://dataseed5.defibit.io/genesis)

            • cosmos:Binance-Chain-Tigris

          • IOV Mainnet (Tendermint + weave)

            • cosmos:iov-mainnet
      • **CAIP-5: **Blockchain Reference for the Cosmos Namespace
        • Summary: chain-id for cosmos chains should follow regex [-a-zA-Z0-9]{1,47} and if not they should be hashed like: first_16_chars(hex(sha256(utf8(chain_id)))) and prefixed with “x”, “hash” or “hashed”
        • Issue:
          • Currently IBC based denoms breaks this spec
        • Examples:

          • Cosmos Hub (Tendermint + Cosmos SDK)

            • cosmos:cosmoshub-2
            • cosmos:cosmoshub-3

          • Binance chain

            • cosmos:Binance-Chain-Tigris

          • IOV Mainnet (Tendermint + Weave)

            • cosmos:iov-mainnet

          • chain_ids "x", "hash-", "hashed" (are direct)

            • cosmos:x
            • cosmos:hash-
            • cosmos:hashed

          • chain_ids "hashed-", "hashed-123" (invalid prefix for the direct definition)

            • cosmos:hashed-c904589232422def
            • cosmos:hashed-99df5cd68192b33e

          • chain_id "123456789012345678901234567890123456789012345678" (too long for the direct definition)

            • cosmos:hashed-0204c92a0388779d

          • chain_ids " ", "wonderland🧝‍♂️" (invalid character for the direct definition)

            • cosmos:hashed-36a9e7f1c95b82ff
            • cosmos:hashed-843d2fc87f40eeb9
      • **CAIP-10: **Account ID Specification
        • Summary
          • An account is only relevant to the chain on which it exists so it should be packaged together like account_id: account_address + "@" + chain_id
        • Examples

          • Ethereum mainnet

            • 0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1

          • Bitcoin mainnet

            • 128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6@bip122:000000000019d6689c085ae165831e93

          • Cosmos Hub

            • cosmos1t2uflqwqe0fsj0shcfkrvpukewcw40yjj6hdc0@cosmos:cosmoshub-3

          • Kusama network

            • 5hmuyxw9xdgbpptgypokw4thfyoe3ryenebr381z9iaegmfy@polkadot:b0a8d493285c2df73290dfb7e61f870f

          • Dummy max length (63+1+16+1+47 = 128 chars/bytes)

            • bd57219062044ed77c7e5b865339a6d727309c548763141f11e26e9242bbd34@max-namespace-16:xip3343-8c3444cf8970a9e41a706fab93e7a6c4-xxxyyy
      • **CAIP-19: **Asset Type and Asset ID Specification
        • Summary
          • An asset has a specific origin which is referenced with the Blockchain ID specification, but within that setting there are various ways to designate a token. One way is slip44 where an asset number is registered. Another way is as an ERC-20 on EVM chains with a reference to a contract address. There is also the possibility that an asset has an ID on top for non-fungible tokens, this should be appended should it be necessary.
        • Issues
          • This doesn’t address an asset once it’s moved away from it’s origin chain. In the SDK the path is namespaced as part of the asset as seen in ADR001: Coin Source Tracing.
        • Example:

          • Ether Token

            • eip155:1/slip44:60

          • Bitcoin Token

            • bip122:000000000019d6689c085ae165831e93/slip44:0

          • ATOM Token

            • cosmos:cosmoshub-3/slip44:118

          • Litecoin Token

            • bip122:12a765e31ffd4059bada1e25190f6e98/slip44:2

          • Binance Token

            • cosmos:Binance-Chain-Tigris/slip44:714

          • IOV Token

            • cosmos:iov-mainnet/slip44:234

          • Lisk Token

            • lip9:9ee11e9df416b18b/slip44:134

          • DAI Token

            • eip155:1/erc20:0x6b175474e89094c44da98b954eedeac495271d0f

          • CryptoKitties Collectible

            • eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d

          • CryptoKitties Collectible ID

            • eip155:1/erc721:0x06012c8cf97BEaD5deAe237070F9587f8E7A266d/771769
    • Proposals
      • Extend CAIP-19 to include IBC path information?
      • Query a port and channel for the chain id like here
      • Denom would look like:
        • ibcDenom = "ibc/" + hash(trace path + "/" + base denom)
        • trace path = {destPortN}/{destChannelN}/…/{destPort0}/{destChannel0}
      • What does a user want?
        • Blockchain : Denom
        • If it is IBC
          • Should have an asterisk?
          • Hover?
          • See the path it took as a popup showing the chain ids
          • Ability to debug shows the channel and port ids
        • View options
          • Group similar assets
            • All atoms grouped no matter what ibc path
            • All eth grouped no matter what bridge
            • All stable tokens grouped no matter what type?
      • Standardization around slip44 paths within the ecosystem between wallets
  • Asset Directory
    • https://github.com/iov-one/asset-directory
    • Namespace on Tickers
    • Namespace on CAIP-19s
    • JS package to import into project for querying metadata
    • API possible with Lambda function attached to github for most up to date endpoint
  • Name Services
    • Starname.me
      • Namespaced with an asterisk, stored on a cosmos sdk blockchain
      • Has a registry that includes slip44 addresses
      • Format is like: antoine*cosmos
    • ENS
      • Following ICANN namespace (except for the .eth) in order to register data under human readable names.
      • Uses nested namespace so that TLD = .eth, .xyz currently with verification via DNS RSA signatures and soon to be all TLD addresses
      • Has a registry that includes slip44 addresses so a cosmos address can be stored like cosmos.billyrennekamp.eth
    • Subjective initialisation canonical name registry #483
      • Name service for chain IDs to be stored on chain
Last changed by 
 
billy rennekamp
0
2
1771

Read more

Bad Kid Images

https://res.cloudinary.com/stargaze/image/upload/w_700/b5ij1wrgjzmzcivljffz.jpg

Jul 15, 2023
Formatting a proposal

Begin by writing out the proposal description in markdown. Confirm that it's under the charlimit (5k until Theta and 10k after). Then generate the proposal with --offline so that it is not signed but the json is created. Pipe it into a file like unsigned.json. You can leave the description empty or with dummy text here because the CLI will try to escape the chars but likely not the way you want. > gaiad tx gov submit-proposal software-upgrade v7-Theta \ --title v7-Theta \ --deposit 50000uatom \ --upgrade-height 10085397 \ --upgrade-info '{"binaries":{"linux/amd64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-linux-amd64?checksum=sha256:dc0e5b6690a55f0f1c41ad96f068049e25d9e85d53c0587284b7f1a1f9a51545","linux/arm64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-linux-arm64?checksum=sha256:994f67ec8134504ae032a1ae58caf769b5a9a1581a38705efd94ab654a7f6173","darwin/amd64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-darwin-amd64?checksum=sha256:2b7425b27e1c04877f0e9230f1657bee1b3274b73bee8f550a290cc505444dbf","windows/amd64":"https://github.com/cosmos/gaia/releases/download/v7.0.0/gaiad-v7.0.0-windows-amd64.exe?checksum=sha256:1362b026e942cc16ab2b7f35a3ff39fb9075dcde70570635485d4b1866e1d036"}}' \ --description "#test\r\n\r##test" \

May 1, 2022
for vega upgrade

for vega-upgrade gaiad tx gov submit-proposal software-upgrade Vega \ --title Vega \ --deposit 500000uatom \ --upgrade-height 8695000 \ --upgrade-info '{"binaries":{"linux/amd64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-linux-amd64?checksum=sha256:d9b4391065a338107ca240f29539d62572fe1e85a6c455576afc5e93dba7f402","linux/arm64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-linux-arm64?checksum=sha256:e348259fb9ca5d516a8754ea1f15255ef32e7656e79d52a87616edb16f0a7343","darwin/amd64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-darwin-amd64?checksum=sha256:e0de182c098ab68d3ef4bab8a3d12aca100b9f1d18d873d66e82ec2c187a1735","windows/amd64":"https://github.com/cosmos/gaia/releases/download/v6.0.0/gaiad-v6.0.0-windows-amd64.exe?checksum=sha256:713cb6c1a7ef555d5ed64f036f65b039b44b76f314855e2f7d2a5330568e6100"}}' \ --description "This on-chain upgrade governance proposal is to adopt gaia v6.0.0 which includes a number of updates, fixes and new modules. By voting YES to this proposal, you approve of adding these updates to the Cosmos Hub.\n\n### Background\n\nSince the last upgrade at height 6910000 there have been a number of updates, fixes and new modules added to the Cosmos SDK, IBC and Tendermint. The following updates are included in gaia v6.0.0:\n * Bump [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) to [v0.44.3](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.3) which notably includes fixes for the vesting accounts and two new modules outlined below. For a full list of updates in Cosmos-SDK v0.44.3 please see the [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/CHANGELOG.md#v0443---2021-10-21)\n * Add the [authz](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/authz/spec) module to the Cosmos Hub. `x/authz` is an implementation of a Cosmos SDK module, per [ADR 30](https://github.com/cosmos/cosmos-sdk/blob/v0.44.3/docs/architecture/adr-030-authz-module.md), that allows granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the `Authorization` interface.\n * Add the [feegrant](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/feegrant/spec) module to the Cosmos Hub. This module allows accounts to grant fee allowances and to use fees from their accounts. Grantees can execute any transaction without the need to maintain sufficient fees.\n * **NOTICE** It's imortant to highlight [PR #10041](https://github.com/cosmos/cosmos-sdk/pull/10041) which impacts **WALLETS AND EXCHANGES**. This update has removed the deprecated the legacy REST endpoints for broadcast & encode. **This means `POST /tx` and `POST /txs/encode` no longer work**. Please see the [REST Endpoints Migration guide](https://docs.cosmos.network/master/migrations/rest.html) to migrate to the new REST endpoints.\n * Add [IBC](https://github.com/cosmos/ibc-go) as a standalone module from the Cosmos SDK using version [v2.0.0](https://github.com/cosmos/ibc-go/releases/tag/v2.0.0). See the [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v2.0.0/CHANGELOG.md) for details.\n * Please note that the governance parameter for `MaxExpectedBlockDelay` is set to 30 seconds. This means if a connection is opened with a packet delay of 1 minute, it requires 2 blocks to be committed after the consensus state is submitted before the packet can be processed.\n * Add [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) [v1.0.1](https://github.com/strangelove-ventures/packet-forward-middleware/releases/tag/v1.0.1) as per [Proposal #56](https://www.mintscan.io/cosmos/proposals/56) prepared and tested by [Strangelove Ventures](https://www.strangelove.ventures/). This feature allows multi-hop IBC transfer messages so that a user can send tokens from chain A to chain C via chain B.\n * Bump [Liquidity](https://github.com/gravity-devs/liquidity) module to [v1.4.2](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.4.2) to ensure compatibility with Cosmos-SDK.\n\n### Ready for Production\n\nThese changes have been extensively tested by various Cosmos Core Contributor teams including [Hypha Co-Op](https://hypha.coop/), [Informal Systems Co-Op](https://informal.systems/), [Interchain GmbH](https://interchain.berlin/), [Regen Network](https://regen.network/), [Strangelove Ventures](https://strangelove.ventures/), [Tendermint Inc](https://tendermint.com/) and more. The release candidate for this update was run as a local testnet and a public testnet with a successful upgrade; documentation can be found [here](https://github.com/cosmos/vega-test).\n\n### On-Chain Upgrade Process\n\nWhen the network reaches the halt height, the state machine program of the Cosmos Hub will be halted. The classic method for upgrading requires all validators and node operators to manually substitute the existing state machine binary with the new binary. There is also a newer method that relies on [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/master/cosmovisor) to swap the binaries automatically. Cosmovisor also includes the ability to download the binaries automatically before swapping them. Instructions specific to the upgrade can be found [here](https://github.com/cosmos/gaia/blob/main/docs/gaia-tutorials/upgrade-node.md). To test a simulated local upgrade please see the [local testnet documentation](https://github.com/cosmos/vega-test/blob/master/local-testnet/README.md). Because it is an onchain upgrade process, the blockchain will be continued with all the accumulated history with continuous block height.\n" \ --fees 300uatom \ --gas auto \ --from deploy \

Mar 16, 2022
ICA demo

This is the script that needs to be run on both servers, except the chain id needs to be changed on the second server Introduction Alice is on chain test-1 and has 100 tokens bob is on chain test-2 does not have any token. alice knows an faucet user on chain test-2, so she can sometimes ask faucet user to send her some tokens. now, alice wants to send some native token of chain test-2 to bob.

Jan 25, 2022
Read more from billy rennekamp
Published on HackMD